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

隨著 2019 華為開發(fā)者大會的臨近，華為消費(fèi)者業(yè)務(wù) CEO 余承東此前在 P30 國內(nèi)發(fā)布會上宣布的 “能夠?qū)崿F(xiàn) Android 性能革命” 的方舟編譯器也即將進(jìn)入到開源階段。雖然此前在 4 月份華為已經(jīng)就方舟編譯器進(jìn)行了介紹，但人們更加關(guān)心的是：華為方舟編譯器的革命性到底體現(xiàn)在哪里？

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

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

Java 語言是在 1995 年 5 月發(fā)布的，它的一個(gè)重點(diǎn)特點(diǎn)就是可以跨平臺操作，而且需要借助虛擬機(jī)機(jī)制來解釋源代碼并調(diào)度硬件資源；但同時(shí) Java 是一種預(yù)編譯語言，需要先在開發(fā)者環(huán)境中將源代碼（Source Code）轉(zhuǎn)換成字節(jié)碼（Byte Code），然后在設(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)行得快。

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

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

Android 2.2（2010 年）：引入 JIT（Just In Time）即時(shí)編譯機(jī)制，當(dāng) App 運(yùn)行時(shí)，會將用戶經(jīng)常使用的功能編譯為機(jī)器能直接執(zhí)行的 010101 機(jī)器碼，不用一句一句地去翻譯。當(dāng)出現(xiàn)不常用的功能時(shí)，再調(diào)用解釋器來翻譯；這樣速度加快，但每次啟動 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)長，而且占用手機(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ǔ)?。皇謾C(jī)上的虛擬機(jī)+編譯器+解釋器本身不僅占用硬件資源，還無法最大發(fā)揮軟件運(yùn)行性能。正因如此，所以絕大部分手機(jī)廠商只能無奈的通過簡單粗暴提升 Android 手機(jī)的內(nèi)存和存儲空間，來彌補(bǔ)虛擬機(jī)的弊端。

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

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

2、為了與 C/C++ 等代碼進(jìn)行交互，Java 原生接口（Java Native Interface，簡稱 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è)部分：前端 Front End，主要負(fù)責(zé)將源代碼翻譯成 IR（Intermediate Representation）；中端的 Optimizer 主要負(fù)責(zé)代碼優(yōu)化，將前端翻譯過來的 IR 代碼優(yōu)化得更高效；后端 Back End 則將優(yōu)化后的 IR 編譯成 101010 的機(jī)器碼——為了防止生態(tài)過于碎片化，Android 只為第三方開放了簡單的編譯代碼優(yōu)化模板，代碼優(yōu)化空間有限。

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

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

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

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

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

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

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

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

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

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

那么，方舟編譯器的原理究竟是如何實(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 中的動態(tài)語義（與之對應(yīng)的是靜態(tài)語義，它是通過提前翻譯能夠解決的），靜態(tài)語義指的是確定的語言和意思，而動態(tài)語義指的是需要結(jié)合上下文來理解的內(nèi)容——這其中，如果要像編譯靜態(tài)語義一樣去編譯動態(tài)語義，很多知乎大神認(rèn)為是根本就不可能的。

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

具體來說，方舟編譯器通過編譯階段和運(yùn)行階段的雙向加持，將靜態(tài)編譯動態(tài)語義最大的兩大難點(diǎn)解決：一是設(shè)計(jì)數(shù)據(jù)模型，二是如何在運(yùn)行時(shí)高效獲得動態(tài)信息。方舟編譯器團(tuán)隊(duì)基本遍歷了 Java 的動態(tài)語義，進(jìn)行了大規(guī)模的數(shù)據(jù)建模。同時(shí)，大大提高了編譯時(shí)動態(tài)語義分析的精度，特別是涉及跨語言調(diào)用時(shí)；另外，華為設(shè)計(jì)了一套具有核心專利的動態(tài)語義匹配機(jī)制，有效降低了運(yùn)行時(shí)動態(tài)語義的開銷。

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

由于 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ì)對 IR 進(jìn)行了長達(dá)五年的精雕細(xì)琢，逐漸摸索出 “大腦” 里每一條神經(jīng)、每一個(gè)神經(jīng)元的信號規(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ā)積累。

華為方舟編譯器，直接將代碼優(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)化效果——華為表示，在很多特定場景代碼優(yōu)化的提升甚至是顛覆性的。

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

為了解決這個(gè)問題，方舟編譯器采用了引用計(jì)數(shù)法（RC，Reference Counting）來進(jìn)行內(nèi)存的實(shí)時(shí)回收，并且配合使用了專門的消除環(huán)算法（消除對象互相引用帶來的無法回收問題），來避免 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)示，對基礎(chǔ)類的環(huán)進(jìn)行標(biāo)注。

當(dāng)然，Java 程序員也可以對業(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)存占用，這對傳統(tǒng)的環(huán)回收算法是一個(gè)改進(jìn)。

總結(jié)來看，面對現(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)這種思路而敢于大力投入的勇氣。

正如記者所言，方舟本質(zhì)上不僅僅是一個(gè)編譯器，而是一個(gè)編譯系統(tǒng)，它需要通過用戶終端和開發(fā)者的共同支持。對于華為手機(jī)用戶來說，華為在手機(jī)終端中已經(jīng)用方舟編譯器替代了 Android system-server 的所有后臺服務(wù)，這一項(xiàng)就已經(jīng)足夠讓華為 EMUI 比其他 Android 系統(tǒng)更快一步——根據(jù)華為官方測試，方舟編譯器提升手機(jī)系統(tǒng)操作流暢度高達(dá) 24%，系統(tǒng)響應(yīng)性能提升 44%。

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

記者按：本文參考資料《華為新貴！方舟編譯器的榮光和使命》，點(diǎn)此查看。