HarmonyOS到底是不是Android套皮？

來(lái)源：21ic電子網(wǎng)，頭條@我的小號(hào)等
本文作者觀點(diǎn)不代表本網(wǎng)觀點(diǎn)

某人曾說(shuō)「沒(méi)有調(diào)查就沒(méi)有發(fā)言權(quán)」

最近鴻蒙系統(tǒng)關(guān)注度好高，支持與反對(duì)、看好和看衰、「自主的全場(chǎng)景分布式系統(tǒng)」和「Android套殼」各執(zhí)一詞，吵的不可開(kāi)交。

作為十八流碼農(nóng)，本著了解行業(yè)動(dòng)態(tài)、體驗(yàn)HarmonyOS開(kāi)發(fā)流程、找出HarmonyOS的特性與不足、看看是否有新的機(jī)會(huì)，也為了看看吵得不可開(kāi)交的諸位誰(shuí)說(shuō)得對(duì)，特地在這個(gè)鴻蒙系統(tǒng)馬上正式開(kāi)放升級(jí)的時(shí)間點(diǎn)，開(kāi)發(fā)體驗(yàn)了一番。

HarmonyOS到底怎么實(shí)現(xiàn)的——扒皮HarmonyOS

了解一個(gè)軟件怎么實(shí)現(xiàn)的，最好還是查看源代碼。

但是承諾2020年開(kāi)源的OpenHarmony項(xiàng)目到現(xiàn)在只開(kāi)源到嵌入式設(shè)備，這條路自然走不通。

只好退而求其次，看看已經(jīng)開(kāi)放的SDK、IDE、開(kāi)發(fā)示例、編譯產(chǎn)物，管中窺豹一下HarmonyOS到底怎么實(shí)現(xiàn)的。

00 安裝IDE-配置環(huán)境-編譯運(yùn)行

這部分很簡(jiǎn)單，下載DevEco Studio，然后照著文檔一步步操作就好了。

模板選擇了唯二的JS模板：Phone > Refresh Feature Ability。


然后一直下一步，申請(qǐng)下虛擬機(jī)，編譯運(yùn)行就成功了。

01 分析編譯產(chǎn)物

運(yùn)行成功后，先大致分析一下編譯產(chǎn)物，找一下程序入口，看看代碼到底怎么運(yùn)行的。

點(diǎn)開(kāi)build文件夾，打開(kāi)一看，喔噢！！！這目錄結(jié)構(gòu)和Android的太相似了，于是我熟練的點(diǎn)開(kāi)outputs文件夾找apk文件。


.hap？？？怎么和預(yù)想的不一樣？不過(guò)侵淫Linux多年的經(jīng)驗(yàn)告訴我，后綴都是浮云，于是果斷把.hap改成.apk，然后用Android Studio打開(kāi)，果然：


對(duì)比官方給出的App邏輯視圖：


我們發(fā)現(xiàn)：

1、沒(méi)有找到描述每個(gè)HAP屬性的pack.info
估計(jì)是因?yàn)楣こ讨欢x了一個(gè)Entry，沒(méi)有定義Feature，于是只生成了Entry的安裝包，但是按照官方文檔給的說(shuō)法
Entry可以獨(dú)立安裝運(yùn)行，在只定義一個(gè)Entry的情況下，編譯出這種包也說(shuō)得通
2、App邏輯視圖中的config.json正常在
3、App邏輯視圖中的abilities竟然編譯成Android包的.dex執(zhí)行文件，而用js定義的界面、視圖、邏輯竟然歸入assets中，這里面就有點(diǎn)貓膩了
4、編譯的可執(zhí)行文件中竟然包含一個(gè).apk文件，這個(gè)不速之客可在App邏輯視圖中完全沒(méi)體現(xiàn)，值得懷疑
于是接下來(lái)，我們就先重點(diǎn)分析這個(gè)entry_signed_entry.apk，分析一下這個(gè)不速之客在App安裝包里有什么作用
02 分析entry_signed_entry.apk

繼續(xù)用Android Studio打開(kāi)這個(gè)文件


是一個(gè)標(biāo)準(zhǔn)的Android App！！于是熟練的點(diǎn)開(kāi)Android應(yīng)用描述文件：AndroidManifest.xml

通過(guò)描述文件可以發(fā)現(xiàn)，整個(gè)apk只做了兩件事：

定義Application為ShellApplication
定義MainActivity為MainAbilityShellActivity

emmmmm……這名字起得真直白

按照Android開(kāi)發(fā)的慣例，從build文件夾中找這兩個(gè)類的相關(guān)文件。


果然不費(fèi)吹灰之力，接著分析源代碼：

先分析一下Application的定義文件ShellMyApplication：


ShellMyApplication繼承自HarmonyOS SDK的AceHarmonyApplication，不過(guò)啥事都沒(méi)干，接著看AceHarmonyApplication：


emmmmm……俄羅斯套娃嗎？照樣啥事也沒(méi)干，那就接著找它的父類：

HarmonyApplication：


看這么大段的引用和變量定義，應(yīng)該是正主沒(méi)錯(cuò)了，不過(guò)HarmonyOS的HarmonyApplication竟然繼承自Android的Application，這件事就得說(shuō)道說(shuō)道了HarmonyApplication整個(gè)文件很長(zhǎng)，就不貼代碼了，這個(gè)類主要做了如下幾個(gè)工作：

1、初始化HarmonyOS應(yīng)用...
2、輸出HarmonyOS應(yīng)用開(kāi)始初始化的日志......
3、加載HarmonyOS的Ability到Android的Application的HashMap中.........


4、接收系統(tǒng)產(chǎn)生的各種事件然后轉(zhuǎn)發(fā)給鴻蒙應(yīng)用............
5、初始化一個(gè)EventRunner，結(jié)合ohos包的代碼來(lái)看，估計(jì)就是官方文檔提到的「分布式軟總線」，是HarmonyOS所謂的「分布式設(shè)計(jì)」的相關(guān)實(shí)現(xiàn)，這部分后面分析


