周末在家休息，女朋友在刷朋友圈，突然她問我：最近我的朋友圈經(jīng)常被華為刷屏，到底什么是“鴻蒙”啊?

[[274672]]

圖片來自 Pexels

鴻蒙 OS 回顧

2019 年 8 月 9 日華為開發(fā)者大會(huì)上，華為消費(fèi)者業(yè)務(wù) CEO 余承東正式宣布發(fā)布自有操作系統(tǒng)鴻蒙，內(nèi)核為 Linux 內(nèi)核、鴻蒙微內(nèi)核和 LiteOS。未來將擺脫 Linux 內(nèi)核和 LiteOS，只有鴻蒙微內(nèi)核。

鴻蒙(英語(yǔ)：Harmony OS，開發(fā)代號(hào) Ark)是華為自 2012 年開發(fā)的一款可能兼容 Android App 的跨平臺(tái)操作系統(tǒng)。

圖：鴻蒙 OS 的四大技術(shù)特性

鴻蒙 OS 的四大技術(shù)特性如下：

• 分布式架構(gòu)首次用于終端 OS，實(shí)現(xiàn)跨終端無縫協(xié)同體驗(yàn)。
• 確定時(shí)延引擎和高性能 IPC 技術(shù)實(shí)現(xiàn)系統(tǒng)天生流暢。
• 基于微內(nèi)核架構(gòu)重塑終端設(shè)備可信安全。
• 通過統(tǒng)一 IDE 支撐一次開發(fā)，多端部署，實(shí)現(xiàn)跨終端生態(tài)共享。

什么是跨平臺(tái)

在以前，平臺(tái)≈操作系統(tǒng)。所以，傳統(tǒng)意義上的跨平臺(tái)即不依賴于操作系統(tǒng)，也不依賴硬件環(huán)境。一個(gè)操作系統(tǒng)下開發(fā)的應(yīng)用，放到另一個(gè)操作系統(tǒng)下依然可以運(yùn)行。

但是隨著科技的發(fā)展，平臺(tái)≈操作系統(tǒng)已經(jīng)不成立了，就像華為推出的鴻蒙 OS，他可以支持到多種多樣的設(shè)備，如手機(jī)、手表、電腦、汽車、智能家居設(shè)備等。

所以，今天我們談的跨平臺(tái)，指的是跨設(shè)備。即平臺(tái)≈設(shè)備。

所以，華為希望鴻蒙 OS 可以運(yùn)行在各種各樣的設(shè)備上，所以，鴻蒙 OS 必然需要具備跨平臺(tái)的能力。

而且，鴻蒙想要做的不僅僅是操作系統(tǒng)可以跨平臺(tái)，更重要的是要讓用戶和開發(fā)者真正的感受到跨平臺(tái)。

所以，跨平臺(tái)操作系統(tǒng)鴻蒙的目的是：使開發(fā)者能夠聚焦自身業(yè)務(wù)邏輯，像開發(fā)同一終端一樣開發(fā)跨終端分布式應(yīng)用，也使最終消費(fèi)者享受到強(qiáng)大的跨終端業(yè)務(wù)協(xié)同能力為各使用場(chǎng)景帶來的無縫體驗(yàn)。

Java 實(shí)現(xiàn)跨平臺(tái)

先來說說 Java 是如何實(shí)現(xiàn)跨平臺(tái)的。Java 對(duì)于跨平臺(tái)的支持，就像對(duì)安全性和網(wǎng)絡(luò)移動(dòng)性的支持一樣，是分布在整個(gè) Java 體系結(jié)構(gòu)中的。

其中扮演著重要角色的有 Java 語(yǔ)言規(guī)范、Class 文件、Java 虛擬機(jī)(JVM)等。

首先，在 Java 語(yǔ)言規(guī)范中，規(guī)定了 Java 語(yǔ)言中基本數(shù)據(jù)類型的取值范圍和行為。

其次，所有 Java 文件要編譯成統(tǒng)一的 Class 文件。最后，通過 Java 虛擬機(jī)將 Class 文件轉(zhuǎn)成對(duì)應(yīng)平臺(tái)的二進(jìn)制文件。

Java 的平臺(tái)無關(guān)性是建立在 Java 虛擬機(jī)的平臺(tái)有關(guān)性基礎(chǔ)之上的，是因?yàn)?Java 虛擬機(jī)屏蔽了底層操作系統(tǒng)和硬件的差異。

想要運(yùn)行一段 Java 代碼，要經(jīng)過多個(gè)步驟，將 Java 源代碼轉(zhuǎn)換成機(jī)器可以執(zhí)行的機(jī)器代碼，這個(gè)過程主要由虛擬機(jī)來完成。

