來源：21ic電子網(wǎng)，頭條@我的小號等，本文作者觀點不代表本網(wǎng)觀點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對比官方給出的App邏輯視圖：

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

1、沒有找到描述每個HAP屬性的pack.info

估計是因為工程只定義了一個Entry，沒有定義Feature，于是只生成了Entry的安裝包，但是按照官方文檔給的說法

Entry可以獨立安裝運行，在只定義一個Entry的情況下，編譯出這種包也說得通

2、App邏輯視圖中的config.json正常在

3、App邏輯視圖中的abilities竟然編譯成Android包的.dex執(zhí)行文件，而用js定義的界面、視圖、邏輯竟然歸入assets中，這里面就有點貓膩了

4、編譯的可執(zhí)行文件中竟然包含一個.apk文件，這個不速之客可在App邏輯視圖中完全沒體現(xiàn)，值得懷疑

于是接下來，我們就先重點分析這個entry_signed_entry.apk，分析一下這個不速之客在App安裝包里有什么作用

02 分析entry_signed_entry.apk

繼續(xù)用Android Studio打開這個文件

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

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

1、定義Application為ShellApplication

2、定義MainActivity為MainAbilityShellActivity

emmmmm……這名字起得真直白

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

果然不費吹灰之力，接著分析源代碼：

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

ShellMyApplication繼承自HarmonyOS SDK的AceHarmonyApplication，不過啥事都沒干，接著看AceHarmonyApplication：

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

HarmonyApplication：

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

1、初始化HarmonyOS應(yīng)用...

2、輸出HarmonyOS應(yīng)用開始初始化的日志......

3、加載HarmonyOS的Ability到Android的Application的HashMap中.........

4、接收系統(tǒng)產(chǎn)生的各種事件然后轉(zhuǎn)發(fā)給鴻蒙應(yīng)用............

5、初始化一個EventRunner，結(jié)合ohos包的代碼來看，估計就是官方文檔提到的「分布式軟總線」，是HarmonyOS所謂的「分布式設(shè)計」的相關(guān)實現(xiàn)，這部分后面分析

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

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

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

MainAbilityShellActivity依舊繼承自Android的Activity，整個文件依舊很長，但是邏輯很簡單，就一個作用：

將Android的MainActivity的生命周期、Intent、觸摸事件、按鍵時間、權(quán)限申請結(jié)果……通過AbilityShellActivityDelegate（代理）轉(zhuǎn)發(fā)給HarmonyOS的Ability

果然不負(fù)Shell之名。本來想打開Androi……HarmonyOS的應(yīng)用布局調(diào)試界面，但是設(shè)置里找不到了，233333……

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

這篇文章2020年末寫的，到如今只過去五個月，估計具體實現(xiàn)沒有改變。

03 分布式軟總線

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

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

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

分別是：

分布式任務(wù)調(diào)度

分布式數(shù)據(jù)服務(wù)

分布式文件服務(wù)

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

打開ohos.jar包后，遇到了第一個問題：所有代碼都不給看?。?！

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

不過我們只是為了看一下HarmonyOS的設(shè)計思想，又不研究它具體實現(xiàn)，所有也用不著源代碼，直接看類名、函數(shù)名、依賴關(guān)系，大膽猜測、小心驗證一下就好了

通過分析依賴關(guān)系，發(fā)現(xiàn)，大多數(shù)與分布式相關(guān)的包都依賴于：

ohos.rpc.*

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

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

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

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

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

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

上面說的再斬釘截鐵，最終也不過是猜想。

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

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

這時候靈感一閃，既然HarmonyOS是「全場景分布式系統(tǒng)」，那么這套協(xié)議肯定不止在Androi......HarmonyOS手機(jī)系統(tǒng)上實現(xiàn)，在其他類型設(shè)備上肯定有相關(guān)實現(xiàn)

這時候按揭開源的OpenHarmony再次回到我的視線，既然OpenHarmony項目已經(jīng)開源了嵌入式設(shè)備的相關(guān)實現(xiàn)，那么沒準(zhǔn)里面就有這套協(xié)議的相關(guān)源碼。

于是，我們來翻一下OpenHarmony的倉庫:

https://gitee.com/openharmony

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

https://gitee.com/openharmony/communication_services_softbus_lite

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

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

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

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

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

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

05 其他

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

https://gitee.com/openharmony/ace_engine_lite

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

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

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

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

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

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

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

小程序：運行中各自App環(huán)境內(nèi)部

Flutter：致力于移動端、桌面端、Web、嵌入式全覆蓋

Ability：主要為華為生態(tài)中的手機(jī)以及嵌入式設(shè)備設(shè)計

雖然它們各自的所追求的目標(biāo)不同，但它們設(shè)計思想都是類似的：自繪UI，屏蔽系統(tǒng)差異

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

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

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

具體到示意圖，估計就是：

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

隨時換掉AOSP，這里的「隨時」，估計在近五年內(nèi)不會實現(xiàn)，在此之前，去掉Android虛擬機(jī)，HarmonyOS能不能正常運行，我是持懷疑的態(tài)度的