碼農(nóng)果然都是老實(shí)人，起名都這么實(shí)誠(chéng)又恰如其分：

ShellApplication的作用就是Android的Application提供一個(gè)Shell（殼），讓HarmonyOS的Application寄生其中

接著來(lái)看看MainAbilityShellActivity，依舊是套娃設(shè)計(jì)，直接看具體的實(shí)現(xiàn)：


MainAbilityShellActivity依舊繼承自Android的Activity，整個(gè)文件依舊很長(zhǎng)，但是邏輯很簡(jiǎn)單，就一個(gè)作用：

將Android的MainActivity的生命周期、Intent、觸摸事件、按鍵時(shí)間、權(quán)限申請(qǐng)結(jié)果……通過(guò)AbilityShellActivityDelegate（代理）轉(zhuǎn)發(fā)給HarmonyOS的Ability
果然不負(fù)Shell之名。本來(lái)想打開(kāi)Androi……HarmonyOS的應(yīng)用布局調(diào)試界面，但是設(shè)置里找不到了，233333……

不過(guò)根據(jù)我的第一個(gè)鴻蒙app，以及所見(jiàn)內(nèi)容,得知


這篇文章2020年末寫的，到如今只過(guò)去五個(gè)月，估計(jì)具體實(shí)現(xiàn)沒(méi)有改變。

03 分布式軟總線

HarmonyOS最大的賣點(diǎn)是其宣稱的「面向萬(wàn)物互聯(lián)時(shí)代的全場(chǎng)景分布式操作系統(tǒng)」，也是其最大的特性。

從官方文檔來(lái)看，不管是開(kāi)發(fā)層面所謂的「分布式設(shè)備虛擬化」、「分布式數(shù)據(jù)管理」、「分布式任務(wù)調(diào)度」，還是目前官方演示的「無(wú)縫流轉(zhuǎn)」、「多屏協(xié)同」都是以「分布式軟總線」為通訊基座，因此我們重點(diǎn)來(lái)找找它是怎么實(shí)現(xiàn)的。

具體到開(kāi)發(fā)文檔中，沒(méi)有發(fā)現(xiàn)關(guān)于「分布式軟總線」的API，只找到三個(gè)與其「分布式技術(shù)」所描述的特性相似的三個(gè)功能：


分別是：
分布式任務(wù)調(diào)度
分布式數(shù)據(jù)服務(wù)
分布式文件服務(wù)

有了這三組API，我們就可以通過(guò)「排列組合」實(shí)現(xiàn)其官網(wǎng)所宣稱的所有關(guān)于「分布式」的特性，所以，我們直接到SDK中找這三組API怎么實(shí)現(xiàn)的就可以追根溯源找到「分布式軟總線」具體怎么實(shí)現(xiàn)的了

打開(kāi)ohos.jar包后，遇到了第一個(gè)問(wèn)題：所有代碼都不給看！！！


Java開(kāi)發(fā)中，這種情況比較少見(jiàn)，只有一些重要的、底層的API中可能會(huì)出現(xiàn)，不過(guò)這個(gè)ohos.jar包源碼全部隱藏還是第一次見(jiàn)！！！HarmonyOS到底有多怕發(fā)現(xiàn)它的小秘密。

不過(guò)我們只是為了看一下HarmonyOS的設(shè)計(jì)思想，又不研究它具體實(shí)現(xiàn)，所有也用不著源代碼，直接看類名、函數(shù)名、依賴關(guān)系，大膽猜測(cè)、小心驗(yàn)證一下就好了
通過(guò)分析依賴關(guān)系，發(fā)現(xiàn)，大多數(shù)與分布式相關(guān)的包都依賴于：

ohos.rpc.*

以及官方文檔中有關(guān)「分布式任務(wù)調(diào)度」所依賴的包


以及官方文檔「分布式軟總線示意圖」


我們有理由相信：所謂的「分布式軟總線」實(shí)際上是一個(gè)私有的RPC協(xié)議

結(jié)合RPC的特點(diǎn)和HarmonyOS的特性，HarmonyOS的「分布式軟總線」采用RPC就就根本不奇怪。

不過(guò)，阿華不愧是立志要模仿、超越阿果的公司，連起名都一樣的鬼才：如此專業(yè)的名詞都能起得如此通俗易懂！

04 「分布式軟總線」具體設(shè)計(jì)

上面說(shuō)的再斬釘截鐵，最終也不過(guò)是猜想。

而且作為HarmonyOS的核心特性和殺手锏，作為十八線碼農(nóng)、不入流從業(yè)人員，怎么能不會(huì)對(duì)其設(shè)計(jì)思想產(chǎn)生好奇？

不過(guò)苦于沒(méi)有源代碼，以及估計(jì)絕大部分都是在系統(tǒng)層實(shí)現(xiàn)的，ohos.jar里也不過(guò)是相關(guān)調(diào)用，這條路肯定是行不通。

這時(shí)候靈感一閃，既然HarmonyOS是「全場(chǎng)景分布式系統(tǒng)」，那么這套協(xié)議肯定不止在Androi......HarmonyOS手機(jī)系統(tǒng)上實(shí)現(xiàn)，在其他類型設(shè)備上肯定有相關(guān)實(shí)現(xiàn)
這時(shí)候按揭開(kāi)源的OpenHarmony再次回到我的視線，既然OpenHarmony項(xiàng)目已經(jīng)開(kāi)源了嵌入式設(shè)備的相關(guān)實(shí)現(xiàn)，那么沒(méi)準(zhǔn)里面就有這套協(xié)議的相關(guān)源碼。

于是，我們來(lái)翻一下OpenHarmony的倉(cāng)庫(kù):

https://gitee.com/openharmony

皇天不負(fù)有心人，與「分布式軟總線」相關(guān)：

https://gitee.com/openharmony/communication_services_softbus_lite

