解讀：華為方舟編譯器的革命性到底體現(xiàn)在哪里？

隨著2019華為開發(fā)者大會(huì)的臨近，華為消費(fèi)者業(yè)務(wù)CEO余承東此前在P30國(guó)內(nèi)發(fā)布會(huì)上宣布的“能夠?qū)崿F(xiàn)Android性能革命”的方舟編譯器也即將進(jìn)入到開源階段。

雖然此前在4月份華為已經(jīng)就方舟編譯器進(jìn)行了介紹，但人們更加關(guān)心的是：華為方舟編譯器的革命性到底體現(xiàn)在哪里？

針對(duì)這個(gè)問題，余承東在8月6日推薦了一篇由“菊廠搞機(jī)”發(fā)表的一篇題為《華為新貴！方舟編譯器的榮光和使命》的長(zhǎng)文，該文對(duì)華為方舟編譯器的實(shí)現(xiàn)原理和背后故事進(jìn)行了解讀—;—;而雷鋒網(wǎng)也希望由此提取出關(guān)于華為方舟編譯器實(shí)現(xiàn)Android性能革命的諸多要點(diǎn)。

Android代碼編譯的原理和弊端

在目前全世界的多種編程語言中，Android操作系統(tǒng)采用的是Java語言。

Java語言是在1995年5月發(fā)布的，它的一個(gè)重點(diǎn)特點(diǎn)就是可以跨平臺(tái)操作，而且需要借助虛擬機(jī)機(jī)制來解釋源代碼并調(diào)度硬件資源；但同時(shí)Java是一種預(yù)編譯語言，需要先在開發(fā)者環(huán)境中將源代碼（SourceCode）轉(zhuǎn)換成字節(jié)碼（ByteCode），然后在設(shè)備上運(yùn)行時(shí)再將字節(jié)碼編譯或解釋成硬件能聽得懂的機(jī)器碼。

也就是說，從Java的字節(jié)碼到機(jī)器碼，中間需要兩樣?xùn)|西：

1、虛擬機(jī)，用來調(diào)度硬件資源；

2、翻譯器（將Java字節(jié)碼解釋成機(jī)器語言）或者編譯器（將Java字節(jié)碼編譯成機(jī)器碼）。此處要注意的是，翻譯器和編譯器是不同的；編譯器是把源程序的每一條語句都編譯成機(jī)器語言并保存成二進(jìn)制文件，這樣運(yùn)行時(shí)計(jì)算機(jī)可以直接以機(jī)器語言來運(yùn)行此程序，因而速度很快；而解釋器則是只在執(zhí)行程序時(shí)，才一條一條地解釋成機(jī)器語言來讓計(jì)算機(jī)執(zhí)行，因此運(yùn)行速度不如編譯后的程序運(yùn)行得快。

而對(duì)于Android操作系統(tǒng)來說，為了將Java字節(jié)碼變成機(jī)器語言，Google在不同的版本中進(jìn)行了多樣化的嘗試，其目的自然是不斷推動(dòng)應(yīng)用程序的運(yùn)行速度向前發(fā)展；我們來看一下Android在不同版本是怎么做的：

Android 1.0（2008年）：采用一個(gè)名為Dalvik的虛擬機(jī)，并且集成了一個(gè)解釋器。當(dāng)App運(yùn)行時(shí)，就會(huì)調(diào)用這個(gè)解釋器，對(duì)代碼進(jìn)行逐句解釋，速度很慢。

Android 2.2（2010年）：引入JIT（Just In Time）即時(shí)編譯機(jī)制，當(dāng)App運(yùn)行時(shí)，會(huì)將用戶經(jīng)常使用的功能編譯為機(jī)器能直接執(zhí)行的010101機(jī)器碼，不用一句一句地去翻譯。當(dāng)出現(xiàn)不常用的功能時(shí)，再調(diào)用解釋器來翻譯；這樣速度加快，但每次啟動(dòng)App都要重新編譯一次，不能一勞永逸。

Android 5.0（2014年10月）：將虛擬機(jī)Dalvik換成ART（Android Run Time），將JIT的編譯器替換成AOT（Ahead of Time）。如此，App在下載后安裝到手機(jī)上時(shí)同時(shí)把能編譯的代碼先編譯成機(jī)器聽得懂的101010；剩下不太好翻譯的代碼，就在用戶使用時(shí)再叫醒解釋器來翻譯。如此，不用每次打開App都需要編譯，但安裝App的時(shí)間有點(diǎn)長(zhǎng)，而且占用手機(jī)空間。

