緣起

華為的方舟編譯器終于走出開源的第一步，官方地址為https://www.openarkcompiler.cn/home 。我個(gè)人于今年4月在機(jī)械工業(yè)出版社出版了“深入理解Android”系列書籍的最后一本書——《深入理解Android Java虛擬機(jī)ART》一書。

這本書圍繞Android系統(tǒng)中Java虛擬機(jī)ART做了詳盡的源碼分析。其中，第六章更是以全書最多的篇幅從字節(jié)碼到機(jī)器碼的編譯過程進(jìn)行了詳細(xì)介紹。

寫書時(shí)，我一直耿耿于懷國內(nèi)在計(jì)算機(jī)基礎(chǔ)核心技術(shù)上缺乏領(lǐng)軍公司的投入之時(shí)，沒想到今年華為先送出方舟編譯器，緊接其后是鴻蒙OS。未來不敢說結(jié)局怎樣，但現(xiàn)時(shí)真切讓我和我周圍的小伙伴看到了希望。就算激起無論是正面還是負(fù)面的全民大討論，我覺得相比無人問津也算是大大的進(jìn)步。

言歸正傳，結(jié)合方舟的官網(wǎng)，我其實(shí)有幾個(gè)技術(shù)問題想請教。當(dāng)然，隨著方舟進(jìn)一步擴(kuò)大和深度開源，這些問題可能也就不言自明。到時(shí)候感興趣的讀者不妨以這里提到的問題來看看方舟是如何巧妙解決它們的。

問題一：

https://www.openarkcompiler.cn/document/FAQ Q2說“當(dāng)前部分Java語言特性和JVM虛擬機(jī)特性的支持未包括在本次開源代碼中，包括：annotation、lambda表達(dá)式、泛型等”。想了解下，這部分功能是否已經(jīng)在方舟編譯器上實(shí)現(xiàn)但目前還未開源出來？還是什么別的情況？出于什么考慮，lambda表達(dá)式和泛型未能在此時(shí)開源？

問題二：

編譯器領(lǐng)域現(xiàn)在業(yè)界都使用三段式編譯器。架構(gòu)如下：

編譯器框架LLVM和核心就是LLVM IR，而方舟編譯器也有一個(gè)Maple IR。請問相比LLVM IR，Maple IR的優(yōu)勢在哪里？它的愿景是什么？

問題三：

經(jīng)過方舟編譯器處理后的應(yīng)用，從公開渠道上的信息上看，在流暢度等幾個(gè)方面有大幅提升。能否詳細(xì)介紹下流暢度是怎么衡量的？也就是說，方舟內(nèi)部是如何評價(jià)經(jīng)過方舟編譯器處理后以及沒有經(jīng)過方舟編譯器處理后的應(yīng)用的性能？都選了哪些測試點(diǎn)？

問題四：

適配了方舟編譯器的有幾十個(gè)APP，但還有很多APP開發(fā)者沒有機(jī)會第一時(shí)間接觸方舟（包括我自己）。想了解下使用方舟編譯器是否有副作用？比如，如果將字節(jié)碼全部轉(zhuǎn)成了機(jī)器碼，這會占據(jù)較大的存儲空間。請問是否有類似這樣的問題，有什么好的解決辦法嗎？

問題五：

方舟編譯器說干掉了JVM虛擬機(jī)（原話可能不是如此，但我理解是這個(gè)意思），請問經(jīng)過方舟編譯器處理的應(yīng)用是否能按以前的Java程序那樣調(diào)試？

備注：為什么會問這個(gè)問題？java程序debug時(shí)必須靠jvm幫忙，比如處理jdwp，更關(guān)鍵是要靠jvm來解釋執(zhí)行字節(jié)碼。不過，我在ART那本書里并沒有詳細(xì)介紹這個(gè)過程，我不保證這個(gè)問題問正確了。也請懂行的朋友們指正。

問題六：

方舟編譯器對java語言的特性支持如何？比如，ART虛擬機(jī)中，一個(gè)java方法即使以機(jī)器碼方式運(yùn)行，在某些時(shí)候也必須回退到解釋執(zhí)行。比如下面的ArrayIndexOutOfBounds異常的處理。

對于類似這種問題，方舟編譯器在技術(shù)層面上對于它們大概的解決思路是什么？