這個(gè)項(xiàng)目實(shí)現(xiàn)了軟總線發(fā)現(xiàn)、組網(wǎng)、傳輸相關(guān)協(xié)議，熟悉編程的朋友應(yīng)該能想得到，有了這個(gè)項(xiàng)目，「全場(chǎng)景分布式」所列舉的所有特性都可以實(shí)現(xiàn)了。

代碼部分又臭又長(zhǎng)，而且估計(jì)很多人也不感興趣，也不確定全平臺(tái)的都是這樣實(shí)現(xiàn)的，就不具體分析了，只說(shuō)一下設(shè)計(jì)思想和大致工作流程，不同平臺(tái)具體實(shí)現(xiàn)可能有所不同，不過(guò)設(shè)計(jì)思想應(yīng)該不會(huì)差太多。

「分布式軟總線」主要有以下幾個(gè)工作模塊：

1、設(shè)備發(fā)現(xiàn)：采用了CoAP協(xié)議作為設(shè)備發(fā)現(xiàn)協(xié)議，通過(guò)發(fā)送在一個(gè)局域網(wǎng)內(nèi)發(fā)送廣播來(lái)發(fā)現(xiàn)設(shè)備，具體實(shí)現(xiàn)與本文無(wú)關(guān)，就不展開(kāi)了，感興趣的可以自己去看，在這個(gè)包里：


2、數(shù)據(jù)傳輸：基于Session提供統(tǒng)一的數(shù)據(jù)傳輸功能，不過(guò)網(wǎng)絡(luò)通信是華為的老本行了，估計(jì)挑不出什么毛病，就仔細(xì)分析了，代碼在：


3、設(shè)備認(rèn)證與管理：這部分主要是為了安全的，代碼在：

05 其他

整個(gè)OpenHarmony項(xiàng)目，還有一些有趣的實(shí)現(xiàn)：

https://gitee.com/openharmony/ace_engine_lite

這個(gè)應(yīng)該就是JS開(kāi)發(fā)的Ability界面如何編譯以及在嵌入式設(shè)備上如何渲染的相關(guān)實(shí)現(xiàn)，這也應(yīng)該是為什么HarmonyOS可以采用多種語(yǔ)言開(kāi)發(fā)界面的原因所在：


各種小程序、Flutter相關(guān)框架都是這樣設(shè)計(jì)的，全都是用來(lái)實(shí)現(xiàn)諸如「無(wú)縫流轉(zhuǎn)」、「遠(yuǎn)程啟動(dòng)」、「遷移」等與Ability有關(guān)的功能。

01 華為到底在HarmonyOS上做了哪些工作

從編譯完成的產(chǎn)物以及開(kāi)源的源代碼來(lái)看，華為為其所謂的「全場(chǎng)景分布式操作系統(tǒng)」主要做了兩個(gè)方面的工作：

1、定義了以Ability為核心的應(yīng)用開(kāi)發(fā)框架，使其可以屏蔽不同操作系統(tǒng)的差異，使開(kāi)發(fā)的代碼可以在不同操作系統(tǒng)中運(yùn)行。

在HarmonyOS之前，與之類似的技術(shù)且比較成功的有各家的小程序框架以及Flutter。

它們?nèi)咧g的區(qū)別：

小程序：運(yùn)行中各自App環(huán)境內(nèi)部
Flutter：致力于移動(dòng)端、桌面端、Web、嵌入式全覆蓋
Ability：主要為華為生態(tài)中的手機(jī)以及嵌入式設(shè)備設(shè)計(jì)
雖然它們各自的所追求的目標(biāo)不同，但它們?cè)O(shè)計(jì)思想都是類似的：自繪UI，屏蔽系統(tǒng)差異

2、定義了一個(gè)以「分布式軟總線」為名的自有RPC協(xié)議框架，以此RPC協(xié)議為基礎(chǔ)封裝了一系列常用的API，屏蔽了設(shè)備之間的繁瑣、多種多樣、差異很大的通訊方式，提供了穩(wěn)定、統(tǒng)一、可靠的近場(chǎng)通訊協(xié)議。

再具體到華為手機(jī)上將要升級(jí)的HarmonyOS，估計(jì)是：

原有的Android系統(tǒng) - GMS + HMS + 分布式軟總線 + 以Ability為核心的應(yīng)用開(kāi)發(fā)框架 = HarmonyOS

具體到示意圖，估計(jì)就是：

從分析結(jié)果來(lái)看，HarmonyOS有些地方確實(shí)夸大宣傳了，比如：

隨時(shí)換掉AOSP，這里的「隨時(shí)」，估計(jì)在近五年內(nèi)不會(huì)實(shí)現(xiàn)，在此之前，去掉Android虛擬機(jī)，HarmonyOS能不能正常運(yùn)行，我是持懷疑的態(tài)度的
「全場(chǎng)景分布式操作系統(tǒng)」，根據(jù)「分布式軟總線」相關(guān)代碼，這里的「全場(chǎng)景」，估計(jì)是同一個(gè)局域網(wǎng)內(nèi)的「全場(chǎng)景」、同一個(gè)局域網(wǎng)內(nèi)的萬(wàn)物互聯(lián)

當(dāng)然，對(duì)于HarmonyOS的絕大多數(shù)宣傳，按目前的設(shè)計(jì)思路，完全有可能實(shí)現(xiàn)或者已經(jīng)實(shí)現(xiàn)了，比如：

由于Ability、分布式軟總線等技術(shù)屏蔽了操作系統(tǒng)差異，一點(diǎn)點(diǎn)挖空、取代AOSP是完全有可能實(shí)現(xiàn)的（雖然我認(rèn)為這個(gè)時(shí)間會(huì)持續(xù)5-10年，到時(shí)候Android、HarmonyOS存不存在都不能確定）

02 HarmonyOS到底是不是Android套皮

回到我們最初的問(wèn)題：「HarmonyOS到底是個(gè)全新的自主操作系統(tǒng)還是個(gè)套殼安卓？」

分析完代碼后，我發(fā)現(xiàn)我也不能回答這個(gè)問(wèn)題：