Android 7.0（2017年）：采用混合編譯機(jī)制，安裝時(shí)先不編譯中間代碼，而是在用戶空閑時(shí)將能夠編譯成機(jī)器碼的那部分代碼，通過AOT編譯器先靜態(tài)編譯了。如果AOT還沒來得及編譯或者不能編譯，再調(diào)用JIT+解釋器。這種機(jī)制，相當(dāng)于用時(shí)間換空間，既縮短了用戶安裝APP的等待時(shí)間，又將虛擬機(jī)里編譯器和解釋器能做的優(yōu)化提升到最大效率了。

可以看到，無論是編譯器還是解釋器，只是在虛擬機(jī)上打補(bǔ)丁，手機(jī)上的虛擬機(jī)+編譯器+解釋器本身不僅占用硬件資源，還無法最大發(fā)揮軟件運(yùn)行性能。正因如此，所以絕大部分手機(jī)廠商只能無奈的通過簡(jiǎn)單粗暴提升Android手機(jī)的內(nèi)存和存儲(chǔ)空間，來彌補(bǔ)虛擬機(jī)的弊端。

由此出發(fā)，Android系統(tǒng)在性能和應(yīng)用運(yùn)行層面有四個(gè)方面的問題：

1、如前所述，離不開虛擬機(jī)；

2、為了與C/C++等代碼進(jìn)行交互，Java原生接口（Java Native Interface，簡(jiǎn)稱JNI）應(yīng)運(yùn)而生。目前95%的TOP應(yīng)用都是使用Java和C/C++等多種語言混合開發(fā)而成。Java和C/C++屬于兩種不同架構(gòu)的語言，各有自己的使用規(guī)范。為了APP正常運(yùn)行，它倆之間需要互通有無，這個(gè)互通有無的接口就是JNI。在數(shù)據(jù)訪問、函數(shù)調(diào)用、生命周期維護(hù)、異常處理等方面都需要這兩種代碼互相調(diào)用。這就意味著手機(jī)硬件資源要分配一部分給JNI去做調(diào)度—;—;這一機(jī)制本身的效率就不高，而且占用了硬件資源。

3、Android虛擬機(jī)的編譯器受限于手機(jī)硬件和代碼優(yōu)化模板單一，代碼優(yōu)化空間有限。編譯器包含三個(gè)部分：前端FrontEnd，主要負(fù)責(zé)將源代碼翻譯成IR（Intermediate Representation）；中端的Optimizer主要負(fù)責(zé)代碼優(yōu)化，將前端翻譯過來的IR代碼優(yōu)化得更高效；后端BackEnd則將優(yōu)化后的IR編譯成101010的機(jī)器碼—;—;為了防止生態(tài)過于碎片化，Android只為第三方開放了簡(jiǎn)單的編譯代碼優(yōu)化模板，代碼優(yōu)化空間有限。

4、Java現(xiàn)有的內(nèi)存回收機(jī)制容易造成“間歇性”卡頓。當(dāng)手機(jī)內(nèi)存資源不夠用的時(shí)候，Android虛擬機(jī)就會(huì)召喚GC（Garbage Collection，垃圾回收）讓所有手機(jī)運(yùn)行的Java線程全部暫停，等待它回收內(nèi)存空間，避免過載超載。這個(gè)GC機(jī)制，無法精確控制和干預(yù)，用戶也無法把它去掉，所以性能比較差的手機(jī)還存在“間歇性”卡頓。

這四個(gè)問題，也是華為試圖通過方舟編譯器解決的問題。

華為方舟編譯器是如何解決問題的？

在回答這個(gè)問題之前，先看一下華為從事方舟編譯器工作的時(shí)間線：

2009年，華為啟動(dòng)5G基礎(chǔ)技術(shù)研究的同時(shí)，開始創(chuàng)建編譯組，第一批海內(nèi)外研究人員加入。

2013年，華為推出面向基站領(lǐng)域的自研編譯器HCC，并正式提出編譯器框架構(gòu)想。

2014年，眾多海內(nèi)外專家加入華為，方舟項(xiàng)目正式啟動(dòng)。

2016年，成立編譯器與編程語言實(shí)驗(yàn)室。

2017年，方舟編譯器上的第一個(gè)Java程序“HelloWorld”跑通。

2018年春節(jié)前一周，方舟編譯器跑通Android系統(tǒng)所有后臺(tái)服務(wù)，并成功移植到手機(jī)。

2019年4月，華為方舟編譯器在P30系列的國(guó)內(nèi)發(fā)布會(huì)上對(duì)外宣布。

那么，方舟編譯器的原理究竟是如何實(shí)現(xiàn)的？

