鴻蒙OS到底是不是Android套皮？（終于講明白了）

程序員的成長之路

互聯(lián)網/程序員/技術/資料共享 

閱讀本文大概需要 20 分鐘。

來自：21ic電子網，頭條@我的小號

某人曾說「沒有調查就沒有發(fā)言權」

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

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

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

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

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

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

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

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

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


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


1）分析編譯產物

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

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


.hap？？？怎么和預想的不一樣？不過侵淫Linux多年的經驗告訴我，后綴都是浮云，于是果斷把.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安裝包里有什么作用

2、分析entry_signed_entry.apk

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


是一個標準的Android App??！于是熟練的點開Android應用描述文件：AndroidManifest.xml

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

定義Application為ShellApplication
定義MainActivity為MainAbilityShellActivity

emmmmm……這名字起得真直白

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


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

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


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


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

HarmonyApplication：


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

1、初始化HarmonyOS應用...
2、輸出HarmonyOS應用開始初始化的日志......
3、加載HarmonyOS的Ability到Android的Application的HashMap中.........


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

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

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

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


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

將Android的MainActivity的生命周期、Intent、觸摸事件、按鍵時間、權限申請結果……通過AbilityShellActivityDelegate（代理）轉發(fā)給HarmonyOS的Ability
果然不負Shell之名。本來想打開Androi……HarmonyOS的應用布局調試界面，但是設置里找不到了，233333……

不過根據我的第一個鴻蒙app，以及所見內容,得知


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

3、 分布式軟總線

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

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

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


分別是：
分布式任務調度
分布式數(shù)據服務
分布式文件服務

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

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


Java開發(fā)中，這種情況比較少見，只有一些重要的、底層的API中可能會出現(xiàn)，不過這個ohos.jar包源碼全部隱藏還是第一次見！?。?span style="max-width: 100%;color: rgb(30, 106, 255);">HarmonyOS到底有多怕發(fā)現(xiàn)它的小秘密。

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

ohos.rpc.*

以及官方文檔中有關「分布式任務調度」所依賴的包


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


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

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

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

04 「分布式軟總線」具體設計

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

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

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

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

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

https://gitee.com/openharmony

皇天不負有心人，與「分布式軟總線」相關：

https://gitee.com/openharmony/communication_services_softbus_lite

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

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

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

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


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


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




5、其他

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

https://gitee.com/openharmony/ace_engine_lite

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


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

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

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

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

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

它們三者之間的區(qū)別：

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

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

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

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

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


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

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

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

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

02 HarmonyOS到底是不是Android套皮

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

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

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

回到這個問題：

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

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

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

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

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

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

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

目前HarmonyOS有兩個獨有的特性：
1、一個跨平臺的JavaScript應用框架（后面我們稱之為Ace Engine，理由在下面）
2、分布式軟總線

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

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

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

2). 這個JavaScript應用框
架的嵌入式部分代碼已經開源了，就是上面提到的：

https://gitee.com/openharmony/ace_engine_lite

框架圖如下：


其中：

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

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

3). 這個JS應用框架的手機版本還沒有開源，所以我們不知道具體實現(xiàn)，但是我們在上面的文章中提到過：
JS Bundle由JS Framework解析后將數(shù)據交給了Android，由Android的負責將其渲染在SurfaceView上

這就是我為什么質疑目前HarmonyOS離不開AOSP的原因
這也是我為什么認定HarmonyOS可以掏空AOSP的原因

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


其中：

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

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

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

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


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

Linux Kernel（在內核層中）
AOSP（大致對應圖中的UI框架+用戶程序框架+Ability框架）

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

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

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

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

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

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

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

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

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


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

8、先從技術層面看看:

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

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

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

再看看Ace Engine:

熟悉編程的朋友一定知道，Ace Engine與小程序以及Flutter的設計思想與架構完全一樣，F(xiàn)lutter由于Dart虛擬機無法運行中資源有限的嵌入式設備中，無法做到，那小程序對比如何呢？

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


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

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

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

鴻蒙主管在采訪中說：


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

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

到時候不說手機廠商，就以微信為例：

除了構建在應用內的RPC協(xié)議不如構建在系統(tǒng)內RPC協(xié)議性能指標好外：

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

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

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

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

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

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

01 商業(yè)運作

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

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

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

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


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

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

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


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


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


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


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


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

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

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


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


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

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

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


不說別的，僅僅對比一下兩者的開發(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)建設

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

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


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

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

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

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

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

華為終端能否活到那個時候。這方面要看華為芯片問題能否解決、HMS在缺少關鍵應用的時候是否有人依舊選擇華為
華為如何說服中國互聯(lián)網廠商拋棄GMS擁抱HMS。因為兩個生態(tài)都支持的話HMS對GMS依舊沒有話語權與競爭力

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

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

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

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

9、最后再說說HarmonyOS的物聯(lián)網生態(tài)

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

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

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

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

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

比如：

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

比如：

我的手機、音箱都可以控制我的烤箱，我的烤箱依舊烤不出好吃的面包、蛋撻
我的手機、音箱都可以控制我的炒菜鍋，我的炒菜鍋依舊炒出來的菜該糊的糊，該怎么難吃的還怎么難吃
我的手機、音箱都可以控制我的空調，但室內溫度依舊不能自動調到讓我感到舒適的溫度
......

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

<END>

推薦閱讀：

微信和QQ，終于可以互通了！

處理 Exception 的幾種實踐，被很多團隊采納！

互聯(lián)網初中高級大廠面試題(9個G)

內容包含Java基礎、JavaWeb、MySQL性能優(yōu)化、JVM、鎖、百萬并發(fā)、消息隊列、高性能緩存、反射、Spring全家桶原理、微服務、Zookeeper、數(shù)據結構、限流熔斷降級......等技術棧！

?戳閱讀原文領??！                                       朕已閱