說(shuō)它是吧，它也確實(shí)是從Android發(fā)展出來(lái)的
說(shuō)它不是吧，它也確實(shí)和Android有了明顯的差異和特色
不過(guò)這時(shí)候，我發(fā)現(xiàn)這個(gè)問(wèn)題和一個(gè)提出了2000年的哲學(xué)悖論很像：忒修斯之船
特修斯之船（The Ship of Theseus）亦稱為忒修斯悖論，是一種有關(guān)身份更替的悖論。假定某物體的構(gòu)成要素被置換后，但它依舊是原來(lái)的物體嗎？說(shuō)是一艘可以在海上航行幾百年的船，歸功于不間斷的維修和替換部件。只要一塊木板腐爛了，它就會(huì)被替換掉，以此類推，直到所有的功能部件都不是最開(kāi)始的那些了。問(wèn)題是，最終產(chǎn)生的這艘船是否還是原來(lái)的那艘特修斯之船，還是一艘完全不同的船？如果不是原來(lái)的船，那么在什么時(shí)候它不再是原來(lái)的船了？

回到這個(gè)問(wèn)題：

我替換掉Android一行代碼，那么它還是Android嗎？
我替換掉Android一個(gè)模塊，那么它還是Android嗎？
我給Android添加一個(gè)模塊，那么它還是Android嗎？
......

這個(gè)問(wèn)題哲學(xué)家辯了兩千年，相信我們這一時(shí)半會(huì)兒也辯不出來(lái)，而且爭(zhēng)辯這個(gè)問(wèn)題也沒(méi)有太多的意義

所有我們不如拋棄這個(gè)問(wèn)題，換一個(gè)新的問(wèn)題，也是我們更關(guān)心的問(wèn)題：「HarmonyOS能實(shí)現(xiàn)華為在華為終端上定下的目標(biāo)嗎？」

03 HarmonyOS能實(shí)現(xiàn)華為的目標(biāo)嗎？

這部分本來(lái)想討論HarmonyOS的發(fā)展前景以及能不能取得成功。但是想要看清這件事，需要扎實(shí)的理論知識(shí)、豐富的行業(yè)經(jīng)驗(yàn)，還要對(duì)商業(yè)活動(dòng)有一定的見(jiàn)解，有這個(gè)能力的人，早就是行業(yè)泰斗、技術(shù)大咖了。

所以找了幾天資料依舊沒(méi)什么思路，因此想悄悄咪咪的把這個(gè)坑給鴿了。但沒(méi)想到看得人這么多，這下都不知道怎么鴿了，就只能強(qiáng)行人云亦云一波。通常來(lái)講，影響一個(gè)商業(yè)操作系統(tǒng)成敗的因素有很多，但大體上都是從三個(gè)大方向進(jìn)行分析：系統(tǒng)優(yōu)勢(shì)、商業(yè)運(yùn)作、生態(tài)建設(shè)。那么我們也從這三個(gè)方面探討一下HarmonyOS有沒(méi)有可能成功。

00 系統(tǒng)優(yōu)勢(shì)

目前HarmonyOS有兩個(gè)獨(dú)有的特性：

1、一個(gè)跨平臺(tái)的JavaScript應(yīng)用框架（后面我們稱之為Ace Engine，理由在下面）
2、分布式軟總線

這個(gè)JavaScript應(yīng)用框架是Ability的最重要的組成部分之一，寫00-02時(shí)沒(méi)有仔細(xì)看這部分的代碼和文檔，寫的不太清楚，現(xiàn)在將補(bǔ)充內(nèi)容寫到這里，就不修改上面的內(nèi)容了，這些補(bǔ)充內(nèi)容也能解答評(píng)論區(qū)的一些疑問(wèn)，補(bǔ)充內(nèi)容如下：

1). HarmonyOS雖然號(hào)稱可以使用Java、JavaScript、C寫UI界面且UI界面可以跨設(shè)備，但目前在實(shí)際開(kāi)發(fā)中，不同設(shè)備支持的語(yǔ)言是不同的：
在手機(jī)設(shè)備上，只能使用Java、JavaScript寫界面（相關(guān)文檔 ：Java UI框架、JS UI框架 兩部分）
在嵌入式設(shè)備上，只能使用C、JavaScript寫界面（相關(guān)文檔 ：JS應(yīng)用開(kāi)發(fā)、系統(tǒng)基礎(chǔ)子系統(tǒng)集>圖形及UI子系統(tǒng) 兩部分）
只有JavaScript寫的界面可以跨設(shè)備使用

只有JS UI界面可以跨設(shè)備，就是這個(gè)JavaScript跨平臺(tái)框架的功勞

2). 這個(gè)JavaScript應(yīng)用框
架的嵌入式部分代碼已經(jīng)開(kāi)源了，就是上面提到的：

https://gitee.com/openharmony/ace_engine_lite

框架圖如下：


其中：

JS引擎（JS runtime）是三星開(kāi)源的IoT JavaScript引擎：JerryScript
除JS引擎外，其他應(yīng)該都是華為自己寫的
JS應(yīng)用框架只負(fù)責(zé)解析JS Bundle（我們用JS寫的界面編譯后的產(chǎn)物），渲染交給了有C寫的原生框架
因此C原生框架不可能跨設(shè)備，只能在LiteOS中使用
手機(jī)端能不能使用這個(gè)C原生UI框架未知，但是開(kāi)發(fā)文檔上沒(méi)有提及，應(yīng)該是還沒(méi)有開(kāi)放或?qū)崿F(xiàn)（是哪一個(gè)不太清楚，但是嵌入式設(shè)備與手機(jī)UI框架的實(shí)現(xiàn)難度不是一個(gè)數(shù)量級(jí)，LiteOS上的C語(yǔ)言UI框架應(yīng)該滿足不了手機(jī)上的復(fù)雜且苛刻的要求，所有不可能直接使用）

