華為造方舟，安卓的性能革命或將拉開帷幕

近日，華為在上海舉行了P30系列的國內發布會，除了揭曉了這款產品的相關信息之外，這場發布會還有一個極可能會造成深遠影響的新技術——方舟編譯器。根據華為公布的信息顯示，方舟編譯器通過架構級優化，將顯著提升APP的運行效率，尤其是全程執行機器碼，能夠更為高效的運行應用，徹底解決安卓應用「邊解釋邊執行」所造成的低效率。

華為造了一個「方舟」

余承東在發布會上表示，方舟編譯器可讓系統操作流暢度提升24％，系統響應速度提升44％，第三方應用重新編譯後流暢度可提升60％。並且此次推出的方舟編譯器將面向業界開源，希望App開發廠商能夠儘快使用。

從目前社交媒體上出現的一段華為P30 Pro與三星Galaxy S10 ，使用方舟編譯的微博APP預載入速度對比視頻中，我們不難看出，採用麒麟980主控的華為P30 Pro在微博圖片載入速度上，完成了對三星Galaxy S10 的碾壓。

想要明白「方舟編譯器」到底是什麼東西，首先需要明確幾個概念。無論是手機、PC，還是其他設備都是負責執行已經被計算機語言編好的程序，而程序則是計算機要執行的指令的集合。目前，計算機語言分為程序員用來編程的高級語言（人類使用）、由於0和1組成的二進位機器語言（機器使用），以及根據機器硬體編譯成人能看懂的彙編語言。

編譯器的作用就是將JAVA、C ，或者彙編語言翻譯成機器語言，將程序員寫的源代碼（SourceCode）轉換成CPU能夠直接處理的機器碼（NativeCode），簡而言之，就是在人與機器之間搭建一座橋樑，或者充當人和機器之外的翻譯。編譯器技術作為計算機科學的明珠，它的開發門檻可以說是相當之高，要懂得x86、x64、ARM架構，以及它們的指令集MIPS、RCIS等眾多知識才行。

Android編譯器的發展歷程

很明顯，華為的方舟編譯器就是一個高水準的「翻譯工具」，但是編譯器在Android系統中到底起了什麼樣的作用，就要從Android的發展歷程中尋找答案。2008年9月，谷歌正式發布了Android 1.0，但大家都知道的是，Android是基於Linux內核的操作系統，底層是Linux用於硬體驅動和資源調配，在中間加上了Java虛擬機，其表面層是Android運行庫。

在Android 2.2之前，Android的Java虛擬機是Dalvik。Dalvik支持轉換為.dex格式的Java應用程序，每次運行程序的時候，Dalvik負責將dex文件翻譯為機器碼交由系統調用，但Dalvik的劣勢，就是這是一種適合內存與處理器速度有限系統的解決方案。在這一階段中，Android被iOS以及塞班完全碾壓，差不多就只剩下了開源這一個優點。

到了Android 2.2，由於Android系統的低效率，谷歌拿出了即時編譯技術JIT(Just In Time Compiler)。使得在App運行時，每當遇到一個新類，JIT編譯器就會對這個類進行編譯，而經過編譯後的代碼，會被優化成相當精簡的原生型指令碼（即native code），這樣在下次執行到相同邏輯的時候速度就會更快，而這其實就是余承東所說的「邊解釋邊執行」模式。

但很遺憾的是，即便JIT讓Dalvik的性能提升了300%以上，但是由於JITD的策略是dex文件翻譯成本地機器碼，都需要發生在應用程序的運行過程中，並且應用程序每一次重新運行時，都要做重做這個翻譯工作。也使得JIT Dalvik的組合還是與高效無緣，依然被iOS吊打。

有鑒於此，在Android 4.4時谷歌推出了新的虛擬機ART（Android Runtime），來解決之前的Java代碼執行效率太低的問題。ART使用的編譯器被稱為AOT（Ahead Of Time），也就是預編譯策略，指的是App在第一次安裝時，Java代碼就會被預先編譯成機器碼，使其成為真正的本地應用。但問題就是完全的AOT模式，讓App安裝和系統升級之後的優化非常耗時，同時被優化的App會佔用額外的存儲空間。但在這一時期中，Android的流暢度則有了一定的提升。

