周末在家休息，朋友在刷朋友圈，突然她問我：

鴻蒙OS回顧

2019年8月9日華為開發者大會上，華為消費者業務CEO余承東正式宣布發布自有作業系統鴻蒙，內核為Linux內核、鴻蒙微內核和LiteOS。未來將擺脫Linux內核和LiteOS，只有鴻蒙微內核。

鴻蒙（英語：Harmony OS，開發代號Ark）是華為自2012年開發的一款可能兼容Android app的跨平台作業系統。

圖：鴻蒙OS的四大技術特性

1．分布式架構首次用於終端OS，實現跨終端無縫協同體驗

2. 確定時延引擎和高性能IPC技術實現系統天生流暢

3. 基於微內核架構重塑終端設備可信安全

4. 通過統一IDE支撐一次開發，多端部署，實現跨終端生態共享

什麼是跨平台

在以前，平台 ≈ 作業系統。所以，傳統意義上的跨平台即不依賴於作業系統，也不依賴硬體環境。一個作業系統下開發的應用，放到另一個作業系統下依然可以運行。

但是隨著科技的發展，平台 ≈ 作業系統已經不成立了，就像華為推出的鴻蒙OS，他可以支持到多種多樣的設備，如手機、手錶、電腦、汽車、智能家居設備等。

所以，今天我們談的跨平台，指的是跨設備。即平台 ≈ 設備

所以，華為希望鴻蒙OS可以運行在各種各樣的設備上，所以，鴻蒙OS必然需要具備跨平台的能力。

而且，鴻蒙想要做的不僅僅是作業系統可以跨平台，更重要的是要讓用戶和開發者真正的感受到跨平台。

所以，跨平台作業系統鴻蒙的目的是：使開發者能夠聚焦自身業務邏輯，像開發同一終端一樣開發跨終端分布式應用，也使最終消費者享受到強大的跨終端業務協同能力為各使用場景帶來的無縫體驗。

Java實現跨平台

先來說說Java是如何實現跨平台的。

Java對於跨平台的支持，就像對安全性和網絡移動性的支持一樣，是分布在整個Java體系結構中的。其中扮演者重要的角色的有Java語言規範、Class文件、Java虛擬機（JVM）等。

首先，在Java語言規範中，規定了Java語言中基本數據類型的取值範圍和行為。其次，所有Java文件要編譯成統一的Class文件。最後，通過Java虛擬機將Class文件轉成對應平台的二進位文件。

Java的平台無關性是建立在Java虛擬機的平台有關性基礎之上的，是因為Java虛擬機屏蔽了底層作業系統和硬體的差異。

想要運行一段Java代碼，要經過多個步驟，將Java原始碼轉換成機器可以執行的機器代碼，這個過程主要由虛擬機來完成。

在著名的HotSpot虛擬機中，主要有解釋執行和即時編譯兩種形式：

• 解釋執行逐條將字節碼翻譯成機器碼並執行
• 即時編譯（Just-in-time ，JIT）將一個方法中包含的所有字節碼編譯成機器碼後再執行。

HotSpot 默認採用混合模式，綜合了解釋執行和即時編譯兩者的優點。它會先解釋執行字節碼，而後將其中反覆執行的熱點代碼（熱點檢測），以方法為單位進行即時編譯。

Android實現跨平台

Android其實基於Java語言的，所以同理，想要運行一段Android代碼，也要經過多個步驟，將Android原始碼轉換成機器可以執行的機器代碼。

但是這個轉換過程在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（2016 年）：採用混合編譯機制，安裝時先不編譯中間代碼，而是在用戶空閒時將能夠編譯成機器碼的那部分代碼，通過 AOT 編譯器先靜態編譯了。如果 AOT 還沒來得及編譯或者不能編譯，再調用 JIT+ 解釋器。這種機制，相當於用時間換空間，既縮短了用戶安裝 APP 的等待時間，又將虛擬機里編譯器和解釋器能做的優化提升到最大效率了。