因?yàn)檫@個(gè)JS應(yīng)用框架的LiteOS開(kāi)源部分被命名為ace_engine_lite，所以我們暫時(shí)將這個(gè)應(yīng)用框架稱為Ace Engine

3). 這個(gè)JS應(yīng)用框架的手機(jī)版本還沒(méi)有開(kāi)源，所以我們不知道具體實(shí)現(xiàn)，但是我們?cè)谏厦娴奈恼轮刑岬竭^(guò)：
JS Bundle由JS Framework解析后將數(shù)據(jù)交給了Android，由Android的負(fù)責(zé)將其渲染在SurfaceView上

這就是我為什么質(zhì)疑目前HarmonyOS離不開(kāi)AOSP的原因
這也是我為什么認(rèn)定HarmonyOS可以掏空AOSP的原因

4). 接著我們看一下Ability框架圖：


其中：

User Native Ability在LiteOS中指的就是C語(yǔ)言實(shí)現(xiàn)的Ability；在HarmonyOS中就是Java實(shí)現(xiàn)的Ability
AbilityKit在LiteOS中應(yīng)該是用C語(yǔ)言自己實(shí)現(xiàn)的，但在HarmonyOS中，是基于Android的Activity實(shí)現(xiàn)的
圖中的藍(lán)色部分在LiteOS中很明確，但在HarmonyOS中怎么實(shí)現(xiàn)目前沒(méi)有相關(guān)代碼，不得而知（個(gè)人猜測(cè)，根據(jù)上面代碼分析，有部分在ShellApplication（應(yīng)用內(nèi)）實(shí)現(xiàn)，有部分為系統(tǒng)服務(wù)，也有部分在內(nèi)核中實(shí)現(xiàn)）

5). HarmonyOS所宣稱的雙內(nèi)核，其中一個(gè)是AOSP，那么另一個(gè)就應(yīng)該是4中這個(gè)以Ability為核心的應(yīng)用框架。

且不論其是否符合操作系統(tǒng)的定義，僅由于3的存在，現(xiàn)在這個(gè)階段這個(gè)內(nèi)核的獨(dú)立性是存疑的。

當(dāng)然，也因?yàn)?的存在，按照這條設(shè)計(jì)思路走下去，那么HarmonyOS最終實(shí)現(xiàn)其畫的架構(gòu)圖是可以確定的。


其實(shí)上面這些框框里面所說(shuō)的東西的其中一部分都已經(jīng)實(shí)現(xiàn)了，還有一部分由于時(shí)間原因沒(méi)有實(shí)現(xiàn)，但技術(shù)已經(jīng)被我國(guó)工程師所掌握，實(shí)現(xiàn)起來(lái)也是時(shí)間問(wèn)題，除了的兩部分：

Linux Kernel（在內(nèi)核層中）
AOSP（大致對(duì)應(yīng)圖中的UI框架+用戶程序框架+Ability框架）

別看這倆數(shù)量上很少，但是坑很深，目前國(guó)內(nèi)搞不定的也就這兩部分。

為什么替換不掉Linux Kernel？這個(gè)國(guó)內(nèi)真的沒(méi)人能搞得定這個(gè)（操作系統(tǒng)）。

為什么不替換掉AOSP？我們是為了兼容；那為什么Ability要交給AOSP去渲染呢？那是因?yàn)閲?guó)內(nèi)也沒(méi)有人能搞得定這個(gè)（計(jì)算機(jī)圖形學(xué)）。

以及為什么LiteOS中的JS Framework都自己實(shí)現(xiàn)，但唯獨(dú)JS runtime還要用三星開(kāi)源的JerryScript呢（手機(jī)版不知道用的啥）？因?yàn)檫@個(gè)國(guó)內(nèi)也沒(méi)有人搞得定（編譯原理）。

操作系統(tǒng)、計(jì)算機(jī)圖形學(xué)、編譯原理，這仨貨是計(jì)算機(jī)三大天坑，其中艱難險(xiǎn)阻，非專業(yè)人員不能體會(huì)（討論了半天「操作系統(tǒng)」又回到「操作系統(tǒng)」了，23333……）。

HarmonyOS主打IoT系統(tǒng):

分布式軟總線技術(shù)將物聯(lián)網(wǎng)通訊技術(shù)（NFC、藍(lán)牙、WIFI……）與協(xié)議（CoAP、RPC……）做了良好的封裝，以及對(duì)數(shù)據(jù)格式（HarmonyOS IDL）以及服務(wù)（PA）做了良好的抽象，使局域網(wǎng)內(nèi)的設(shè)備之間可以方便的通訊、交換數(shù)據(jù)、調(diào)用遠(yuǎn)程服務(wù)，設(shè)備之間仿佛融為一體。

Ace Engine在不同設(shè)備之間存在，使得可以對(duì)用戶界面（UI）進(jìn)行抽象（抽象為FA），讓一次開(kāi)發(fā)多端部署得以實(shí)現(xiàn)。

分布式軟總線+Ace Engine 也就是HarmonyOS的核心設(shè)計(jì)思想，這一點(diǎn)在王成錄的采訪中也有所提及。


那么這兩項(xiàng)技術(shù)有「技術(shù)壁壘」嗎？可以作為HarmonyOS的護(hù)城河嗎？個(gè)人認(rèn)為答案都是否定的

先從技術(shù)層面看看:

HarmonyOS的嵌入式操作系統(tǒng)部分就不說(shuō)了，玩過(guò)物聯(lián)網(wǎng)的都知道，現(xiàn)在市面上的競(jìng)品有很多，除了華為的LiteOS外，還有TencentOS tiny、AliOS Things、Xiaomi Vela、RTOS……

LiteOS與其他相比最大的特點(diǎn)就是功能封裝的更加友好，也更加統(tǒng)一，但最大的缺點(diǎn)也源于此：它需要的硬件資源太多了，對(duì)于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備來(lái)說(shuō)，硬件成本是不可承受的。

而如果裁剪掉這部分，那么和其他的Iot系統(tǒng)并沒(méi)有太多區(qū)別。