實(shí)際上，華為所謂的“方舟編譯器”與其說是一個(gè)編譯器，不如說是一個(gè)編譯運(yùn)行系統(tǒng)；這個(gè)系統(tǒng)的運(yùn)行需要開發(fā)環(huán)境和終端（也就是智能手機(jī)）的配合，其目的是繞過Android操作系統(tǒng)中App的運(yùn)行所必須依賴的虛擬機(jī)，將Java/C/C++等混合代碼一次編譯成機(jī)器碼直接在手機(jī)上運(yùn)行，徹底告別Java的JNI額外開銷，也徹底告別了虛擬機(jī)的GC內(nèi)存回收帶來的應(yīng)用進(jìn)程掉線—;—;從而最終實(shí)現(xiàn)Android操作系統(tǒng)的流暢度。

正如上文所言，在方舟編譯器的這一實(shí)現(xiàn)過程中，需要解決四個(gè)方面的問題。

第一：將Java代碼直接編譯成機(jī)器碼

就目前的情況來看，Java編譯成機(jī)器碼的過程中，要面臨的難題是Java中的動(dòng)態(tài)語義（與之對(duì)應(yīng)的是靜態(tài)語義，它是通過提前翻譯能夠解決的），靜態(tài)語義指的是確定的語言和意思，而動(dòng)態(tài)語義指的是需要結(jié)合上下文來理解的內(nèi)容—;—;這其中，如果要像編譯靜態(tài)語義一樣去編譯動(dòng)態(tài)語義，很多知乎大神認(rèn)為是根本就不可能的。

而這個(gè)不可能，正是華為在開發(fā)方舟編譯器過程中解決的問題。

具體來說，方舟編譯器通過編譯階段和運(yùn)行階段的雙向加持，將靜態(tài)編譯動(dòng)態(tài)語義最大的兩大難點(diǎn)解決：一是設(shè)計(jì)數(shù)據(jù)模型，二是如何在運(yùn)行時(shí)高效獲得動(dòng)態(tài)信息。

方舟編譯器團(tuán)隊(duì)基本遍歷了Java的動(dòng)態(tài)語義，進(jìn)行了大規(guī)模的數(shù)據(jù)建模。同時(shí)，大大提高了編譯時(shí)動(dòng)態(tài)語義分析的精度，特別是涉及跨語言調(diào)用時(shí)；另外，華為設(shè)計(jì)了一套具有核心專利的動(dòng)態(tài)語義匹配機(jī)制，有效降低了運(yùn)行時(shí)動(dòng)態(tài)語義的開銷。

由此，方舟編譯器能夠?qū)ava代碼編譯成機(jī)器能直接執(zhí)行的語言。華為方面表示，經(jīng)過華為方舟編譯器的App，再也不需要在手機(jī)上編譯了，徹底告別了虛擬機(jī)，從而帶來了媲美甚至超越iOS的Android體驗(yàn)。

第二：解決混合語言的JNI開銷

由于95%的Top應(yīng)用都是Java/C/C++等混合語言編寫而成；因此方舟編譯器還需要干掉混合語言互相調(diào)用帶來的JNI開銷。

這里就涉及到上文提到的一個(gè)名詞IR，它是用來表示代碼的數(shù)據(jù)結(jié)構(gòu)，它是編譯器的各模塊以及相關(guān)工具之間用來傳遞信息的“協(xié)議和通用語言”，也是程序變換和編譯優(yōu)化各種算法的承載體。它是編譯器的“大腦”，直接決定了編譯器的最終效果—;—;因此，它的難度是最高的。

華為方舟編譯器團(tuán)隊(duì)對(duì)IR進(jìn)行了長(zhǎng)達(dá)五年的精雕細(xì)琢，逐漸摸索出“大腦”里每一條神經(jīng)、每一個(gè)神經(jīng)元的信號(hào)規(guī)律，并在此基礎(chǔ)上發(fā)明了一套核心專利，使得不同語言代碼在開發(fā)者環(huán)境中能夠統(tǒng)一編譯成同一套可直接執(zhí)行的機(jī)器碼，從而徹底消除了混合語言互相調(diào)用的開銷。

也就是說華為方舟編譯器可以將混合語言實(shí)現(xiàn)統(tǒng)一的中間表示IR，這就相當(dāng)于同一個(gè)人能夠理解全世界的語言—;—;當(dāng)然，這背后是華為方舟編譯器團(tuán)隊(duì)基于多個(gè)編程語言的深刻理解和大量研發(fā)積累。

第三：在統(tǒng)一IR之外進(jìn)行代碼優(yōu)化

