隨著2019華為開發(fā)者大會的臨近，華為消費者業(yè)務(wù)CEO余承東此前在P30國內(nèi)發(fā)布會上宣布的“能夠?qū)崿F(xiàn)Android性能革命”的方舟編譯器也即將進入到開源階段。
雖然此前在4月份華為已經(jīng)就方舟編譯器進行了介紹，但人們更加關(guān)心的是：華為方舟編譯器的革命性到底體現(xiàn)在哪里？
針對這個問題，余承東在8月6日推薦了一篇由“菊廠搞機”發(fā)表的一篇題為《華為新貴！方舟編譯器的榮光和使命》的長文，該文對華為方舟編譯器的實現(xiàn)原理和背后故事進行了解讀—;—;而雷鋒網(wǎng)也希望由此提取出關(guān)于華為方舟編譯器實現(xiàn)Android性能革命的諸多要點。
Android代碼編譯的原理和弊端
在目前全世界的多種編程語言中，Android操作系統(tǒng)采用的是Java語言。
Java語言是在1995年5月發(fā)布的，它的一個重點特點就是可以跨平臺操作，而且需要借助虛擬機機制來解釋源代碼并調(diào)度硬件資源；但同時Java是一種預(yù)編譯語言，需要先在開發(fā)者環(huán)境中將源代碼（SourceCode）轉(zhuǎn)換成字節(jié)碼（ByteCode），然后在設(shè)備上運行時再將字節(jié)碼編譯或解釋成硬件能聽得懂的機器碼。
也就是說，從Java的字節(jié)碼到機器碼，中間需要兩樣?xùn)|西：
1、虛擬機，用來調(diào)度硬件資源；
2、翻譯器（將Java字節(jié)碼解釋成機器語言）或者編譯器（將Java字節(jié)碼編譯成機器碼）。此處要注意的是，翻譯器和編譯器是不同的；編譯器是把源程序的每一條語句都編譯成機器語言并保存成二進制文件，這樣運行時計算機可以直接以機器語言來運行此程序，因而速度很快；而解釋器則是只在執(zhí)行程序時，才一條一條地解釋成機器語言來讓計算機執(zhí)行，因此運行速度不如編譯后的程序運行得快。
而對于Android操作系統(tǒng)來說，為了將Java字節(jié)碼變成機器語言，Google在不同的版本中進行了多樣化的嘗試，其目的自然是不斷推動應(yīng)用程序的運行速度向前發(fā)展；我們來看一下Android在不同版本是怎么做的：
Android 1.0（2008年）：采用一個名為Dalvik的虛擬機，并且集成了一個解釋器。當(dāng)App運行時，就會調(diào)用這個解釋器，對代碼進行逐句解釋，速度很慢。
Android 2.2（2010年）：引入JIT（Just In Time）即時編譯機制，當(dāng)App運行時，會將用戶經(jīng)常使用的功能編譯為機器能直接執(zhí)行的010101機器碼，不用一句一句地去翻譯。當(dāng)出現(xiàn)不常用的功能時，再調(diào)用解釋器來翻譯；這樣速度加快，但每次啟動App都要重新編譯一次，不能一勞永逸。
Android 5.0（2014年10月）：將虛擬機Dalvik換成ART（Android Run Time），將JIT的編譯器替換成AOT（Ahead of Time）。如此，App在下載后安裝到手機上時同時把能編譯的代碼先編譯成機器聽得懂的101010；剩下不太好翻譯的代碼，就在用戶使用時再叫醒解釋器來翻譯。如此，不用每次打開App都需要編譯，但安裝App的時間有點長，而且占用手機空間。
Android 7.0（2017年）：采用混合編譯機制，安裝時先不編譯中間代碼，而是在用戶空閑時將能夠編譯成機器碼的那部分代碼，通過AOT編譯器先靜態(tài)編譯了。如果AOT還沒來得及編譯或者不能編譯，再調(diào)用JIT+解釋器。這種機制，相當(dāng)于用時間換空間，既縮短了用戶安裝APP的等待時間，又將虛擬機里編譯器和解釋器能做的優(yōu)化提升到最大效率了。
可以看到，無論是編譯器還是解釋器，只是在虛擬機上打補丁，手機上的虛擬機+編譯器+解釋器本身不僅占用硬件資源，還無法最大發(fā)揮軟件運行性能。正因如此，所以絕大部分手機廠商只能無奈的通過簡單粗暴提升Android手機的內(nèi)存和存儲空間，來彌補虛擬機的弊端。
由此出發(fā)，Android系統(tǒng)在性能和應(yīng)用運行層面有四個方面的問題：
1、如前所述，離不開虛擬機；
2、為了與C/C++等代碼進行交互，Java原生接口（Java Native Interface，簡稱JNI）應(yīng)運而生。目前95%的TOP應(yīng)用都是使用Java和C/C++等多種語言混合開發(fā)而成。Java和C/C++屬于兩種不同架構(gòu)的語言，各有自己的使用規(guī)范。為了APP正常運行，它倆之間需要互通有無，這個互通有無的接口就是JNI。在數(shù)據(jù)訪問、函數(shù)調(diào)用、生命周期維護、異常處理等方面都需要這兩種代碼互相調(diào)用。這就意味著手機硬件資源要分配一部分給JNI去做調(diào)度—;—;這一機制本身的效率就不高，而且占用了硬件資源。
3、Android虛擬機的編譯器受限于手機硬件和代碼優(yōu)化模板單一，代碼優(yōu)化空間有限。編譯器包含三個部分：前端FrontEnd，主要負責(zé)將源代碼翻譯成IR（Intermediate Representation）；中端的Optimizer主要負責(zé)代碼優(yōu)化，將前端翻譯過來的IR代碼優(yōu)化得更高效；后端BackEnd則將優(yōu)化后的IR編譯成101010的機器碼—;—;為了防止生態(tài)過于碎片化，Android只為第三方開放了簡單的編譯代碼優(yōu)化模板，代碼優(yōu)化空間有限。
4、Java現(xiàn)有的內(nèi)存回收機制容易造成“間歇性”卡頓。當(dāng)手機內(nèi)存資源不夠用的時候，Android虛擬機就會召喚GC（Garbage Collection，垃圾回收）讓所有手機運行的Java線程全部暫停，等待它回收內(nèi)存空間，避免過載超載。這個GC機制，無法精確控制和干預(yù)，用戶也無法把它去掉，所以性能比較差的手機還存在“間歇性”卡頓。
這四個問題，也是華為試圖通過方舟編譯器解決的問題。
華為方舟編譯器是如何解決問題的？
在回答這個問題之前，先看一下華為從事方舟編譯器工作的時間線：
2009年，華為啟動5G基礎(chǔ)技術(shù)研究的同時，開始創(chuàng)建編譯組，第一批海內(nèi)外研究人員加入。
2013年，華為推出面向基站領(lǐng)域的自研編譯器HCC，并正式提出編譯器框架構(gòu)想。
2014年，眾多海內(nèi)外專家加入華為，方舟項目正式啟動。
2016年，成立編譯器與編程語言實驗室。
2017年，方舟編譯器上的第一個Java程序“HelloWorld”跑通。
2018年春節(jié)前一周，方舟編譯器跑通Android系統(tǒng)所有后臺服務(wù)，并成功移植到手機。
2019年4月，華為方舟編譯器在P30系列的國內(nèi)發(fā)布會上對外宣布。
那么，方舟編譯器的原理究竟是如何實現(xiàn)的？
實際上，華為所謂的“方舟編譯器”與其說是一個編譯器，不如說是一個編譯運行系統(tǒng)；這個系統(tǒng)的運行需要開發(fā)環(huán)境和終端（也就是智能手機）的配合，其目的是繞過Android操作系統(tǒng)中App的運行所必須依賴的虛擬機，將Java/C/C++等混合代碼一次編譯成機器碼直接在手機上運行，徹底告別Java的JNI額外開銷，也徹底告別了虛擬機的GC內(nèi)存回收帶來的應(yīng)用進程掉線—;—;從而最終實現(xiàn)Android操作系統(tǒng)的流暢度。
正如上文所言，在方舟編譯器的這一實現(xiàn)過程中，需要解決四個方面的問題。
第一：將Java代碼直接編譯成機器碼
就目前的情況來看，Java編譯成機器碼的過程中，要面臨的難題是Java中的動態(tài)語義（與之對應(yīng)的是靜態(tài)語義，它是通過提前翻譯能夠解決的），靜態(tài)語義指的是確定的語言和意思，而動態(tài)語義指的是需要結(jié)合上下文來理解的內(nèi)容—;—;這其中，如果要像編譯靜態(tài)語義一樣去編譯動態(tài)語義，很多知乎大神認(rèn)為是根本就不可能的。
而這個不可能，正是華為在開發(fā)方舟編譯器過程中解決的問題。
具體來說，方舟編譯器通過編譯階段和運行階段的雙向加持，將靜態(tài)編譯動態(tài)語義最大的兩大難點解決：一是設(shè)計數(shù)據(jù)模型，二是如何在運行時高效獲得動態(tài)信息。
方舟編譯器團隊基本遍歷了Java的動態(tài)語義，進行了大規(guī)模的數(shù)據(jù)建模。同時，大大提高了編譯時動態(tài)語義分析的精度，特別是涉及跨語言調(diào)用時；另外，華為設(shè)計了一套具有核心專利的動態(tài)語義匹配機制，有效降低了運行時動態(tài)語義的開銷。
由此，方舟編譯器能夠?qū)ava代碼編譯成機器能直接執(zhí)行的語言。華為方面表示，經(jīng)過華為方舟編譯器的App，再也不需要在手機上編譯了，徹底告別了虛擬機，從而帶來了媲美甚至超越iOS的Android體驗。
第二：解決混合語言的JNI開銷
由于95%的Top應(yīng)用都是Java/C/C++等混合語言編寫而成；因此方舟編譯器還需要干掉混合語言互相調(diào)用帶來的JNI開銷。
這里就涉及到上文提到的一個名詞IR，它是用來表示代碼的數(shù)據(jù)結(jié)構(gòu)，它是編譯器的各模塊以及相關(guān)工具之間用來傳遞信息的“協(xié)議和通用語言”，也是程序變換和編譯優(yōu)化各種算法的承載體。它是編譯器的“大腦”，直接決定了編譯器的最終效果—;—;因此，它的難度是最高的。
華為方舟編譯器團隊對IR進行了長達五年的精雕細琢，逐漸摸索出“大腦”里每一條神經(jīng)、每一個神經(jīng)元的信號規(guī)律，并在此基礎(chǔ)上發(fā)明了一套核心專利，使得不同語言代碼在開發(fā)者環(huán)境中能夠統(tǒng)一編譯成同一套可直接執(zhí)行的機器碼，從而徹底消除了混合語言互相調(diào)用的開銷。
也就是說華為方舟編譯器可以將混合語言實現(xiàn)統(tǒng)一的中間表示IR，這就相當(dāng)于同一個人能夠理解全世界的語言—;—;當(dāng)然，這背后是華為方舟編譯器團隊基于多個編程語言的深刻理解和大量研發(fā)積累。
第三：在統(tǒng)一IR之外進行代碼優(yōu)化
華為方舟編譯器，直接將代碼優(yōu)化從手機環(huán)節(jié)搬到了開發(fā)者環(huán)境，未來還可能搬到云端。利用開發(fā)者環(huán)境更強大的算力，可以實現(xiàn)更先進和精細的優(yōu)化算法，來達到更佳的優(yōu)化效果—;—;華為表示，在很多特定場景代碼優(yōu)化的提升甚至是顛覆性的。
值得一提的是，開發(fā)者使用方舟編譯器，并不需要改變原來的編碼習(xí)慣。開發(fā)者可以自行開發(fā)代碼優(yōu)化算法，也可以僅通過方舟編譯器預(yù)置的算法進行代碼優(yōu)化。未來，華為還將提供代碼調(diào)優(yōu)工具，開發(fā)者可以選擇根據(jù)工具的優(yōu)化建議來調(diào)整代碼，和方舟編譯器配合獲得更優(yōu)的執(zhí)行效果。
第四：解決Android內(nèi)存回收帶來的卡頓問題
為了解決這個問題，方舟編譯器采用了引用計數(shù)法（RC，Reference Counting）來進行內(nèi)存的實時回收，并且配合使用了專門的消除環(huán)算法（消除對象互相引用帶來的無法回收問題），來避免GC集中式回收帶來的系統(tǒng)卡頓。相比GC，方舟的內(nèi)存回收是實時的而非集中式的，且不需要暫停應(yīng)用進程，這樣便大大消除了卡頓。
另外，軟件有一個大家都很熟悉的死循環(huán)，就是電腦被一個無限循環(huán)的運行程序把計算機資源占光。這種“死循環(huán)”在軟件中叫“環(huán)引用”。為了從機制避免手機內(nèi)存被環(huán)引用“吃掉”，方舟編譯器引入annotation的“告警”標(biāo)示，對基礎(chǔ)類的環(huán)進行標(biāo)注。
當(dāng)然，Java程序員也可以對業(yè)務(wù)代碼中的環(huán)進行標(biāo)注。經(jīng)過豐富的實踐驗證，方舟這種機制可以減少大部分程序中環(huán)的出現(xiàn)。另外一方面，方舟編譯器在運行狀態(tài)下引入了高效的環(huán)回收機制，允許有選擇的智能回收某個APP的內(nèi)存占用，這對傳統(tǒng)的環(huán)回收算法是一個改進。
總結(jié)來看，面對現(xiàn)有的Android系統(tǒng)在代碼編譯、運行、IR、內(nèi)存回收等四個層面的問題，華為方舟編譯器分別給出了自己的解決方案，這其中的核心創(chuàng)新點是混合語言的統(tǒng)一中間表示和完全靜態(tài)編譯，但更重要的是華為在解決Android操作系統(tǒng)App運行問題的嶄新思路，以及為了實現(xiàn)這種思路而敢于大力投入的勇氣。
總結(jié)
方舟本質(zhì)上不僅僅是一個編譯器，而是一個編譯系統(tǒng)，它需要通過用戶終端和開發(fā)者的共同支持。
對于華為手機用戶來說，華為在手機終端中已經(jīng)用方舟編譯器替代了Android system-server的所有后臺服務(wù)，這一項就已經(jīng)足夠讓華為EMUI比其他Android系統(tǒng)更快一步—;—;根據(jù)華為官方測試，方舟編譯器提升手機系統(tǒng)操作流暢度高達24%，系統(tǒng)響應(yīng)性能提升44%。
當(dāng)然，華為要想充分發(fā)揮方舟這個編譯系統(tǒng)的實力，還離不開開發(fā)者在開發(fā)層面對方舟編譯器的大力支持，這本質(zhì)上是華為在現(xiàn)有Android開發(fā)生態(tài)之外另辟蹊徑打造的一個全新開發(fā)環(huán)境—;—;它究竟能否得到開發(fā)者的支持，還需要等華為將其開源之后才能有答案。
下載文檔