再看看Ace Engine:

熟悉編程的朋友一定知道，Ace Engine與小程序以及Flutter的設(shè)計(jì)思想與架構(gòu)完全一樣，F(xiàn)lutter由于Dart虛擬機(jī)無(wú)法運(yùn)行中資源有限的嵌入式設(shè)備中，無(wú)法做到，那小程序?qū)Ρ热绾文兀?/section>

以目前擁有最大生態(tài)的微信小程序?yàn)槔哉Q生之日起，就支持Android、IOS、HarmonyOS（由于兼容Android），而又由于WMPF（Wechat Mini-Program Framework，小程序硬件框架）的存在。


目前微信小程序也可以運(yùn)行在Windows、Mac、嵌入式設(shè)備上，基本覆蓋了Ace Engine的所有設(shè)備（HarmonyOS、嵌入式設(shè)備）以及Ace Engine不支持的設(shè)備（IOS、Mac、Windows）。

至于CoAP+RPC（分布式軟總線）呢？且不說(shuō)開(kāi)源方案本來(lái)就有很多，就是從零開(kāi)始實(shí)現(xiàn)，目前國(guó)內(nèi)能做到的公司數(shù)量數(shù)起來(lái)，只怕兩只手兩只腳都不夠用。

那么依靠這些，華為能夠?yàn)镠armonyOS培育出自己的物聯(lián)網(wǎng)生態(tài)嗎？我個(gè)人的觀點(diǎn)是悲觀的。

鴻蒙主管在采訪中說(shuō)：


個(gè)人認(rèn)為，物聯(lián)網(wǎng)作為提出了二十多年的概念，以及孵化了十幾年的產(chǎn)業(yè)，「分布式軟總線」相關(guān)技術(shù)和協(xié)議在不同產(chǎn)品中或多或少都才用過(guò)，而物聯(lián)網(wǎng)到現(xiàn)在這個(gè)時(shí)間點(diǎn)都沒(méi)有爆發(fā)，通訊成本高、開(kāi)發(fā)成本高的確是沒(méi)有爆發(fā)的原因之一，但絕對(duì)不是根本原因。

而且退一步講，即使這個(gè)模式跑通了又如何？這套技術(shù)并沒(méi)有什么壟斷性的技術(shù)壁壘，以各手機(jī)廠商與移動(dòng)互聯(lián)網(wǎng)廠商的能力，最多只能給HarmonyOS六個(gè)月到一年的先發(fā)紅利。

到時(shí)候不說(shuō)手機(jī)廠商，就以微信為例：

除了構(gòu)建在應(yīng)用內(nèi)的RPC協(xié)議不如構(gòu)建在系統(tǒng)內(nèi)RPC協(xié)議性能指標(biāo)好外：

在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，可以支持更多的平臺(tái)（HarmonyOS vs Android+IOS）
在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，開(kāi)發(fā)成本更低（小程序 vs App）
在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，推廣成本更低（微信小程序生態(tài) vs 華為App生態(tài)）
在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，獲客成本更低（即開(kāi)即用 vs 下載、安裝App）
……

假如你是產(chǎn)品經(jīng)理，在想法驗(yàn)證階段，面對(duì)這么多需要考慮的指標(biāo)，你會(huì)優(yōu)先選擇哪一個(gè)？到時(shí)候恐怕應(yīng)用響應(yīng)慢點(diǎn)、通訊速度慢點(diǎn)會(huì)成為最后考慮的東西。

而一旦想法驗(yàn)證通過(guò)，又有幾個(gè)服務(wù)不會(huì)全平臺(tái)支持，而主動(dòng)與一個(gè)平臺(tái)綁定？

這就是HarmonyOS想要成功所需要解決的第一個(gè)問(wèn)題：

如果「分布式軟總線」這條路是無(wú)價(jià)值的，那么作為HarmonyOS最大的賣點(diǎn)，HarmonyOS所做的種種努力都是白費(fèi)的，HarmonyOS最終就會(huì)走向失敗；

而如果「分布式軟總線」這條路走得通，極其容易被別的廠商參考、借鑒，HarmonyOS卻并不能以此建立足夠?qū)拸V的「護(hù)城河」并以此培育出自己的生態(tài)
01 商業(yè)運(yùn)作

一款商業(yè)操作系統(tǒng)想要生存，最基本的條件有兩個(gè)：

足夠多的用戶
可以平衡廠家、用戶、開(kāi)發(fā)者利益的政策

死于沒(méi)有足夠多用戶的操作系統(tǒng)太多了，就不說(shuō)了；死于第二個(gè)因素的操作系統(tǒng)最著名的就是Windows Phone，一意孤行、反復(fù)橫跳，導(dǎo)致微軟錯(cuò)失了整個(gè)移動(dòng)互聯(lián)網(wǎng)時(shí)代。

先說(shuō)用戶問(wèn)題，目前可以確定的是，在HarmonyOS沒(méi)有成功的趨勢(shì)之前，搭載HarmonyOS的手機(jī)以及使用HarmonyOS的用戶絕大多數(shù)華為以及榮耀用戶。


我們以兩年換機(jī)周期為例，目前華為手機(jī)存量大約為4億臺(tái)。

在目前這個(gè)時(shí)間點(diǎn)，HarmonyOS生態(tài)抗衡GMS生態(tài)的可能性微乎其微，所以第一批升級(jí)HarmonyOS的絕大多數(shù)應(yīng)該都是國(guó)內(nèi)用戶，那這部分手機(jī)存量在2.2億左右
由于GMS被禁用，華為的海外市場(chǎng)估計(jì)會(huì)繼續(xù)迅速萎縮。

而在2020年9月15日之后，被禁止生產(chǎn)5nm Kirin芯片之后，華為終端產(chǎn)品缺貨的狀態(tài)持續(xù)存在，華為國(guó)內(nèi)的市場(chǎng)份額估計(jì)也會(huì)快速萎縮。


