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