Android編譯的問題

可以看到，從2008年的Android 1.0開始，Android在編譯優化上面在一直下功夫。

當前的 Android 採用的是解釋執行 + JIT + AOT 的綜合模式，在 空間占用+安裝速度+運行速度 上已經達到了一個很好的平衡。

但是Android的編譯問題一直被詬病。儘管在後續的Android 8.0 上改進了解釋器，解釋模式執行效率大幅提升；Android 10.0 上提供了預先放置熱點代碼的方式，應用在安裝的時候就能知道常用代碼會被提前編譯。

但是，目前來看，無論如何，Android都沒能擺脫這樣一個前提：即應用在被打包成 APK 的時候，採用的還是 Java 代碼。換句話說，在 APK 變成用戶可應用的過程中，還經歷了一個在 Android 系統內部的編譯過程，這是一個繞不過的坎。

鴻蒙實現跨平台

那麼，鴻蒙OS的代碼編譯是怎麼樣的呢？他又是如何解決跨平台的問題的呢？

從上圖中可以看到，在鴻蒙OS架構中，方舟編譯器和多終端開發IDE扮演著重要的位置。

跨平台有一個最大的挑戰，那就是各個平台的適配問題，尤其是目前各種設備類型越來越多，如何將同一個應用，在手機、手錶、汽車、電視上面都可以適配的展示呢？這就是多終端開發IDE所做的事情。

使用華為提供的多終端IDE，多語言統一編譯，分布式架構Kit提供螢幕布局控制項以及交互的自動適配，支持控制項拖拽，面向預覽的可視化編程，從而使開發者可以基於同一工程高效構建多端自動運行App，實現真正的一次開發，多端部署，在跨設備之間實現共享生態。

上圖就是華為提供的IDE，在裡面可以通過圖形化介面拖拽控制項，並且IDE可以幫助自動適配各種終端設備。

有了IDE，開發可以方便的開發一套代碼，這樣可以自動適配到各種設備中，但是各種設備所執行的機器指令是不一樣的，如何把這一套代碼分別編譯成各個設備需要的機器指令呢？

Android設備是由不同設備上內置的虛擬機進行編譯的，所以編譯之前就知道這個設備具體是什麼了，那麼，鴻蒙OS是怎麼做的呢？這就是方舟編譯器所幹的事情了。

華為方舟編譯器是首個取代Android虛擬機模式的靜態編譯器，可供開發者在開發環境中一次性將高級語言編譯為機器碼。此外，方舟編譯器未來將支持多語言統一編譯，可大幅提高開發效率。

Android之所以"慢"，是因為他的編譯過程是在終端進行的，也就是說需要在用戶的手機上，通過虛擬機進行編譯成可執行的機器代碼。

而鴻蒙OS使用的方舟編譯器，可以將高級語言（Java）直接變成機器碼，從而繞過了虛擬機。並且這個編譯過程並不是在用戶的手機上完成的，而是在應用開發階段就完成了。

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

華為官方介紹，方舟編譯器是首家完全替代語言虛擬機的靜態編譯器，完全不需要解釋器。兼顧Java開發效率和C語言運行效率的編譯器。

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

Android 在內存回收上採用集中回收機制，發聲全局回收時更需要暫停應用，這也是隨機卡頓的根因之一。而方舟編譯器採用了引用計數法來進行內存的實時回收，並且配合使用了專門的消除環算法（消除對象互相引用帶來的無法回收問題），來避免 GC 集中式回收帶來的系統卡頓。相比 GC，方舟的內存回收是實時的而非集中式的，且不需要暫停應用進程，這樣便大大消除了卡頓。

另外，就像JVM其實也是支持多種語言一樣，華為表示，方舟編譯器未來也會支持更過的開發語言。換句話說，其他語言的開發者，日後也能開發基於鴻蒙OS的應用。