到了Android 7.0之後，谷歌重新引入了JIT編譯技術，形成了AOT JIT 解釋執行共存的模式。也免除了單獨使用某一種解決方案帶來的缺陷，解釋執行是為了輔助優化AOT結果，避免進行無腦的全量編譯，而JIT則是為了對ART進行代碼分析，使其能夠在運行時動態優化。並且在Android Q上，谷歌結合AI技術提供了系統預測感知功能，使得App在安裝時，系統就能知道常用代碼會被提前編譯。

在「三劍合璧」的模式之下，如今的Android已經比4.X、5.X時代要高效很多。但是即便是這樣的Android，在iOS面前依然是略遜一籌。使用C語言開發的iOS是不需要虛擬機的，再搭配專用的開發工具Xcode，以及編譯效率超高的LLVM編譯器，實現了只要APP運行就能夠自動將整個程序編譯，然後轉換為機器碼的靜態編譯。當然，這也造成了同一款APP，iOS端包體要明顯大於Android端的情況。

簡而言之，Android不改變以虛擬機為中心的運行模式，其實很難從根源上解決卡頓的問題。

方舟會是扇動Android生態的蝴蝶嗎？

回到方舟編譯器上，由於目前華為還沒有開源代碼，關於其到底是如何實現系統操作流暢度提升24％，系統響應速度提升44％的效果，暫時還無法明確。不過，華為可能採用的路徑差不多有三條，其一，是繼續在目前Android這套AOT JIT 解釋執行的基礎上進行優化，繼續在應用安裝後，後台靜默編譯成機器碼的路子上前進，只不過華為工程師實力出色，讓方舟編譯器成為了一個「頂級翻譯」。

其二，是學習iOS採用的LLVM編譯器的模式，將App在開發階段就通過伺服器完成，讓服務端或者雲端完成本來需要手機本地的工作。使得App變成可安裝的APK文件時，直接就把Java代碼編譯為了機器碼。

其三，是方舟編譯器雖然是叫著編譯器的名字，但實質上是將編譯器和Runtime（指將數據類型的確定，由編譯時推遲到了運行時）全部替換成華為自己的解決方案。

由於Android需要更高的兼容性，因此在現有Android策略的基礎上提升效率的意義其實並不大，並且第一種可能就代表著華為這次的宣傳只是微創新。

其他兩種猜測的可能性則相對較高，而第二種也就是打包APK的時候，就直接變成機器碼的策略，因為ARM架構的不同世代之間與不同廠商魔改會產生兼容性問題，進而削弱App的跨平台能力，與Android本身的高兼容性南轅北轍。但是，華為也在發布會上強調，需要「在華為自己的應用商店下載App」，換句話來說是可能會選擇犧牲兼容性，來提升流暢度。

如果第三種猜測屬實，替換Runtime基本上則代表了華為這次是實實在在的「分裂Android」。根據谷歌在2012年修改的Android開發協議的新條款顯示，「你同意將不會採取任何可能造成Android分裂的行為，包括但不限於：發布、參與創建，或者以任何方式從SDK派生其他的軟體開發工具。」

考慮到P30系列的海外發布會上並沒有公布方舟編譯器，而是選擇在國內首發，因此未嘗就沒有利用GMS服務沒有進國內市場的空子。考慮到華為想要打造自家OS已經不是一個新聞了，因此推出一套屬於自己的底層開發標準，也並不是不能理解。

但就像之前說的那樣，一個操作系統想要成功，最主要是在底層之上的中間層、應用層上，搭建屬於自己的各式介面和服務，需要說服儘可能多的開發者支持，完成操作系統的主流化，而之前Windows Mobile和BlackBerryOS的失敗，也幾乎都是死在這一步上。方舟編譯器就相當於是在Android系統的基礎上，實現「忒修斯之船」的操作，通過數年的過渡將.APK慢慢變成.HUAWEI。

至於說分裂Android的行為可能引來谷歌的制裁，其實並不是一個大問題。除了谷歌自己也開始準備全新的Fuchsia OS之外，去年才剛剛因為Android強制捆綁的GMS服務，吃了歐盟一張大罰單，被迫改變了Android的商業模式。因此谷歌用取消GMS服務來制裁華為，很難在除美國之外的地區獲得支持，但華為手機又根本就不在美國市場銷售。

當然，以上均為我們不負責任的猜測，至於方舟編譯器的具體情況，則還有待華為方面將代碼公布出來之後，才能見分曉了。

【本文圖片來自網路】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！