[新聞] 解讀| 華為方舟編譯器是如何實現Android

[ohmylove347 (米特巴爾)]

解讀| 華為方舟編譯器是如何實現Android 性能革命的？

2019 年4 月11 日，在上海的華為新品發布會上，除了可以拍月亮的華為P30 系列，余承東還親自拋出了兩項軟件層面的“重磅炸彈”，分別是方舟編譯器和EROFS 超級文件系統；其中，華為方舟編譯器可以實現“架構級優化和顯著提升性能”，可以解決安卓程序“邊解釋邊執行”的問題，從而被余承東稱之為“安卓性能革命”。


發布會結束之後，華為方舟編譯器引起了外界的熱議。

那麼，方舟編譯器究竟是什麼？它的“革命性” 到底體現在哪裡？面對這些問題，華為終於在兩週之後舉行了媒體沙龍，對方舟編譯器進行了更加細緻的解讀。

Android 生態中編譯器的工作原理

在了解方舟編譯器之前，我們必須得首先了解Android 操作系統中的編譯器的運行機制。

雷鋒網從VirtualXposed/太極的作者weishu處了解到，當前Android平台的絕大多數應用是使用Java語言寫的，CPU只能理解彙編指令，無法直接識別Java語言的虛擬機指令；為了讓CPU能運行Java語言編寫的程序，一般有兩種辦法：

引入一個中間層，這個中間層負責Java 代碼的執行，然後這個中間層本身編譯為CPU 能理解的彙編指令，也就是CPU -> 中間層-> Java 代碼。如果這個中間層採用Java 語言直接作為輸入，理解一句Java 語句就把Java語言翻譯一下讓CPU 執行一段，我們一般稱這種模式為「解釋執行」。毋庸置疑這種方式效率是相當低效的。

直接把Java 語言翻譯成CPU 能理解的機器語言。這裡又有兩種方式：第一，在程序運行之前直接把Java 代碼編譯為機器語言。這種模式稱之為AOT（Ahead of time）編譯；第二，在程序運行起來之後，實時地把Java 語言編譯為機器語言然後執行。這種模式稱之為JIT（Just in time） 編譯。

具體在Android 平台上，代碼編譯經歷了數個階段。

在Android 5.0 正式採用ART 之前，Android 採用的是解釋執行+ JIT 的方式執行Java 代碼。在這個階段是貨真價實的「邊解釋邊執行」的模式，代碼效率相當低下，再加上那時候同樣表現不行的GC（垃圾回收），Android 非常難用。


在Android 5.0 至Android 6.0 階段，Google 推出了ART（Android Runtime）來解決之前的Java 代碼執行效率問題。這個階段採用的是完全AOT 模式；Android 應用在安裝的時候，系統會把所有Java代碼提前編譯為機器碼。這種模式有兩個缺點：

安裝速度巨慢。即使是高通驍龍855 採用AOT 模式編譯一下安裝包比較大的應用（如支付寶）可能就要一分鐘。而那個時候的CPU 並不如現在，安裝一個應用需要很長時間。更要命的是，系統OTA 開機會對所有的應用執行AOT 操作，這時候開機速度可能需要很長時間。

佔用磁盤空間，Java 代碼編譯為機器碼之後體積會急劇膨脹。

到了Android 7.0，Google 做了很大的改進；這一改進是基於這樣一個事實：我們使用一個應用的時候，基本每個人只使用它一小部分功能，為什麼要把所有代碼全編譯呢？因此只編譯用戶經常用的那部分代碼就OK 了，這樣安裝的時候速度比較快，等用戶啟動的時候系統就能知道哪部分代碼經常被執行，把這部分代碼編譯為機器碼，運行起來速度也快。

於是Google 又引入了JIT，這時候的執行模式是AOT + JIT + 解釋執行。具體來看：

應用安裝的時候不執行AOT 編譯，安裝速度飛快。初次使用應用的時候沒有機器碼，因此只能解釋執行。

