《轉(zhuǎn)載》如何給女朋友解釋鴻蒙OS是怎樣實現(xiàn)跨平臺的？

漫話：如何給女朋友解釋鴻蒙OS是怎樣實現(xiàn)跨平臺的？

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

鴻蒙OS回顧

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

鴻蒙（英語：Harmony OS，開發(fā)代號Ark）是華為自2012年開發(fā)的一款可能兼容Android app的跨平臺操作系統(tǒng)。

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

1．分布式架構(gòu)首次用于終端OS，實現(xiàn)跨終端無縫協(xié)同體驗

2. 確定時延引擎和高性能IPC技術(shù)實現(xiàn)系統(tǒng)天生流暢

3. 基于微內(nèi)核架構(gòu)重塑終端設(shè)備可信安全

4. 通過統(tǒng)一IDE支撐一次開發(fā)，多端部署，實現(xiàn)跨終端生態(tài)共享

什么是跨平臺

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

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

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

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

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

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

Java實現(xiàn)跨平臺

先來說說Java是如何實現(xiàn)跨平臺的。

Java對于跨平臺的支持，就像對安全性和網(wǎng)絡(luò)移動性的支持一樣，是分布在整個Java體系結(jié)構(gòu)中的。其中扮演者重要的角色的有Java語言規(guī)范、Class文件、Java虛擬機（JVM）等。

首先，在Java語言規(guī)范中，規(guī)定了Java語言中基本數(shù)據(jù)類型的取值范圍和行為。其次，所有Java文件要編譯成統(tǒng)一的Class文件。最后，通過Java虛擬機將Class文件轉(zhuǎn)成對應(yīng)平臺的二進制文件。

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

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

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

解釋執(zhí)行

逐條將字節(jié)碼翻譯成機器碼并執(zhí)行

即時編譯（Just-in-time ，JIT）

將一個方法中包含的所有字節(jié)碼編譯成機器碼后再執(zhí)行。

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

Android實現(xiàn)跨平臺

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

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

Android 1.0（2008 年）：采用一個名為 Dalvik 的虛擬機，并且集成了一個解釋器。當(dāng) App 運行時，就會調(diào)用這個解釋器，對代碼進行逐句解釋，速度很慢。

Android 2.2（2010 年）：引入 JIT（Just In Time）即時編譯機制，當(dāng) App 運行時，會將用戶經(jīng)常使用的功能編譯為機器能直接執(zhí)行的 010101 機器碼，不用一句一句地去翻譯。當(dāng)出現(xiàn)不常用的功能時，再調(diào)用解釋器來翻譯；這樣速度加快，但每次啟動 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 編譯器先靜態(tài)編譯了。如果 AOT 還沒來得及編譯或者不能編譯，再調(diào)用 JIT+ 解釋器。這種機制，相當(dāng)于用時間換空間，既縮短了用戶安裝 APP 的等待時間，又將虛擬機里編譯器和解釋器能做的優(yōu)化提升到最大效率了。

Android編譯的問題

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

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

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

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

鴻蒙實現(xiàn)跨平臺

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

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

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

使用華為提供的多終端IDE，多語言統(tǒng)一編譯，分布式架構(gòu)Kit提供屏幕布局控件以及交互的自動適配，支持控件拖拽，面向預(yù)覽的可視化編程，從而使開發(fā)者可以基于同一工程高效構(gòu)建多端自動運行App，實現(xiàn)真正的一次開發(fā)，多端部署，在跨設(shè)備之間實現(xiàn)共享生態(tài)。

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

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

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

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

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

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

通過方舟編譯器，開發(fā)者的應(yīng)用在下載之前就已經(jīng)轉(zhuǎn)化成為機器可以識別的代碼，因而可以在手機上快速安裝、啟動和運行，而無需在經(jīng)過 VM 的編譯——某種程度上，方舟編譯器是將編譯過程提前到應(yīng)用開發(fā)階段，從而大幅度減少了智能手機和操作系統(tǒng)的運行負(fù)擔(dān)。

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

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

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