再根據(jù)Android手機(jī)過(guò)去系統(tǒng)升級(jí)比例的經(jīng)驗(yàn)，目前HarmonyOS裝機(jī)量絕對(duì)達(dá)不到王成錄所說(shuō)的生存線。


這也是HarmonyOS想要成功需要解決的第二個(gè)問(wèn)題。在商業(yè)政策方面，華為整體的態(tài)度是開(kāi)放的（老板的態(tài)度）。


但到了執(zhí)行層面，就變成了華為優(yōu)先（余總的態(tài)度）。


所有可以預(yù)見(jiàn)未來(lái)一段時(shí)間HarmonyOS會(huì)主要服務(wù)于華為終端的1+8+N戰(zhàn)略。


那么在HarmonyOS證明自己是大勢(shì)所趨之前，其他手機(jī)廠商估計(jì)是和華為是玩不到一起的。

那么華為手機(jī)產(chǎn)能受限的情況下，如何為那關(guān)鍵的「1」也就是手機(jī)終端獲取新的用戶也是一個(gè)需要解決的問(wèn)題。

在第三方應(yīng)用方面，一方面表示每一位開(kāi)發(fā)者都是華為要匯聚的星星之火。


另一方面執(zhí)行起來(lái)，卻是只和大廠合作。


在2021年這個(gè)時(shí)間點(diǎn)，作為還有不到一個(gè)月就要發(fā)布的且宣稱要開(kāi)源的新系統(tǒng)，到現(xiàn)在為止還像寶貝一樣藏起來(lái)、對(duì)非核心開(kāi)發(fā)者像防賊一樣，技術(shù)實(shí)現(xiàn)細(xì)節(jié)語(yǔ)焉不詳，虛擬機(jī)云端運(yùn)行，開(kāi)發(fā)文檔只有UI和分布式軟總線兩部分，其他部分依舊是在Android上的HMS SDK。

這對(duì)很多開(kāi)發(fā)者是不可理喻的。

而將在八月份發(fā)布的Android 12，在三月份已經(jīng)發(fā)布開(kāi)發(fā)者預(yù)覽版。


不說(shuō)別的，僅僅對(duì)比一下兩者的開(kāi)發(fā)文檔：

https://developer.android.google.cn/about/versions/12
https://developer.harmonyos.com/cn/documentation

就不難發(fā)現(xiàn)為什么很多開(kāi)發(fā)者對(duì)HarmonyOS不看好。這也就是HarmonyOS面臨的第四個(gè)問(wèn)題：對(duì)開(kāi)發(fā)者政策問(wèn)題。

02 生態(tài)建設(shè)

操作系統(tǒng)的生態(tài)基本上都是以操作系統(tǒng)為單位，比如MacOS、Windows、iOS
但是由于Android碎片化、海量用戶、谷歌服務(wù)在國(guó)內(nèi)被禁用、國(guó)內(nèi)Android廠商強(qiáng)勢(shì)崛起等等原因，分裂為國(guó)內(nèi)、外兩個(gè)生態(tài)。

在海外，GMS具有壟斷地位，HMS+華為硬件暫時(shí)不具備與之競(jìng)爭(zhēng)的能力。


很多人對(duì)比GMS、HMS時(shí)通常從技術(shù)的角度論證，認(rèn)為HMS比GMS在某些技術(shù)指標(biāo)上的領(lǐng)先，華為在應(yīng)用商店分成上的讓利等等來(lái)證明HMS在海外可以取代GMS，我認(rèn)為這種看法是不符合實(shí)際情況的。

實(shí)際上GMS這個(gè)框架在技術(shù)上確實(shí)沒(méi)有什么難度，但GMS不可取代的并非框架本身，而是GMS連接著的Youtube、Gmail、Gmap、Google Pay、Google Search以及海外Android應(yīng)用所依托的賬號(hào)系統(tǒng)。

HMS與GMS的競(jìng)爭(zhēng)也并非這兩個(gè)框架本身的競(jìng)爭(zhēng)，而是HMS與GMS所承載的獨(dú)占服務(wù)的競(jìng)爭(zhēng)，HMS想要干掉GMS，前提是先干掉這些總用戶20億+的Google系服務(wù)。

在這一方面，華為加上國(guó)內(nèi)一票互聯(lián)網(wǎng)廠商一起上都不一定有勝利的把握，所有短期內(nèi)HMS在海外取代GMS基本上是不可能事件。

另一方面，HMS取代GMS也并非不可能，抖音出海成功之后，越來(lái)越多的中國(guó)互聯(lián)網(wǎng)服務(wù)被海外用戶所接受，中國(guó)互聯(lián)網(wǎng)服務(wù)取代美國(guó)互聯(lián)網(wǎng)服務(wù)并非不可能。但是到那時(shí)候HMS取代GMS依舊面臨兩個(gè)問(wèn)題：

華為終端能否活到那個(gè)時(shí)候。這方面要看華為芯片問(wèn)題能否解決、HMS在缺少關(guān)鍵應(yīng)用的時(shí)候是否有人依舊選擇華為
華為如何說(shuō)服中國(guó)互聯(lián)網(wǎng)廠商拋棄GMS擁抱HMS。因?yàn)閮蓚€(gè)生態(tài)都支持的話HMS對(duì)GMS依舊沒(méi)有話語(yǔ)權(quán)與競(jìng)爭(zhēng)力

在國(guó)內(nèi)，由于Google服務(wù)在國(guó)內(nèi)被禁，又由于GMS這個(gè)框架確實(shí)沒(méi)有什么技術(shù)壁壘，又由于HMOV四家手機(jī)廠商除了華為獨(dú)有芯片設(shè)計(jì)能力之外，在手機(jī)設(shè)計(jì)方面各家技術(shù)實(shí)力相差不大，所以各家都實(shí)現(xiàn)了一套類似GMS的框架：

https://developer.huawei.com/consumer/cn/
https://dev.mi.com/console/
https://open.oppomobile.com/
https://dev.vivo.com.cn/home?cid=w-2-baidu-sem-kfpt-qt

