漫話：如何給女朋友解釋鴻蒙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語言規範、Class檔案、Java虛擬機器器（JVM）等。
首先，在Java語言規範中，規定了Java語言中基本資料型別的取值範圍和行為。其次，所有Java檔案要編譯成統一的Class檔案。最後，通過Java虛擬機器器將Class檔案轉成對應平臺的二進位制檔案。
Java的平臺無關性是建立在Java虛擬機器器的平臺有關性基礎之上的，是因為Java虛擬機器器遮蔽了底層作業系統和硬體的差異。
想要執行一段Java程式碼，要經過多個步驟，將Java原始碼轉換成機器可以執行的機器程式碼，這個過程主要由虛擬機器器來完成。
在著名的HotSpot虛擬機器器中，主要有解釋執行和即時編譯兩種形式：
解釋執行
逐條將位元組碼翻譯成機器碼並執行
即時編譯（Just-in-time ，JIT）
將一個方法中包含的所有位元組碼編譯成機器碼後再執行。
HotSpot 預設採用混合模式，綜合瞭解釋執行和即時編譯兩者的優點。它會先解釋執行位元組碼，而後將其中反覆執行的熱點程式碼（熱點檢測），以方法為單位進行即時編譯。
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 的等待時間，又將虛擬機器器裡編譯器和直譯器能做的優化提升到最大效率了。
可以看到，從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的應用。
https://www.jishuwen.com/d/2NN3
https://www.zhihu.com/question/339567108 https://www.cnbeta.com/articles/tech/876171.htm https://www.cnbeta.com/articles/tech/876919.htm https://juejin.im/post/5cb07000f265da037d4f9be6
