HarmonyOS到底是不是Android套皮？
上一篇：3600萬中國人在抖音“上清華”
某人曾說「沒有調(diào)查就沒有發(fā)言權(quán)」 最近鴻蒙系統(tǒng)關(guān)注度好高，支持與反對、看好和看衰、「自主的全場景分布式系統(tǒng)」和「Android套殼」各執(zhí)一詞，吵的不可開交。 作為十八流碼農(nóng)，本著了解行業(yè)動態(tài)、體驗(yàn)HarmonyOS開發(fā)流程、找出HarmonyOS的特性與不足、看看是否有新的機(jī)會，也為了看看吵得不可開交的諸位誰說得對，特地在這個鴻蒙系統(tǒng)馬上正式開放升級的時間點(diǎn)，開發(fā)體驗(yàn)了一番。 HarmonyOS到底怎么實(shí)現(xiàn)的——扒皮HarmonyOS
了解一個軟件怎么實(shí)現(xiàn)的，最好還是查看源代碼。 但是承諾2020年開源的OpenHarmony項(xiàng)目到現(xiàn)在只開源到嵌入式設(shè)備，這條路自然走不通。 只好退而求其次，看看已經(jīng)開放的SDK、IDE、開發(fā)示例、編譯產(chǎn)物，管中窺豹一下HarmonyOS到底怎么實(shí)現(xiàn)的。
00 安裝IDE-配置環(huán)境-編譯運(yùn)行
這部分很簡單，下載DevEco Studio，然后照著文檔一步步操作就好了。 模板選擇了唯二的JS模板：Phone > Refresh Feature Ability。 然后一直下一步，申請下虛擬機(jī)，編譯運(yùn)行就成功了。
01 分析編譯產(chǎn)物
運(yùn)行成功后，先大致分析一下編譯產(chǎn)物，找一下程序入口，看看代碼到底怎么運(yùn)行的。 點(diǎn)開build文件夾，打開一看，喔噢！！！這目錄結(jié)構(gòu)和Android的太相似了，于是我熟練的點(diǎn)開outputs文件夾找apk文件。 .hap？？？怎么和預(yù)想的不一樣？不過侵淫Linux多年的經(jīng)驗(yàn)告訴我，后綴都是浮云，于是果斷把.hap改成.apk，然后用Android Studio打開，果然：
對比官方給出的App邏輯視圖： 我們發(fā)現(xiàn)： 估計(jì)是因?yàn)楣こ讨欢x了一個Entry，沒有定義Feature，于是只生成了Entry的安裝包，但是按照官方文檔給的說法
Entry可以獨(dú)立安裝運(yùn)行，在只定義一個Entry的情況下，編譯出這種包也說得通
3、App邏輯視圖中的abilities竟然編譯成Android包的.dex執(zhí)行文件，而用js定義的界面、視圖、邏輯竟然歸入assets中，這里面就有點(diǎn)貓膩了
4、編譯的可執(zhí)行文件中竟然包含一個.apk文件，這個不速之客可在App邏輯視圖中完全沒體現(xiàn)，值得懷疑
于是接下來，我們就先重點(diǎn)分析這個entry_signed_entry.apk，分析一下這個不速之客在App安裝包里有什么作用
02 分析entry_signed_entry.apk
繼續(xù)用Android Studio打開這個文件 是一個標(biāo)準(zhǔn)的Android App！！于是熟練的點(diǎn)開Android應(yīng)用描述文件：AndroidManifest.xml 通過描述文件可以發(fā)現(xiàn)，整個apk只做了兩件事： emmmmm……這名字起得真直白 按照Android開發(fā)的慣例，從build文件夾中找這兩個類的相關(guān)文件。 果然不費(fèi)吹灰之力，接著分析源代碼： 先分析一下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包的代碼來看，估計(jì)就是官方文檔提到的「分布式軟總線」，是HarmonyOS所謂的「分布式設(shè)計(jì)」的相關(guān)實(shí)現(xiàn)，這部分后面分析
碼農(nóng)果然都是老實(shí)人，起名都這么實(shí)誠又恰如其分： ShellApplication的作用就是Android的Application提供一個Shell（殼），讓HarmonyOS的Application寄生其中 接著來看看MainAbilityShellActivity，依舊是套娃設(shè)計(jì)，直接看具體的實(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年末寫的，到如今只過去五個月，估計(jì)具體實(shí)現(xiàn)沒有改變。 03 分布式軟總線
HarmonyOS最大的賣點(diǎn)是其宣稱的「面向萬物互聯(lián)時代的全場景分布式操作系統(tǒng)」，也是其最大的特性。 從官方文檔來看，不管是開發(fā)層面所謂的「分布式設(shè)備虛擬化」、「分布式數(shù)據(jù)管理」、「分布式任務(wù)調(diào)度」，還是目前官方演示的「無縫流轉(zhuǎn)」、「多屏協(xié)同」都是以「分布式軟總線」為通訊基座，因此我們重點(diǎn)來找找它是怎么實(shí)現(xiàn)的。 具體到開發(fā)文檔中，沒有發(fā)現(xiàn)關(guān)于「分布式軟總線」的API，只找到三個與其「分布式技術(shù)」所描述的特性相似的三個功能： 分別是： 有了這三組API，我們就可以通過「排列組合」實(shí)現(xiàn)其官網(wǎng)所宣稱的所有關(guān)于「分布式」的特性，所以，我們直接到SDK中找這三組API怎么實(shí)現(xiàn)的就可以追根溯源找到「分布式軟總線」具體怎么實(shí)現(xiàn)的了 打開ohos.jar包后，遇到了第一個問題：所有代碼都不給看！！！ Java開發(fā)中，這種情況比較少見，只有一些重要的、底層的API中可能會出現(xiàn)，不過這個ohos.jar包源碼全部隱藏還是第一次見！！！HarmonyOS到底有多怕發(fā)現(xiàn)它的小秘密。 不過我們只是為了看一下HarmonyOS的設(shè)計(jì)思想，又不研究它具體實(shí)現(xiàn)，所有也用不著源代碼，直接看類名、函數(shù)名、依賴關(guān)系，大膽猜測、小心驗(yàn)證一下就好了
通過分析依賴關(guān)系，發(fā)現(xiàn)，大多數(shù)與分布式相關(guān)的包都依賴于： ohos.rpc.* 以及官方文檔中有關(guān)「分布式任務(wù)調(diào)度」所依賴的包 以及官方文檔「分布式軟總線示意圖」 我們有理由相信：所謂的「分布式軟總線」實(shí)際上是一個私有的RPC協(xié)議 結(jié)合RPC的特點(diǎn)和HarmonyOS的特性，HarmonyOS的「分布式軟總線」采用RPC就就根本不奇怪。 不過，阿華不愧是立志要模仿、超越阿果的公司，連起名都一樣的鬼才：如此專業(yè)的名詞都能起得如此通俗易懂！
04 「分布式軟總線」具體設(shè)計(jì)
上面說的再斬釘截鐵，最終也不過是猜想。 而且作為HarmonyOS的核心特性和殺手锏，作為十八線碼農(nóng)、不入流從業(yè)人員，怎么能不會對其設(shè)計(jì)思想產(chǎn)生好奇？ 不過苦于沒有源代碼，以及估計(jì)絕大部分都是在系統(tǒng)層實(shí)現(xiàn)的，ohos.jar里也不過是相關(guān)調(diào)用，這條路肯定是行不通。 這時候靈感一閃，既然HarmonyOS是「全場景分布式系統(tǒng)」，那么這套協(xié)議肯定不止在Androi......HarmonyOS手機(jī)系統(tǒng)上實(shí)現(xiàn)，在其他類型設(shè)備上肯定有相關(guān)實(shí)現(xiàn) 這時候按揭開源的OpenHarmony再次回到我的視線，既然OpenHarmony項(xiàng)目已經(jīng)開源了嵌入式設(shè)備的相關(guān)實(shí)現(xiàn)，那么沒準(zhǔn)里面就有這套協(xié)議的相關(guān)源碼。 于是，我們來翻一下OpenHarmony的倉庫: 皇天不負(fù)有心人，與「分布式軟總線」相關(guān)：
https://gitee.com/openharmony/communication_services_softbus_lite 這個項(xiàng)目實(shí)現(xiàn)了軟總線發(fā)現(xiàn)、組網(wǎng)、傳輸相關(guān)協(xié)議，熟悉編程的朋友應(yīng)該能想得到，有了這個項(xiàng)目，「全場景分布式」所列舉的所有特性都可以實(shí)現(xiàn)了。 代碼部分又臭又長，而且估計(jì)很多人也不感興趣，也不確定全平臺的都是這樣實(shí)現(xiàn)的，就不具體分析了，只說一下設(shè)計(jì)思想和大致工作流程，不同平臺具體實(shí)現(xiàn)可能有所不同，不過設(shè)計(jì)思想應(yīng)該不會差太多。 「分布式軟總線」主要有以下幾個工作模塊： 1、設(shè)備發(fā)現(xiàn)：采用了CoAP協(xié)議作為設(shè)備發(fā)現(xiàn)協(xié)議，通過發(fā)送在一個局域網(wǎng)內(nèi)發(fā)送廣播來發(fā)現(xiàn)設(shè)備，具體實(shí)現(xiàn)與本文無關(guān)，就不展開了，感興趣的可以自己去看，在這個包里： 2、數(shù)據(jù)傳輸：基于Session提供統(tǒng)一的數(shù)據(jù)傳輸功能，不過網(wǎng)絡(luò)通信是華為的老本行了，估計(jì)挑不出什么毛病，就仔細(xì)分析了，代碼在： 3、設(shè)備認(rèn)證與管理：這部分主要是為了安全的，代碼在：
05 其他
整個OpenHarmony項(xiàng)目，還有一些有趣的實(shí)現(xiàn)： https://gitee.com/openharmony/ace_engine_lite
這個應(yīng)該就是JS開發(fā)的Ability界面如何編譯以及在嵌入式設(shè)備上如何渲染的相關(guān)實(shí)現(xiàn)，這也應(yīng)該是為什么HarmonyOS可以采用多種語言開發(fā)界面的原因所在： 各種小程序、Flutter相關(guān)框架都是這樣設(shè)計(jì)的，全都是用來實(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)中運(yùn)行。 在HarmonyOS之前，與之類似的技術(shù)且比較成功的有各家的小程序框架以及Flutter。 它們?nèi)咧g的區(qū)別： 小程序：運(yùn)行中各自App環(huán)境內(nèi)部 Flutter：致力于移動端、桌面端、Web、嵌入式全覆蓋 Ability：主要為華為生態(tài)中的手機(jī)以及嵌入式設(shè)備設(shè)計(jì) 雖然它們各自的所追求的目標(biāo)不同，但它們設(shè)計(jì)思想都是類似的：自繪UI，屏蔽系統(tǒng)差異 2、定義了一個以「分布式軟總線」為名的自有RPC協(xié)議框架，以此RPC協(xié)議為基礎(chǔ)封裝了一系列常用的API，屏蔽了設(shè)備之間的繁瑣、多種多樣、差異很大的通訊方式，提供了穩(wěn)定、統(tǒng)一、可靠的近場通訊協(xié)議。 再具體到華為手機(jī)上將要升級的HarmonyOS，估計(jì)是： 原有的Android系統(tǒng) - GMS + HMS + 分布式軟總線 + 以Ability為核心的應(yīng)用開發(fā)框架 = HarmonyOS 具體到示意圖，估計(jì)就是：
從分析結(jié)果來看，HarmonyOS有些地方確實(shí)夸大宣傳了，比如：
隨時換掉AOSP，這里的「隨時」，估計(jì)在近五年內(nèi)不會實(shí)現(xiàn)，在此之前，去掉Android虛擬機(jī)，HarmonyOS能不能正常運(yùn)行，我是持懷疑的態(tài)度的 「全場景分布式操作系統(tǒng)」，根據(jù)「分布式軟總線」相關(guān)代碼，這里的「全場景」，估計(jì)是同一個局域網(wǎng)內(nèi)的「全場景」、同一個局域網(wǎng)內(nèi)的萬物互聯(lián) 當(dāng)然，對于HarmonyOS的絕大多數(shù)宣傳，按目前的設(shè)計(jì)思路，完全有可能實(shí)現(xiàn)或者已經(jīng)實(shí)現(xiàn)了，比如： 02 HarmonyOS到底是不是Android套皮
回到我們最初的問題：「HarmonyOS到底是個全新的自主操作系統(tǒng)還是個套殼安卓？」 分析完代碼后，我發(fā)現(xiàn)我也不能回答這個問題： 說它是吧，它也確實(shí)是從Android發(fā)展出來的 說它不是吧，它也確實(shí)和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能實(shí)現(xiàn)華為在華為終端上定下的目標(biāo)嗎？」
03 HarmonyOS能實(shí)現(xiàn)華為的目標(biāo)嗎？
這部分本來想討論HarmonyOS的發(fā)展前景以及能不能取得成功。但是想要看清這件事，需要扎實(shí)的理論知識、豐富的行業(yè)經(jīng)驗(yàn)，還要對商業(yè)活動有一定的見解，有這個能力的人，早就是行業(yè)泰斗、技術(shù)大咖了。 所以找了幾天資料依舊沒什么思路，因此想悄悄咪咪的把這個坑給鴿了。但沒想到看得人這么多，這下都不知道怎么鴿了，就只能強(qiáng)行人云亦云一波。通常來講，影響一個商業(yè)操作系統(tǒng)成敗的因素有很多，但大體上都是從三個大方向進(jìn)行分析：系統(tǒng)優(yōu)勢、商業(yè)運(yùn)作、生態(tài)建設(shè)。那么我們也從這三個方面探討一下HarmonyOS有沒有可能成功。 00 系統(tǒng)優(yōu)勢
目前HarmonyOS有兩個獨(dú)有的特性： 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è)備，但目前在實(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框架的實(shí)現(xiàn)難度不是一個數(shù)量級，LiteOS上的C語言UI框架應(yīng)該滿足不了手機(jī)上的復(fù)雜且苛刻的要求，所有不可能直接使用） 因?yàn)檫@個JS應(yīng)用框架的LiteOS開源部分被命名為ace_engine_lite，所以我們暫時將這個應(yīng)用框架稱為Ace Engine 3). 這個JS應(yīng)用框架的手機(jī)版本還沒有開源，所以我們不知道具體實(shí)現(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語言實(shí)現(xiàn)的Ability；在HarmonyOS中就是Java實(shí)現(xiàn)的Ability AbilityKit在LiteOS中應(yīng)該是用C語言自己實(shí)現(xiàn)的，但在HarmonyOS中，是基于Android的Activity實(shí)現(xiàn)的 圖中的藍(lán)色部分在LiteOS中很明確，但在HarmonyOS中怎么實(shí)現(xiàn)目前沒有相關(guān)代碼，不得而知（個人猜測，根據(jù)上面代碼分析，有部分在ShellApplication（應(yīng)用內(nèi)）實(shí)現(xiàn)，有部分為系統(tǒng)服務(wù)，也有部分在內(nèi)核中實(shí)現(xiàn)） 5). HarmonyOS所宣稱的雙內(nèi)核，其中一個是AOSP，那么另一個就應(yīng)該是4中這個以Ability為核心的應(yīng)用框架。 且不論其是否符合操作系統(tǒng)的定義，僅由于3的存在，現(xiàn)在這個階段這個內(nèi)核的獨(dú)立性是存疑的。 當(dāng)然，也因?yàn)?的存在，按照這條設(shè)計(jì)思路走下去，那么HarmonyOS最終實(shí)現(xiàn)其畫的架構(gòu)圖是可以確定的。 其實(shí)上面這些框框里面所說的東西的其中一部分都已經(jīng)實(shí)現(xiàn)了，還有一部分由于時間原因沒有實(shí)現(xiàn)，但技術(shù)已經(jīng)被我國工程師所掌握，實(shí)現(xiàn)起來也是時間問題，除了的兩部分：
Linux Kernel（在內(nèi)核層中） AOSP（大致對應(yīng)圖中的UI框架+用戶程序框架+Ability框架） 別看這倆數(shù)量上很少，但是坑很深，目前國內(nèi)搞不定的也就這兩部分。 為什么替換不掉Linux Kernel？這個國內(nèi)真的沒人能搞得定這個（操作系統(tǒng)）。 為什么不替換掉AOSP？我們是為了兼容；那為什么Ability要交給AOSP去渲染呢？那是因?yàn)閲鴥?nèi)也沒有人能搞得定這個（計(jì)算機(jī)圖形學(xué)）。 以及為什么LiteOS中的JS Framework都自己實(shí)現(xiàn)，但唯獨(dú)JS runtime還要用三星開源的JerryScript呢（手機(jī)版不知道用的啥）？因?yàn)檫@個國內(nèi)也沒有人搞得定（編譯原理）。 操作系統(tǒng)、計(jì)算機(jī)圖形學(xué)、編譯原理，這仨貨是計(jì)算機(jī)三大天坑，其中艱難險(xiǎn)阻，非專業(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ā)多端部署得以實(shí)現(xiàn)。 分布式軟總線+Ace Engine 也就是HarmonyOS的核心設(shè)計(jì)思想，這一點(diǎn)在王成錄的采訪中也有所提及。 那么這兩項(xiàng)技術(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與其他相比最大的特點(diǎn)就是功能封裝的更加友好，也更加統(tǒng)一，但最大的缺點(diǎn)也源于此：它需要的硬件資源太多了，對于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備來說，硬件成本是不可承受的。 而如果裁剪掉這部分，那么和其他的Iot系統(tǒng)并沒有太多區(qū)別。 再看看Ace Engine: 熟悉編程的朋友一定知道，Ace Engine與小程序以及Flutter的設(shè)計(jì)思想與架構(gòu)完全一樣，F(xiàn)lutter由于Dart虛擬機(jī)無法運(yùn)行中資源有限的嵌入式設(shè)備中，無法做到，那小程序?qū)Ρ热绾文兀?/span> 以目前擁有最大生態(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（分布式軟總線）呢？且不說開源方案本來就有很多，就是從零開始實(shí)現(xiàn)，目前國內(nèi)能做到的公司數(shù)量數(shù)起來，只怕兩只手兩只腳都不夠用。 那么依靠這些，華為能夠?yàn)镠armonyOS培育出自己的物聯(lián)網(wǎng)生態(tài)嗎？我個人的觀點(diǎn)是悲觀的。 鴻蒙主管在采訪中說： 個人認(rèn)為，物聯(lián)網(wǎng)作為提出了二十多年的概念，以及孵化了十幾年的產(chǎn)業(yè)，「分布式軟總線」相關(guān)技術(shù)和協(xié)議在不同產(chǎn)品中或多或少都才用過，而物聯(lián)網(wǎng)到現(xiàn)在這個時間點(diǎ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)理，在想法驗(yàn)證階段，面對這么多需要考慮的指標(biāo)，你會優(yōu)先選擇哪一個？到時候恐怕應(yīng)用響應(yīng)慢點(diǎn)、通訊速度慢點(diǎn)會成為最后考慮的東西。 而一旦想法驗(yàn)證通過，又有幾個服務(wù)不會全平臺支持，而主動與一個平臺綁定？ 這就是HarmonyOS想要成功所需要解決的第一個問題： 如果「分布式軟總線」這條路是無價(jià)值的，那么作為HarmonyOS最大的賣點(diǎn)，HarmonyOS所做的種種努力都是白費(fèi)的，HarmonyOS最終就會走向失敗； 而如果「分布式軟總線」這條路走得通，極其容易被別的廠商參考、借鑒，HarmonyOS卻并不能以此建立足夠?qū)拸V的「護(hù)城河」并以此培育出自己的生態(tài) 01 商業(yè)運(yùn)作
一款商業(yè)操作系統(tǒng)想要生存，最基本的條件有兩個： 死于沒有足夠多用戶的操作系統(tǒng)太多了，就不說了；死于第二個因素的操作系統(tǒng)最著名的就是Windows Phone，一意孤行、反復(fù)橫跳，導(dǎo)致微軟錯失了整個移動互聯(lián)網(wǎng)時代。 先說用戶問題，目前可以確定的是，在HarmonyOS沒有成功的趨勢之前，搭載HarmonyOS的手機(jī)以及使用HarmonyOS的用戶絕大多數(shù)華為以及榮耀用戶。 我們以兩年換機(jī)周期為例，目前華為手機(jī)存量大約為4億臺。 在目前這個時間點(diǎn)，HarmonyOS生態(tài)抗衡GMS生態(tài)的可能性微乎其微，所以第一批升級HarmonyOS的絕大多數(shù)應(yīng)該都是國內(nèi)用戶，那這部分手機(jī)存量在2.2億左右 由于GMS被禁用，華為的海外市場估計(jì)會繼續(xù)迅速萎縮。 而在2020年9月15日之后，被禁止生產(chǎn)5nm Kirin芯片之后，華為終端產(chǎn)品缺貨的狀態(tài)持續(xù)存在，華為國內(nèi)的市場份額估計(jì)也會快速萎縮。 再根據(jù)Android手機(jī)過去系統(tǒng)升級比例的經(jīng)驗(yàn)，目前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ì)是和華為是玩不到一起的。 那么華為手機(jī)產(chǎn)能受限的情況下，如何為那關(guān)鍵的「1」也就是手機(jī)終端獲取新的用戶也是一個需要解決的問題。 在第三方應(yīng)用方面，一方面表示每一位開發(fā)者都是華為要匯聚的星星之火。 另一方面執(zhí)行起來，卻是只和大廠合作。 在2021年這個時間點(diǎn)，作為還有不到一個月就要發(fā)布的且宣稱要開源的新系統(tǒng)，到現(xiàn)在為止還像寶貝一樣藏起來、對非核心開發(fā)者像防賊一樣，技術(shù)實(shí)現(xiàn)細(xì)節(jié)語焉不詳，虛擬機(jī)云端運(yùn)行，開發(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)為這種看法是不符合實(shí)際情況的。 實(shí)際上GMS這個框架在技術(shù)上確實(shí)沒有什么難度，但GMS不可取代的并非框架本身，而是GMS連接著的Youtube、Gmail、Gmap、Google Pay、Google Search以及海外Android應(yīng)用所依托的賬號系統(tǒng)。 HMS與GMS的競爭也并非這兩個框架本身的競爭，而是HMS與GMS所承載的獨(dú)占服務(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。因?yàn)閮蓚€生態(tài)都支持的話HMS對GMS依舊沒有話語權(quán)與競爭力 在國內(nèi)，由于Google服務(wù)在國內(nèi)被禁，又由于GMS這個框架確實(shí)沒有什么技術(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一個不落，全都提供類似的移動服務(wù)，如果你點(diǎn)開看一下，發(fā)現(xiàn)他們提供的服務(wù)內(nèi)容也相差不大。 所以在國內(nèi)，HMS、MMS、OMS、VMS的市場份額就約等于它們手機(jī)的市場份額，所以騰訊系、阿里系接入HMS并不會給HMS提供什么額外競爭力，因?yàn)樗鼈兘尤肴A為家的HMS，自然也會同時接入小米家的MMS、OPPO家的OMS、Vivo家的VMS。 而且它們接入的基本上只有推送服務(wù)，像比較重要的賬號體系、支付體系都會牢牢把握在自己手中，甚至即使是推送服務(wù)，它們?yōu)榱吮ＷC自己的業(yè)務(wù)以及消息送達(dá)率，它們在接入官方推送服務(wù)后依舊在后臺維護(hù)這自己獨(dú)有的推送服務(wù)，那些應(yīng)用互啟動、推送服務(wù)后臺耗電問題依舊沒有解決。 所以騰訊系、阿里系接入HMS是肯定的，在HarmonyOS出來之前，它們很多應(yīng)用就已經(jīng)接入了，但要是說騰訊系、阿里系接入HMS可以提高HMS的競爭力，恐怕是很多人的一廂情愿。 最后再說說HarmonyOS的物聯(lián)網(wǎng)生態(tài) 很多人認(rèn)為軟件沒有實(shí)物，沒有什么規(guī)則限制，只要想得到，就能做得到。 這也是很多人的一廂情愿，計(jì)算機(jī)科學(xué)是一門科學(xué)，是邏輯的產(chǎn)物，也受相應(yīng)規(guī)則的制約。 對HarmonyOS來說，它將物聯(lián)網(wǎng)通訊協(xié)議進(jìn)行封裝使通訊更加便捷，提供跨平臺JS runtime使得UI界面可以一次開發(fā)多端運(yùn)行，確實(shí)使得相關(guān)開發(fā)更加便利。 但有利必有弊，通常來說，軟件封裝的層次越高，其通用性就越差。 HarmonyOS在針對某些物聯(lián)網(wǎng)場景進(jìn)行了針對性的優(yōu)化，確實(shí)意味著在這些物聯(lián)網(wǎng)場景可以進(jìn)行更便捷的開發(fā)，但也意味如果你的物聯(lián)網(wǎng)設(shè)備不適用這些場景，那么在HarmonyOS上進(jìn)行開發(fā)，會產(chǎn)生比采用其他平臺更高的成本。 比如：
對于絕大多數(shù)物聯(lián)網(wǎng)設(shè)備，沒有這么奢侈的硬件去運(yùn)行HarmonyOS的物聯(lián)網(wǎng)系統(tǒng)，也并沒有這么多交互需要界面去實(shí)現(xiàn)，那么采用LiteOS，就意味著對其沒有什么幫助還徒增成本（其他物聯(lián)網(wǎng)系統(tǒng)有更通用的解決方案，成本也更低） HarmonyOS更加私有化的封裝也意味著與其他的物聯(lián)網(wǎng)系統(tǒng)打通更加的困難，華為估計(jì)沒有能力做的所有物聯(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或者語音，但這些并沒有多少方便我們的生活，有點(diǎn)食之無味、棄之可惜的味道 比如： 我的手機(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)布局，它確實(shí)將原來的物聯(lián)網(wǎng)設(shè)備開發(fā)成本降低了一個數(shù)量級，但是依舊沒有解決上面的這些問題，畢竟，就算所有物聯(lián)網(wǎng)設(shè)備都可以暢通無阻的通訊又有什么用呢？我買它們有不是讓它們來說悄悄話的！！！ ...... （這個問題太大了，需要考慮的問題太多，能力有限，既考慮不全，也表達(dá)不太清楚，不往下寫了）
來源：21ic電子網(wǎng)，頭條@我的小號等，本文作者觀點(diǎn)不代表本網(wǎng)觀點(diǎn)
看完這篇文章，你有什么收獲？歡迎在留言區(qū)與10w+Java開發(fā)者一起討論~
關(guān)注微信公眾號：互聯(lián)網(wǎng)架構(gòu)師，在后臺回復(fù)：2T，可以獲取我整理的教程，都是干貨。
1、GitHub 標(biāo)星 3.2w！史上最全技術(shù)人員面試手冊！FackBoo發(fā)起和總結(jié)
3、從零開始搭建創(chuàng)業(yè)公司后臺技術(shù)棧
5、37歲程序員被裁，120天沒找到工作，無奈去小公司，結(jié)果懵了...
6、滴滴業(yè)務(wù)中臺構(gòu)建實(shí)踐，首次曝光
評論
圖片
表情