「全場景分布式操作系統(tǒng)」，根據(jù)「分布式軟總線」相關(guān)代碼，這里的「全場景」，估計是同一個局域網(wǎng)內(nèi)的「全場景」、同一個局域網(wǎng)內(nèi)的萬物互聯(lián)

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

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

02 HarmonyOS到底是不是Android套皮

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

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

說它是吧，它也確實是從Android發(fā)展出來的

說它不是吧，它也確實和Android有了明顯的差異和特色

不過這時候，我發(fā)現(xiàn)這個問題和一個提出了2000年的哲學(xué)悖論很像：忒修斯之船

特修斯之船（The Ship of Theseus）亦稱為忒修斯悖論，是一種有關(guān)身份更替的悖論。假定某物體的構(gòu)成要素被置換后，但它依舊是原來的物體嗎？說是一艘可以在海上航行幾百年的船，歸功于不間斷的維修和替換部件。只要一塊木板腐爛了，它就會被替換掉，以此類推，直到所有的功能部件都不是最開始的那些了。問題是，最終產(chǎn)生的這艘船是否還是原來的那艘特修斯之船，還是一艘完全不同的船？如果不是原來的船，那么在什么時候它不再是原來的船了？

回到這個問題：

我替換掉Android一行代碼，那么它還是Android嗎？

我替換掉Android一個模塊，那么它還是Android嗎？

我給Android添加一個模塊，那么它還是Android嗎？

......

這個問題哲學(xué)家辯了兩千年，相信我們這一時半會兒也辯不出來，而且爭辯這個問題也沒有太多的意義

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

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

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

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

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

目前HarmonyOS有兩個獨有的特性：

1、一個跨平臺的JavaScript應(yīng)用框架（后面我們稱之為Ace Engine，理由在下面）

2、分布式軟總線

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

1). HarmonyOS雖然號稱可以使用Java、JavaScript、C寫UI界面且UI界面可以跨設(shè)備，但目前在實際開發(fā)中，不同設(shè)備支持的語言是不同的：

在手機(jī)設(shè)備上，只能使用Java、JavaScript寫界面（相關(guān)文檔 ：Java UI框架、JS UI框架 兩部分）

在嵌入式設(shè)備上，只能使用C、JavaScript寫界面（相關(guān)文檔 ：JS應(yīng)用開發(fā)、系統(tǒng)基礎(chǔ)子系統(tǒng)集>圖形及UI子系統(tǒng) 兩部分）

只有JavaScript寫的界面可以跨設(shè)備使用

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

2). 這個JavaScript應(yīng)用框

架的嵌入式部分代碼已經(jīng)開源了，就是上面提到的：

https://gitee.com/openharmony/ace_engine_lite

框架圖如下：

其中：

JS引擎（JS runtime）是三星開源的IoT JavaScript引擎：JerryScript

除JS引擎外，其他應(yīng)該都是華為自己寫的

JS應(yīng)用框架只負(fù)責(zé)解析JS Bundle（我們用JS寫的界面編譯后的產(chǎn)物），渲染交給了有C寫的原生框架

因此C原生框架不可能跨設(shè)備，只能在LiteOS中使用

手機(jī)端能不能使用這個C原生UI框架未知，但是開發(fā)文檔上沒有提及，應(yīng)該是還沒有開放或?qū)崿F(xiàn)（是哪一個不太清楚，但是嵌入式設(shè)備與手機(jī)UI框架的實現(xiàn)難度不是一個數(shù)量級，LiteOS上的C語言UI框架應(yīng)該滿足不了手機(jī)上的復(fù)雜且苛刻的要求，所有不可能直接使用）

因為這個JS應(yīng)用框架的LiteOS開源部分被命名為ace_engine_lite，所以我們暫時將這個應(yīng)用框架稱為Ace Engine

3). 這個JS應(yīng)用框架的手機(jī)版本還沒有開源，所以我們不知道具體實現(xiàn)，但是我們在上面的文章中提到過：

JS Bundle由JS Framework解析后將數(shù)據(jù)交給了Android，由Android的負(fù)責(zé)將其渲染在SurfaceView上

這就是我為什么質(zhì)疑目前HarmonyOS離不開AOSP的原因

這也是我為什么認(rèn)定HarmonyOS可以掏空AOSP的原因

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

其中：

User Native Ability在LiteOS中指的就是C語言實現(xiàn)的Ability；在HarmonyOS中就是Java實現(xiàn)的Ability

AbilityKit在LiteOS中應(yīng)該是用C語言自己實現(xiàn)的，但在HarmonyOS中，是基于Android的Activity實現(xiàn)的

圖中的藍(lán)色部分在LiteOS中很明確，但在HarmonyOS中怎么實現(xiàn)目前沒有相關(guān)代碼，不得而知（個人猜測，根據(jù)上面代碼分析，有部分在ShellApplication（應(yīng)用內(nèi)）實現(xiàn)，有部分為系統(tǒng)服務(wù)，也有部分在內(nèi)核中實現(xiàn)）

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

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

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

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