在著名的 HotSpot 虛擬機(jī)中，主要有解釋執(zhí)行和即時(shí)編譯兩種形式：

• 解釋執(zhí)行，逐條將字節(jié)碼翻譯成機(jī)器碼并執(zhí)行。
• 即時(shí)編譯(Just-in-time ，JIT)，將一個(gè)方法中包含的所有字節(jié)碼編譯成機(jī)器碼后再執(zhí)行。

HotSpot 默認(rèn)采用混合模式，綜合了解釋執(zhí)行和即時(shí)編譯兩者的優(yōu)點(diǎn)。它會(huì)先解釋執(zhí)行字節(jié)碼，而后將其中反復(fù)執(zhí)行的熱點(diǎn)代碼(熱點(diǎn)檢測(cè))，以方法為單位進(jìn)行即時(shí)編譯。

Android 實(shí)現(xiàn)跨平臺(tái)

Android 其實(shí)基于 Java 語(yǔ)言的，所以同理，想要運(yùn)行一段 Android 代碼，也要經(jīng)過多個(gè)步驟，將 Android 源代碼轉(zhuǎn)換成機(jī)器可以執(zhí)行的機(jī)器代碼。

但是這個(gè)轉(zhuǎn)換過程在 Android 的不同版本中實(shí)現(xiàn)不盡相同：

Android 1.0(2008 年)：采用一個(gè)名為 Dalvik 的虛擬機(jī)，并且集成了一個(gè)解釋器。當(dāng) App 運(yùn)行時(shí)，就會(huì)調(diào)用這個(gè)解釋器，對(duì)代碼進(jìn)行逐句解釋，速度很慢。

Android 2.2(2010 年)：引入 JIT(Just In Time)即時(shí)編譯機(jī)制，當(dāng) App 運(yùn)行時(shí)，會(huì)將用戶經(jīng)常使用的功能編譯為機(jī)器能直接執(zhí)行的 010101 機(jī)器碼，不用一句一句地去翻譯。

當(dāng)出現(xiàn)不常用的功能時(shí)，再調(diào)用解釋器來翻譯;這樣速度加快，但每次啟動(dòng) App 都要重新編譯一次，不能一勞永逸。 

Android 5.0(2014 年 10 月)：將虛擬機(jī) Dalvik 換成 ART(Android Run Time)，將 JIT 的編譯器替換成 AOT(Ahead of Time)。

如此，App 在下載后安裝到手機(jī)上時(shí)同時(shí)把能編譯的代碼先編譯成機(jī)器聽得懂的 101010;剩下不太好翻譯的代碼，就在用戶使用時(shí)再叫醒解釋器來翻譯。

如此，不用每次打開 App 都需要編譯，但安裝 App 的時(shí)間有點(diǎn)長(zhǎng)，而且占用手機(jī)空間。

Android 7.0(2016 年)：采用混合編譯機(jī)制，安裝時(shí)先不編譯中間代碼，而是在用戶空閑時(shí)將能夠編譯成機(jī)器碼的那部分代碼，通過 AOT 編譯器先靜態(tài)編譯了。

如果 AOT 還沒來得及編譯或者不能編譯，再調(diào)用 JIT+ 解釋器。這種機(jī)制，相當(dāng)于用時(shí)間換空間，既縮短了用戶安裝 APP 的等待時(shí)間，又將虛擬機(jī)里編譯器和解釋器能做的優(yōu)化提升到最大效率了。

Android 編譯的問題

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

當(dāng)前的 Android 采用的是解釋執(zhí)行+JIT+AOT 的綜合模式，在空間占用+安裝速度+運(yùn)行速度上已經(jīng)達(dá)到了一個(gè)很好的平衡。

但是 Android 的編譯問題一直被詬病。盡管在后續(xù)的 Android 8.0 上改進(jìn)了解釋器，解釋模式執(zhí)行效率大幅提升。

Android 10.0 上提供了預(yù)先放置熱點(diǎn)代碼的方式，應(yīng)用在安裝的時(shí)候就能知道常用代碼會(huì)被提前編譯。

但是，目前來看，無論如何，Android 都沒能擺脫這樣一個(gè)前提：即應(yīng)用在被打包成 APK 的時(shí)候，采用的還是 Java 代碼。

換句話說，在 APK 變成用戶可應(yīng)用的過程中，還經(jīng)歷了一個(gè)在 Android 系統(tǒng)內(nèi)部的編譯過程，這是一個(gè)繞不過的坎。

鴻蒙實(shí)現(xiàn)跨平臺(tái)

那么，鴻蒙 OS 的代碼編譯是怎么樣的呢?他又是如何解決跨平臺(tái)的問題的呢?

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