問題七：

ART虛擬機(jī)在諸如synchronized等的實(shí)現(xiàn)上做了大量工作（ART一書的第十二章），包括優(yōu)化（比如一個(gè)線程如果已經(jīng)得到某個(gè)鎖的情況下，后續(xù)再去獲取這個(gè)鎖的話，實(shí)際上只是遞增了該鎖的引用計(jì)數(shù)）。雖然PTHREAD相關(guān)同步處理也有類似的優(yōu)化，但我想了解下方舟編譯器（如果干掉虛擬機(jī)的話），有沒有針對這方面的處理或者優(yōu)化？

問題八：

引用計(jì)數(shù)是垃圾回收的一種經(jīng)典技術(shù)。方舟編譯器說是用引用計(jì)數(shù)代替了其它幾種GC技術(shù)，做到隨用隨收。但其中有一些需要特別注意的地方（ART一書的第十三章、十四章專門講解內(nèi)存分配和GC）。垃圾回收是和內(nèi)存分配息息相關(guān)的。ART虛擬機(jī)內(nèi)部對內(nèi)存分配有著良好的管理。比如rosalloc分配器，BumpPointerSpace、針對大內(nèi)存對象的LargeObjectSpace等。請問方舟編譯器是怎么應(yīng)對的？是將java層的new直接對應(yīng)到比如native層的new/malloc（直接依賴os的內(nèi)存分配機(jī)制），還是也依賴一個(gè)小的，輕量級的runtime來協(xié)助這方面的工作？

另外，ART在內(nèi)存管理方面做了一些優(yōu)化，比如當(dāng)程序退到后臺后，會對內(nèi)存進(jìn)行碎片整理。如果方舟編譯器是隨用隨收的話，請問長時(shí)間運(yùn)行后，是否會存在內(nèi)存碎片？如果有，是如何處理的呢？

問題九：

官網(wǎng)上提到了伴隨方舟編譯器有一個(gè)輕量級的運(yùn)行時(shí)，這個(gè)運(yùn)行時(shí)主要工作是什么？它和ART JVM有何區(qū)別？方舟編譯器未來還要支持Javascript，這個(gè)運(yùn)行時(shí)是否也能支持JS？還是說需要一個(gè)針對js的運(yùn)行時(shí)？最后，這個(gè)運(yùn)行時(shí)會開源嗎？

問題十：

我想方舟編譯器的背后是承載了華為甚至很多國人偉大夢想的，但一時(shí)領(lǐng)先并不保證長久領(lǐng)先。比如，媒體做了經(jīng)過方舟編譯器處理后APP和蘋果手機(jī)上APP打開速度的對比測試。方舟編譯器的效果比較明顯。但ios13據(jù)蘋果官方數(shù)據(jù)上看，APP啟動(dòng)速度提升了兩倍。這說明我們在努力，對手也在努力。華為是一個(gè)有著很強(qiáng)憂患意識的偉大公司。那么，方舟編譯器針對ios13是否有優(yōu)勢？我們這個(gè)優(yōu)勢會不會很容易被對手顛覆呢？我們該如何努力，朝哪個(gè)方向努力呢？

最后

無論怎樣，方舟編譯器都會在IT歷史上留下濃重的筆墨。衷心期望我個(gè)人或其它朋友能為我們自己的IT成果——方舟編譯器、鴻蒙OS等編寫學(xué)習(xí)資料，貢獻(xiàn)自己的微薄力量。

最后的最后

我期望的結(jié)果不是朋友們從我的書、文章、博客后學(xué)會了什么知識，干成了什么，而應(yīng)該是說，神農(nóng)，我可是踩在你的肩膀上的喔。

關(guān)于學(xué)習(xí)方面的問題，我已經(jīng)討論完了。后面這個(gè)公眾號將對一些基礎(chǔ)的技術(shù)，新技術(shù)做一些學(xué)習(xí)和分享。也歡迎你的投稿。不過，正如我在公眾號“聯(lián)系方式”里說的那樣——鄭淵潔在童話大王《智齒》里有一句話令我印象深刻，大意是“我有權(quán)保持沉默，但你說的每一句話都可能成為我靈感的源泉”。所以，影響不是單向的，很可能我從你那學(xué)到的東西更多。