Linux Kernel（在內(nèi)核層中）

AOSP（大致對應(yīng)圖中的UI框架+用戶程序框架+Ability框架）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再看看Ace Engine:

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

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

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

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

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

鴻蒙主管在采訪中說：

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

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

到時候不說手機(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)用，可以支持更多的平臺（HarmonyOS vs Android+IOS）

在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，開發(fā)成本更低（小程序 vs App）

在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，推廣成本更低（微信小程序生態(tài) vs 華為App生態(tài)）

在微信小程序中做物聯(lián)網(wǎng)應(yīng)用，獲客成本更低（即開即用 vs 下載、安裝App）

……

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

而一旦想法驗證通過，又有幾個服務(wù)不會全平臺支持，而主動與一個平臺綁定？

這就是HarmonyOS想要成功所需要解決的第一個問題：

如果「分布式軟總線」這條路是無價值的，那么作為HarmonyOS最大的賣點，HarmonyOS所做的種種努力都是白費的，HarmonyOS最終就會走向失??；

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

01 商業(yè)運作

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

足夠多的用戶

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

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

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

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

在目前這個時間點，HarmonyOS生態(tài)抗衡GMS生態(tài)的可能性微乎其微，所以第一批升級HarmonyOS的絕大多數(shù)應(yīng)該都是國內(nèi)用戶，那這部分手機(jī)存量在2.2億左右

由于GMS被禁用，華為的海外市場估計會繼續(xù)迅速萎縮。

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

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

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

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

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

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

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

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

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

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

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

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

不說別的，僅僅對比一下兩者的開發(fā)文檔：

https://developer.android.google.cn/about/versions/12

https://developer.harmonyos.com/cn/documentation

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

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

操作系統(tǒng)的生態(tài)基本上都是以操作系統(tǒng)為單位，比如MacOS、Windows、iOS

但是由于Android碎片化、海量用戶、谷歌服務(wù)在國內(nèi)被禁用、國內(nèi)Android廠商強(qiáng)勢崛起等等原因，分裂為國內(nèi)、外兩個生態(tài)。

在海外，GMS具有壟斷地位，HMS+華為硬件暫時不具備與之競爭的能力。

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

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

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

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

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

華為終端能否活到那個時候。這方面要看華為芯片問題能否解決、HMS在缺少關(guān)鍵應(yīng)用的時候是否有人依舊選擇華為

華為如何說服中國互聯(lián)網(wǎng)廠商拋棄GMS擁抱HMS。因為兩個生態(tài)都支持的話HMS對GMS依舊沒有話語權(quán)與競爭力

在國內(nèi)，由于Google服務(wù)在國內(nèi)被禁，又由于GMS這個框架確實沒有什么技術(shù)壁壘，又由于HMOV四家手機(jī)廠商除了華為獨有芯片設(shè)計能力之外，在手機(jī)設(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一個不落，全都提供類似的移動服務(wù)，如果你點開看一下，發(fā)現(xiàn)他們提供的服務(wù)內(nèi)容也相差不大。

所以在國內(nèi)，HMS、MMS、OMS、VMS的市場份額就約等于它們手機(jī)的市場份額，所以騰訊系、阿里系接入HMS并不會給HMS提供什么額外競爭力，因為它們接入華為家的HMS，自然也會同時接入小米家的MMS、OPPO家的OMS、Vivo家的VMS。

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

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

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

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

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

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

但有利必有弊，通常來說，軟件封裝的層次越高，其通用性就越差。

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

比如：

對于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備，沒有這么奢侈的硬件去運行HarmonyOS的物聯(lián)網(wǎng)系統(tǒng)，也并沒有這么多交互需要界面去實現(xiàn)，那么采用LiteOS，就意味著對其沒有什么幫助還徒增成本（其他物聯(lián)網(wǎng)系統(tǒng)有更通用的解決方案，成本也更低）

HarmonyOS更加私有化的封裝也意味著與其他的物聯(lián)網(wǎng)系統(tǒng)打通更加的困難，華為估計沒有能力做的所有物聯(lián)網(wǎng)設(shè)備都采用鴻蒙系統(tǒng)，那么HarmonyOS與為鴻蒙系統(tǒng)物聯(lián)網(wǎng)設(shè)備的交互也更加困難

個人認(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或者語音，但這些并沒有多少方便我們的生活，有點食之無味、棄之可惜的味道

比如：

我的手機(jī)、音箱都可以控制我的烤箱，我的烤箱依舊烤不出好吃的面包、蛋撻

我的手機(jī)、音箱都可以控制我的炒菜鍋，我的炒菜鍋依舊炒出來的菜該糊的糊，該怎么難吃的還怎么難吃

我的手機(jī)、音箱都可以控制我的空調(diào)，但室內(nèi)溫度依舊不能自動調(diào)到讓我感到舒適的溫度

......

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

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

......

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

[超站]友情鏈接：

四季很好，只要有你，文娛排行榜：https://www.yaopaiming.com/
關(guān)注數(shù)據(jù)與安全，洞悉企業(yè)級服務(wù)市場：https://www.ijiandao.com/