跨平臺(tái)有一個(gè)最大的挑戰(zhàn)，那就是各個(gè)平臺(tái)的適配問題，尤其是目前各種設(shè)備類型越來越多，如何將同一個(gè)應(yīng)用，在手機(jī)、手表、汽車、電視上面都可以適配的展示呢?

這就是多終端開發(fā) IDE 所做的事情：

使用華為提供的多終端 IDE，多語(yǔ)言統(tǒng)一編譯，分布式架構(gòu) Kit 提供屏幕布局控件以及交互的自動(dòng)適配，支持控件拖拽，面向預(yù)覽的可視化編程。

從而使開發(fā)者可以基于同一工程高效構(gòu)建多端自動(dòng)運(yùn)行 App，實(shí)現(xiàn)真正的一次開發(fā)，多端部署，在跨設(shè)備之間實(shí)現(xiàn)共享生態(tài)。

上圖就是華為提供的 IDE，在里面可以通過圖形化界面拖拽控件，并且 IDE 可以幫助自動(dòng)適配各種終端設(shè)備。

有了IDE，開發(fā)可以方便的開發(fā)一套代碼，這樣可以自動(dòng)適配到各種設(shè)備中，但是各種設(shè)備所執(zhí)行的機(jī)器指令是不一樣的，如何把這一套代碼分別編譯成各個(gè)設(shè)備需要的機(jī)器指令呢?

Android 設(shè)備是由不同設(shè)備上內(nèi)置的虛擬機(jī)進(jìn)行編譯的，所以編譯之前就知道這個(gè)設(shè)備具體是什么了，那么，鴻蒙 OS 是怎么做的呢?這就是方舟編譯器所干的事情了。

華為方舟編譯器是首個(gè)取代 Android 虛擬機(jī)模式的靜態(tài)編譯器，可供開發(fā)者在開發(fā)環(huán)境中一次性將高級(jí)語(yǔ)言編譯為機(jī)器碼。

此外，方舟編譯器未來將支持多語(yǔ)言統(tǒng)一編譯，可大幅提高開發(fā)效率。

Android 之所以"慢"，是因?yàn)樗木幾g過程是在終端進(jìn)行的，也就是說需要在用戶的手機(jī)上，通過虛擬機(jī)進(jìn)行編譯成可執(zhí)行的機(jī)器代碼。

而鴻蒙 OS 使用的方舟編譯器，可以將高級(jí)語(yǔ)言(Java)直接變成機(jī)器碼，從而繞過了虛擬機(jī)。

并且這個(gè)編譯過程并不是在用戶的手機(jī)上完成的，而是在應(yīng)用開發(fā)階段就完成了。

通過方舟編譯器，開發(fā)者的應(yīng)用在下載之前就已經(jīng)轉(zhuǎn)化成為機(jī)器可以識(shí)別的代碼，因而可以在手機(jī)上快速安裝、啟動(dòng)和運(yùn)行，而無需再經(jīng)過 VM 的編譯。

某種程度上，方舟編譯器是將編譯過程提前到應(yīng)用開發(fā)階段，從而大幅度減少了智能手機(jī)和操作系統(tǒng)的運(yùn)行負(fù)擔(dān)。

華為官方介紹，方舟編譯器是首家完全替代語(yǔ)言虛擬機(jī)的靜態(tài)編譯器，完全不需要解釋器。并兼顧 Java 開發(fā)效率和 C 語(yǔ)言運(yùn)行效率的編譯器。

除了代碼編譯，方舟編譯器也提供了更高效的內(nèi)存機(jī)制，它與 Android 內(nèi)存回收的不同之處在于：

Android 在內(nèi)存回收上采用集中回收機(jī)制，發(fā)生全局回收時(shí)更需要暫停應(yīng)用，這也是隨機(jī)卡頓的根因之一。

而方舟編譯器采用了引用計(jì)數(shù)法來進(jìn)行內(nèi)存的實(shí)時(shí)回收，并且配合使用了專門的消除環(huán)算法(消除對(duì)象互相引用帶來的無法回收問題)，來避免 GC 集中式回收帶來的系統(tǒng)卡頓。

相比 GC，方舟的內(nèi)存回收是實(shí)時(shí)的而非集中式的，且不需要暫停應(yīng)用進(jìn)程，這樣便大大消除了卡頓。

另外，就像 JVM 其實(shí)也是支持多種語(yǔ)言一樣，華為表示，方舟編譯器未來也會(huì)支持更多的開發(fā)語(yǔ)言。換句話說，其他語(yǔ)言的開發(fā)者，日后也能開發(fā)基于鴻蒙 OS 的應(yīng)用。

參考資料：

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