HMOV一個(gè)不落，全都提供類似的移動(dòng)服務(wù)，如果你點(diǎn)開(kāi)看一下，發(fā)現(xiàn)他們提供的服務(wù)內(nèi)容也相差不大。

所以在國(guó)內(nèi)，HMS、MMS、OMS、VMS的市場(chǎng)份額就約等于它們手機(jī)的市場(chǎng)份額，所以騰訊系、阿里系接入HMS并不會(huì)給HMS提供什么額外競(jìng)爭(zhēng)力，因?yàn)樗鼈兘尤肴A為家的HMS，自然也會(huì)同時(shí)接入小米家的MMS、OPPO家的OMS、Vivo家的VMS。

而且它們接入的基本上只有推送服務(wù)，像比較重要的賬號(hào)體系、支付體系都會(huì)牢牢把握在自己手中，甚至即使是推送服務(wù)，它們?yōu)榱吮ＷC自己的業(yè)務(wù)以及消息送達(dá)率，它們?cè)诮尤牍俜酵扑头?wù)后依舊在后臺(tái)維護(hù)這自己獨(dú)有的推送服務(wù)，那些應(yīng)用互啟動(dòng)、推送服務(wù)后臺(tái)耗電問(wèn)題依舊沒(méi)有解決。

所以騰訊系、阿里系接入HMS是肯定的，在HarmonyOS出來(lái)之前，它們很多應(yīng)用就已經(jīng)接入了，但要是說(shuō)騰訊系、阿里系接入HMS可以提高HMS的競(jìng)爭(zhēng)力，恐怕是很多人的一廂情愿。

最后再說(shuō)說(shuō)HarmonyOS的物聯(lián)網(wǎng)生態(tài)

很多人認(rèn)為軟件沒(méi)有實(shí)物，沒(méi)有什么規(guī)則限制，只要想得到，就能做得到。

這也是很多人的一廂情愿，計(jì)算機(jī)科學(xué)是一門科學(xué)，是邏輯的產(chǎn)物，也受相應(yīng)規(guī)則的制約。

對(duì)HarmonyOS來(lái)說(shuō)，它將物聯(lián)網(wǎng)通訊協(xié)議進(jìn)行封裝使通訊更加便捷，提供跨平臺(tái)JS runtime使得UI界面可以一次開(kāi)發(fā)多端運(yùn)行，確實(shí)使得相關(guān)開(kāi)發(fā)更加便利。

但有利必有弊，通常來(lái)說(shuō)，軟件封裝的層次越高，其通用性就越差。

HarmonyOS在針對(duì)某些物聯(lián)網(wǎng)場(chǎng)景進(jìn)行了針對(duì)性的優(yōu)化，確實(shí)意味著在這些物聯(lián)網(wǎng)場(chǎng)景可以進(jìn)行更便捷的開(kāi)發(fā)，但也意味如果你的物聯(lián)網(wǎng)設(shè)備不適用這些場(chǎng)景，那么在HarmonyOS上進(jìn)行開(kāi)發(fā)，會(huì)產(chǎn)生比采用其他平臺(tái)更高的成本。

比如：

對(duì)于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備，沒(méi)有這么奢侈的硬件去運(yùn)行HarmonyOS的物聯(lián)網(wǎng)系統(tǒng)，也并沒(méi)有這么多交互需要界面去實(shí)現(xiàn)，那么采用LiteOS，就意味著對(duì)其沒(méi)有什么幫助還徒增成本（其他物聯(lián)網(wǎng)系統(tǒng)有更通用的解決方案，成本也更低）
HarmonyOS更加私有化的封裝也意味著與其他的物聯(lián)網(wǎng)系統(tǒng)打通更加的困難，華為估計(jì)沒(méi)有能力做的所有物聯(lián)網(wǎng)設(shè)備都采用鴻蒙系統(tǒng)，那么HarmonyOS與為鴻蒙系統(tǒng)物聯(lián)網(wǎng)設(shè)備的交互也更加困難
個(gè)人認(rèn)為物聯(lián)網(wǎng)設(shè)備的互聯(lián)互通與相互控制并不是解決目前物聯(lián)網(wǎng)產(chǎn)業(yè)困境的關(guān)鍵。目前，物聯(lián)網(wǎng)產(chǎn)品的解決方案大多都是講控制權(quán)交給手機(jī)App或者語(yǔ)音，但這些并沒(méi)有多少方便我們的生活，有點(diǎn)食之無(wú)味、棄之可惜的味道

比如：

我的手機(jī)、音箱都可以控制我的烤箱，我的烤箱依舊烤不出好吃的面包、蛋撻
我的手機(jī)、音箱都可以控制我的炒菜鍋，我的炒菜鍋依舊炒出來(lái)的菜該糊的糊，該怎么難吃的還怎么難吃
我的手機(jī)、音箱都可以控制我的空調(diào)，但室內(nèi)溫度依舊不能自動(dòng)調(diào)到讓我感到舒適的溫度
......

我認(rèn)為這些問(wèn)題才是物聯(lián)網(wǎng)產(chǎn)業(yè)目前遇到的問(wèn)題的關(guān)鍵。

而這也是為什么我不看好HarmonyOS的物聯(lián)網(wǎng)生態(tài)布局，它確實(shí)將原來(lái)的物聯(lián)網(wǎng)設(shè)備開(kāi)發(fā)成本降低了一個(gè)數(shù)量級(jí)，但是依舊沒(méi)有解決上面的這些問(wèn)題，畢竟，就算所有物聯(lián)網(wǎng)設(shè)備都可以暢通無(wú)阻的通訊又有什么用呢？我買它們有不是讓它們來(lái)說(shuō)悄悄話的！！！
......

（這個(gè)問(wèn)題太大了，需要考慮的問(wèn)題太多，能力有限，既考慮不全，也表達(dá)不太清楚，不往下寫了）

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??