應用運行起來之後，系統收集經常被運行的代碼的信息，做兩件事：1）在必要的時候在運行時直接把Java 代碼編譯為機器碼（JIT），然後使用機器碼執行提高運行效率。2）把這個「經常被運行的代碼信息保存起來」。

設備空閒的時候，系統拿出應用運行時候保存的「熱點代碼信息」直接把這些代碼編譯為機器碼（AOT）。

Android 8.0 上改進了解釋器，解釋模式執行效率大幅提升；Android 10.0 上提供了預先放置熱點代碼的方式，應用在安裝的時候就能知道常用代碼會被提前編譯。可以看到，當前Android 平台的執行模式在空間佔用+安裝速度+運行速度上已經達到了一個很好的平衡。

總結來看，目前的Android 採用的是解釋執行+ 還算可以的JIT + AOT 的綜合模式；但並沒有擺脫這樣一個前提，即應用在被打包成APK 的時候，採用的還是Java 代碼。換句話說，在APK 變成用戶可應用的過程中，還經歷了一個在Android 系統內部的編譯過程，這是一個繞不過的坎。


按照華為方面在媒體沙龍中的解讀，這個在現有Android 中繞不過去的坎，被稱為虛擬機（Virtual Machine，簡稱VM），它包含翻譯器和編譯器，其目的就是把Java 高級語言轉換成機器能懂的語言——這一轉換過程導致卡頓，並且VM 的統一回收內存垃圾額也會帶來卡頓。

華為方舟編譯器究竟改變了什麼？

首先，方舟編譯器是配合華為EMUI 9.1 操作系統而打造的一個編譯工具。

按照華為方面的說法，雖然方舟編譯器是在2019 年4 月11 日發布，但是華為早在5 年前就開始佈局，2013 年推出了自研編譯器HCC，2014 年編程大神Fred Chow 加入，擔任華為編譯器技術首席科學家，2016 年華為成立編譯器與編程語言實驗室，投入了數百的專家團隊經歷了多次嘗試，才在EMUI 9.1 上實現了機器代碼的翻譯。


按照上述Android 操作系統的代碼運行邏輯，華為編譯器最大的優勢在於，它繞過了VM。

簡單來說，在百人專家團隊的打造下，華為方舟編譯器可以將高級語言（Java）直接變成機器碼，無需再通過Android 操作系統中內置的VM 編譯器。按照華為方面的說法：方舟編譯器編譯的應用在開發階段就已完成；也就是說，只要是經過編譯器編譯的應用，在應用市場上上架了以後，用戶下載APK 的就是編譯過的了。


換句話說，通過方舟編譯器，開發者的應用在下載之前就已經轉化成為機器可以識別的代碼，因而可以在手機上快速安裝、啟動和運行，而無需在經過VM 的編譯——某種程度上，方舟編譯器是將編譯過程提前到應用開發階段，從而大幅度減少了智能手機和操作系統的運行負擔。

按照華為方面的說法，採用華為編譯器之後，提升效果如下：

EMUI 9.1 僅僅對系統組件System Server 應用了方舟編譯器之後，系統流暢速度提升了24%，系統響應速度提升了44%；

第三方應用（目前採用了新浪微博極速版）的操作流暢度提升了60%。

不可忽視的是，實際上，要想實現華為所言的效果，就首先需要第三方的應用開發者採用方舟編譯器對自家的App 提前進行改造，從而能夠上架華為應用商店——這也是余承東在4 月11 日的發布會呼籲開發者積極參與的原因。

除了代碼編譯，方舟編譯器也提供了更高效的內存機制，它與Android 內存回收的不同之處在於：

內存管理是程序開發與運行時需要重點考慮的部分，也和系統流暢度息息相關。Android 在內存回收上採用集中回收機制，發聲全局回收時更需要暫停應用，這也是隨機卡頓的根因之一。而方舟編譯器提供了更高效的內存回收機制，回收時無需暫停應用，隨時用隨時回收，大大提高運行速度。


