解讀| 華為方舟編譯器是如何實現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.
--
All Comments