另外，就像JVM其實也是支持多種語言一樣，華為表示，方舟編譯器未來也會支持更過的開發(fā)語言。換句話說，其他語言的開發(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

漫話編程

2019年08月12日閱讀 10941

關(guān)注

漫話：如何給女朋友解釋鴻蒙OS是怎樣實現(xiàn)跨平臺的？

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

鴻蒙OS回顧

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

鴻蒙（英語：Harmony OS，開發(fā)代號Ark）是華為自2012年開發(fā)的一款可能兼容Android app的跨平臺操作系統(tǒng)。

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

1．分布式架構(gòu)首次用于終端OS，實現(xiàn)跨終端無縫協(xié)同體驗

2. 確定時延引擎和高性能IPC技術(shù)實現(xiàn)系統(tǒng)天生流暢

3. 基于微內(nèi)核架構(gòu)重塑終端設(shè)備可信安全

4. 通過統(tǒng)一IDE支撐一次開發(fā)，多端部署，實現(xiàn)跨終端生態(tài)共享

什么是跨平臺

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

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

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

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

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

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

Java實現(xiàn)跨平臺

先來說說Java是如何實現(xiàn)跨平臺的。

Java對于跨平臺的支持，就像對安全性和網(wǎng)絡(luò)移動性的支持一樣，是分布在整個Java體系結(jié)構(gòu)中的。其中扮演者重要的角色的有Java語言規(guī)范、Class文件、Java虛擬機（JVM）等。

首先，在Java語言規(guī)范中，規(guī)定了Java語言中基本數(shù)據(jù)類型的取值范圍和行為。其次，所有Java文件要編譯成統(tǒng)一的Class文件。最后，通過Java虛擬機將Class文件轉(zhuǎn)成對應(yīng)平臺的二進制文件。

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

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

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

解釋執(zhí)行

逐條將字節(jié)碼翻譯成機器碼并執(zhí)行

即時編譯（Just-in-time ，JIT）

將一個方法中包含的所有字節(jié)碼編譯成機器碼后再執(zhí)行。

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

Android實現(xiàn)跨平臺

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

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

Android 1.0（2008 年）：采用一個名為 Dalvik 的虛擬機，并且集成了一個解釋器。當(dāng) App 運行時，就會調(diào)用這個解釋器，對代碼進行逐句解釋，速度很慢。

Android 2.2（2010 年）：引入 JIT（Just In Time）即時編譯機制，當(dāng) App 運行時，會將用戶經(jīng)常使用的功能編譯為機器能直接執(zhí)行的 010101 機器碼，不用一句一句地去翻譯。當(dāng)出現(xiàn)不常用的功能時，再調(diào)用解釋器來翻譯；這樣速度加快，但每次啟動 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 編譯器先靜態(tài)編譯了。如果 AOT 還沒來得及編譯或者不能編譯，再調(diào)用 JIT+ 解釋器。這種機制，相當(dāng)于用時間換空間，既縮短了用戶安裝 APP 的等待時間，又將虛擬機里編譯器和解釋器能做的優(yōu)化提升到最大效率了。

Android編譯的問題

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

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

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

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

鴻蒙實現(xiàn)跨平臺

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

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

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

使用華為提供的多終端IDE，多語言統(tǒng)一編譯，分布式架構(gòu)Kit提供屏幕布局控件以及交互的自動適配，支持控件拖拽，面向預(yù)覽的可視化編程，從而使開發(fā)者可以基于同一工程高效構(gòu)建多端自動運行App，實現(xiàn)真正的一次開發(fā)，多端部署，在跨設(shè)備之間實現(xiàn)共享生態(tài)。

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

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

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

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

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

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

通過方舟編譯器，開發(fā)者的應(yīng)用在下載之前就已經(jīng)轉(zhuǎn)化成為機器可以識別的代碼，因而可以在手機上快速安裝、啟動和運行，而無需在經(jīng)過 VM 的編譯——某種程度上，方舟編譯器是將編譯過程提前到應(yīng)用開發(fā)階段，從而大幅度減少了智能手機和操作系統(tǒng)的運行負(fù)擔(dān)。

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

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

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

另外，就像JVM其實也是支持多種語言一樣，華為表示，方舟編譯器未來也會支持更過的開發(fā)語言。換句話說，其他語言的開發(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

轉(zhuǎn)自掘金社區(qū)-漫話編程

Java Android

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。