另外，在方舟編譯器的編譯環境下， 還可以對代碼進行優化。目前，由於Android ART 的AoT 和JIT 動態編譯因為是運行在手機上，受資源所限，因而只能使用簡單的優化算法。而方舟編譯器由於是在應用開發階段進行編譯，所以可以允許不同應用靈活採用不同的編譯優化方案，而且因為在開發環境編譯不會受到手機性能的限制，可以使用更多先進的優化算法，從而使得每個應用的性能達到最佳。

2019，全面開源

其實，在4 月11 日的發布會上，華為方面已經表示，方舟編譯器也將開放給第三方合作夥伴，希望共同構建開發者生態的“方舟朋友圈”。

目前，華為已經宣布方舟編譯器會從2019 年全面開源；其中，華為將在2019 年8 月的華為終端開發者大會宣布方舟編譯框架代碼開源，後續會在2019 年11 月的綠盟開發者大會實現完整方舟編譯器代碼開源。

對於華為方舟編譯器的開源，雷鋒網將保持關注。

雷鋒網(公眾號：雷鋒網)注：本文部分內容編自知乎平台作者weishu的回答內容，已經獲得作者授權。

https://m.leiphone.com/news/201904/oshefuZTLnU00mJO.html

心得：好吧，其實我整天都看不懂，只知道好像很厲害
有厲害的人可以解釋個嗎感謝
這樣子卓卓是不是在效能上要成功反超果果了呢！
太令人期待啦！

PS. 這應該不是偏頗的媒體吧…拜託別水桶我