華為方舟編譯器，直接將代碼優(yōu)化從手機(jī)環(huán)節(jié)搬到了開發(fā)者環(huán)境，未來還可能搬到云端。利用開發(fā)者環(huán)境更強(qiáng)大的算力，可以實(shí)現(xiàn)更先進(jìn)和精細(xì)的優(yōu)化算法，來達(dá)到更佳的優(yōu)化效果—;—;華為表示，在很多特定場(chǎng)景代碼優(yōu)化的提升甚至是顛覆性的。

值得一提的是，開發(fā)者使用方舟編譯器，并不需要改變?cè)瓉淼木幋a習(xí)慣。開發(fā)者可以自行開發(fā)代碼優(yōu)化算法，也可以僅通過方舟編譯器預(yù)置的算法進(jìn)行代碼優(yōu)化。未來，華為還將提供代碼調(diào)優(yōu)工具，開發(fā)者可以選擇根據(jù)工具的優(yōu)化建議來調(diào)整代碼，和方舟編譯器配合獲得更優(yōu)的執(zhí)行效果。

第四：解決Android內(nèi)存回收帶來的卡頓問題

為了解決這個(gè)問題，方舟編譯器采用了引用計(jì)數(shù)法（RC，Reference Counting）來進(jìn)行內(nèi)存的實(shí)時(shí)回收，并且配合使用了專門的消除環(huán)算法（消除對(duì)象互相引用帶來的無法回收問題），來避免GC集中式回收帶來的系統(tǒng)卡頓。相比GC，方舟的內(nèi)存回收是實(shí)時(shí)的而非集中式的，且不需要暫停應(yīng)用進(jìn)程，這樣便大大消除了卡頓。

另外，軟件有一個(gè)大家都很熟悉的死循環(huán)，就是電腦被一個(gè)無限循環(huán)的運(yùn)行程序把計(jì)算機(jī)資源占光。這種“死循環(huán)”在軟件中叫“環(huán)引用”。為了從機(jī)制避免手機(jī)內(nèi)存被環(huán)引用“吃掉”，方舟編譯器引入annotation的“告警”標(biāo)示，對(duì)基礎(chǔ)類的環(huán)進(jìn)行標(biāo)注。

當(dāng)然，Java程序員也可以對(duì)業(yè)務(wù)代碼中的環(huán)進(jìn)行標(biāo)注。經(jīng)過豐富的實(shí)踐驗(yàn)證，方舟這種機(jī)制可以減少大部分程序中環(huán)的出現(xiàn)。另外一方面，方舟編譯器在運(yùn)行狀態(tài)下引入了高效的環(huán)回收機(jī)制，允許有選擇的智能回收某個(gè)APP的內(nèi)存占用，這對(duì)傳統(tǒng)的環(huán)回收算法是一個(gè)改進(jìn)。

總結(jié)來看，面對(duì)現(xiàn)有的Android系統(tǒng)在代碼編譯、運(yùn)行、IR、內(nèi)存回收等四個(gè)層面的問題，華為方舟編譯器分別給出了自己的解決方案，這其中的核心創(chuàng)新點(diǎn)是混合語言的統(tǒng)一中間表示和完全靜態(tài)編譯，但更重要的是華為在解決Android操作系統(tǒng)App運(yùn)行問題的嶄新思路，以及為了實(shí)現(xiàn)這種思路而敢于大力投入的勇氣。

總結(jié)

方舟本質(zhì)上不僅僅是一個(gè)編譯器，而是一個(gè)編譯系統(tǒng)，它需要通過用戶終端和開發(fā)者的共同支持。

對(duì)于華為手機(jī)用戶來說，華為在手機(jī)終端中已經(jīng)用方舟編譯器替代了Android system-server的所有后臺(tái)服務(wù)，這一項(xiàng)就已經(jīng)足夠讓華為EMUI比其他Android系統(tǒng)更快一步—;—;根據(jù)華為官方測(cè)試，方舟編譯器提升手機(jī)系統(tǒng)操作流暢度高達(dá)24%，系統(tǒng)響應(yīng)性能提升44%。

當(dāng)然，華為要想充分發(fā)揮方舟這個(gè)編譯系統(tǒng)的實(shí)力，還離不開開發(fā)者在開發(fā)層面對(duì)方舟編譯器的大力支持，這本質(zhì)上是華為在現(xiàn)有Android開發(fā)生態(tài)之外另辟蹊徑打造的一個(gè)全新開發(fā)環(huán)境—;—;它究竟能否得到開發(fā)者的支持，還需要等華為將其開源之后才能有答案。