-----
Sent from JPTT on my Google Pixel 2.

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.10.20.223
※ 文章網址: https://www.ptt.cc/bbs/MobileComm/M.1556252257.A.C08.html
推 Abre        : 我看花粉俱樂部都在主打這東西
→ Abre        : 但認真問 這種廠商自主"優化"的東西 真的會比原裝
→ Abre        : 來的好嗎?
噓 maplefff    : 立場偏頗，建議水桶
不是吧！這科普類的文章欸…
推 airmike     : 意思不就是直譯轉成全編譯? 白話簡化一點就是Java
→ airmike     : 跟直接編出機器碼執行的速度差異
推 democrat    : 一堆Buzz word 就可以把人唬住了嘿嘿，實際上這篇什
不是可以繞過虛擬機嗎？還是我轉了篇廢文…
→ democrat    : 麼都沒講，跟你的主管一樣
※ 編輯: ohmylove347 (101.10.20.223), 04/26/2019 12:21:46
※ 編輯: ohmylove347 (101.10.20.223), 04/26/2019 12:22:59
→ kuma660224  : 其實就是放棄安卓的虛擬機優點
→ sakala      : 第三方沒用有意義嗎？
→ kuma660224  : 估計大部分軟體開發廠商不會用這種東西
→ kuma660224  : 谷歌當然知道虛擬機機制不是最快
推 airmike     : 全編譯的壞處就是portability差 很快就會發現APP在
→ kuma660224  : 但它可跨足不同指令集...
→ airmike     : 不同OS不同build 執行不起來 或是效果不同
→ airmike     : Google不是笨蛋 當初用Java抽象化還是有其理由
→ kuma660224  : 要追求最快，代價就是破壞無敵相容性
推 BDrip       : 編譯器會不會藏洞(?
→ kuma660224  : 這是取捨問題. 不想被硬體層綁死
推 IvanLord    : 沒有什麼卵用
推 skyangle0607: 單眼造假，p圖造假，誇大宣傳，種種因素加起來當然
→ skyangle0607: 大賣
推 E6300       : 方舟=特洛伊
→ labbat      : 立場偏頗，夾帶政治立場，建議水桶
→ lukesfather : 先說我是外行的，所以要大家重新編碼去經過華為審
→ lukesfather : 核過的平台上架去讓android手機加速了解程式指令嗎
→ lukesfather : ？
→ lukesfather : 如果理解沒錯的話，那還不如好好期待fushia之類的
→ lukesfather : 新編碼系統。 還不用擔心其壯大後強迫開發者配合中
→ lukesfather : 國政府法令。
推 autoupdate  : 該不會ㄧ打開又是某國外的套件
推 striving    : 用過微博極速版，真的很快 …
推 q30339      : 他開源 不用配合
推 kci9kimo    : 繞過了VM，沒有相容性問題？安全性問題？我是不信
推 nk950357    : 坐等mainline大神解釋
→ kci9kimo    : Android又不是華為的,再怎樣弄都是非正式,除非G願意
→ chiguang    : 黨說你實現了，你就實現了
推 Kreen       : 坦白說這真的很屌～
推 ededws1     : 還要開發者自行修改程式碼，而且還只能搭配華為商店
→ ededws1     : 這麼小的市場還不如等Google改架構
→ kiazo       : 有1好沒2好
推 kci9kimo    : 真的要實做絕對可以,問題是太專用了
推 aoc902001   : 不明覺厲
→ kci9kimo    : 如果我是一個軟體商,怎可能為了小眾另外改寫程式
推 kci9kimo    : 話說這種文章，是作者自己產採訪發的，還是廠商付錢
→ kci9kimo    : 多看幾次，越看越覺得真的是「寫的」好好
推 azirebb     : 方舟編譯器幫你編譯，順便植入監控程式碼
→ wheateardoll: 華為覺得自己的架構師比Google強 哈哈哈
推 jaredjj     : 又是華為還是雷鋒網更是簡體字原文，立場偏頗捧華
→ jaredjj     : 為技術，版主在幹嘛還不刪文
推 marc47      : 只有在第一次執行上有加快吧，後來的原本android就
→ marc47      : 是跑已經編譯過的
→ qazwsx0128  : 以後用中文寫程式    樓下會怕機器看不懂switch嗎
噓 Cliffx      : 鬼扯
推 googlexxxx  : ART 本身就是直譯器還繞一圈，況且上架Google本身是
→ googlexxxx  : 依照白皮書開發的，除非亂搞否則早就改進很多了。文
→ googlexxxx  : 中一直提Java 是說甲骨文的還是Open Java 兩者又是
→ paul40807   : 新android手機為什麼剛買到的那幾天會續航力崩壞跟
→ googlexxxx  : 不同東西了！這明顯是廣告文吧！因為中國沒有Google
→ paul40807   : 超級發熱 但過幾天又好了 就是那時候需要耗費大量運
→ googlexxxx  :  play 你就偷了人家的東西說是自己的。
→ paul40807   : 算資源將App編譯成機器碼 才會導致這個情形
→ paul40807   : 所以Android手機剛買到必須要使用個一兩天以後再來
→ paul40807   : 做效能測試會比較準確 尤其是續航力測試
→ wenli978    : 把Compiler基本功能包裝一下講的很炫砲
→ aljinn      : 這篇應該沒有很難讀懂吧 只是內容正不正確…？
推 googlexxxx  : 就騙不懂的啊，你如果搞蘋果那一套看你怎麼比
→ birdy590    : 以為 Google 自己沒能力做喔? 現在的狀況是評估過的
推 hegemon     : OpenJDK跟OracleJDK沒有差太多，Google為了專利問題
→ hegemon     : 是使用OpenJDK
→ googlexxxx  : Google Android Wiki 裡面有系統直譯的演變 ART
→ vsbrm       : 讓人聯想到百度SDK開發軟體事件
推 googlexxxx  : 看看有多少老闆要讓你繞過VM 的沙盒環境直接上機
推 aresa       : 這是一個大家都停下來等紅燈，你他媽直接開過去的概
→ aresa       : 念
噓 wangtenghong: 應有更適合的板吧? 如Linux或Programming
推 googlexxxx  : areas 大比喻的好
→ googlexxxx  : 更正aresa
推 ShieChang   : 直接用機器碼的缺點 1.難以事前檢查是否含有惡意程
→ ShieChang   : 式 2. app優化只能靠app開發者，無法靠手機廠
推 googlexxxx  : 沒那麼不堪啦！你還是會在Google 的開發環境下去進
→ googlexxxx  : 行
噓 sam812      : 廣告文 滾
→ caonimashen : 這不就python的玩法 要效率的部分調用c
推 jj840917    : 這篇很不親民 你要懂OS Compiler和Programming La
→ jj840917    : nguage才能看懂
噓 BirthStone  : po錯版
推 newclicker  : 幫本文翻譯:俺大軍企為了以下各種用途之執行效率
→ newclicker  : p月,銀河..etc https://i.imgur.com/pO5LQUN.jpg
→ newclicker  : 不可名狀應用.. https://i.imgur.com/vRGW5rT.png
→ newclicker  : 發現傳統VM的直譯執行效率不彰,已不敷使用,
→ newclicker  : 所以致敬了yoyodiy的手法~繞過去~,全世界都驚呆了呢
→ newclicker  : https://i.imgur.com/oIzUhmx.png
→ newclicker  : 這樣翻譯大家有沒有秒懂呢?
噓 blueweak    : 我的老天 繞過VM也可以拿來說嘴...這很中國
噓 princeguitar: 很會吹 優異的中國天職
推 jj840917    : 如果是真的直接繞過VM轉成Machine code的話真的很
→ jj840917    : 猛吧 怎麼會說是說嘴
推 kira925     : 就是針對華為限定的特別最佳化JIT...
推 kevin99801  : 除了提早翻譯成機器碼才上架商店之外好像看不出其他
→ kevin99801  : 很明顯的不同，優點就是文中所說，在翻譯的時候因為
→ kevin99801  : 是在開發端所以可以用更好的演算法去做翻譯優化，缺
→ kevin99801  : 點就是先翻好的東西相容性可能不如在手機端上翻好。
推 kira925     : 講了一堆東西 其實就是重新發明輪子 只有對華為有用
推 mikotofans  : 其實這篇也只是猜測方舟的機制
推 kira925     : 畢竟華為並沒有公開阿
→ mikotofans  : 怎麼感覺樓上一堆方舟工程師
推 newclicker  : 華為:俺大軍企覺得現行用Java VM的模式導致
→ newclicker  : 自己的APK很容易被解包,原始碼都被看光光
→ newclicker  : 要藏小祕密幹些甚麼勾當都不太方便
→ newclicker  : 有了方舟,我想怎麼加殼都可以,全世界都說好棒棒呢
→ kira925     : 就這篇的內容評論阿
→ kira925     : 至於要質疑這篇 那你也要拿出點東西說明方舟幹了什
→ kira925     : 麼與眾不同的東西
→ kira925     : 我想應該不會是"我不知道他們幹了什麼 但我知道很屌
推 loking      : 中國的用詞真微妙，邊翻譯邊執行，是指直譯器嗎？
→ kuma660224  : 是JIT JustInTime吧
→ kuma660224  : 現在遊戲繪圖Shader都是JIT編譯
→ kuma660224  : 因為無法預測GPU用什麼指令集無法事先編譯
→ kuma660224  : 載入時順便編譯他（透過硬體廠商驅動處理）
噓 gn02827186  : 台灣隨便一個小學生都做得出來還在吹
推 kira925     : ....亂嘴這個就不對了
噓 CelestialRel: 這三小革命性... 不就把JAVA變得和C一樣而已嗎...
→ robber1234  : 繞過去變成C一樣，那相容性,可移植性就沒了
→ robber1234  : 系統升級改一次,不同SoC改一次,好厲害的方舟
→ azuel       : 全面重新擁抱碎片化？
推 blackstyles : 不就變成C........然後包一堆toolchain......
噓 fewhy       : 繞VM就是個假java了啊
→ fewhy       : 這種東西google會準嗎 科科
→ soundwin    : 買iPhone 就好了
→ zzro        : 嗯? 繞過VM的VM語言 你說你做個硬體來硬解我還比信
推 aa1477888   : 文中指出的缺點就是最大的缺點
→ aa1477888   : 你App經過方舟之後 For華為的手機平板沒問題
→ aa1477888   : 當你要放到其他裝置 即便是一樣的Android版本
→ aa1477888   : 也不能保證跑出相同結果來