鴻蒙之迷思

本文通過追根溯源和道聽途說，從“純技術(shù)”層面探討了鴻蒙演化到今天“不得已”的現(xiàn)狀。
一、2012實(shí)驗(yàn)室

鴻蒙是個(gè)品牌，背后是n套核心的n套系統(tǒng)的組合。
鴻蒙中的關(guān)鍵曾經(jīng)是方舟編譯器，鴻蒙的開發(fā)代號(hào)還叫過Ark(方舟)。由于方舟團(tuán)隊(duì)的幾位離職負(fù)責(zé)人在網(wǎng)上寫過回憶錄，所以我們能拼湊出當(dāng)初發(fā)生了什么。
華為2012實(shí)驗(yàn)室有個(gè)了不起的組織架構(gòu)，就是把研發(fā)實(shí)驗(yàn)室設(shè)到全球各地，這樣那些不想到深圳工作的牛人可以安心在本地，不用拖家?guī)Э凇?br />
當(dāng)然獵頭也更方便，不少實(shí)驗(yàn)室設(shè)在其它巨頭旁邊。
從****上的DSP到后來的麒麟和鯤鵬，華為自建編譯器團(tuán)隊(duì)越來越必要，來實(shí)現(xiàn)性能的優(yōu)化到自有指令集等等。

世界軟件的燈塔在硅谷，所以華為編譯器團(tuán)隊(duì)就在美研所組建。中國軟件的燈塔之一在杭州，國內(nèi)編譯器團(tuán)隊(duì)集中在杭研所。
美研所在2014年請(qǐng)到Open64編譯器的總架構(gòu)師周志德老爺子。也許由于Open64日暮西山，而蘋果支持的LLVM如日中天，不服氣的周老和小伙伴們做起Maple編譯器，這就是方舟的前身。
Maple為什么改叫方舟，網(wǎng)上眾說紛紜。一種說法是周老的英文名字Fred Chow諧音就是“方舟”；另一種說法是2012世界大難來了要方舟來救命，這和2012實(shí)驗(yàn)室的名字吻合。

在孟晚舟被Maple國扣留以后，改名字更是大勢(shì)所趨。不過到今天方舟大量文件名仍保留了Maple或Mpl等。

華為美研(Futurewei)在美帝制裁后，出現(xiàn)了個(gè)法律悖論。因?yàn)镕uturewei是美國公司，美帝沒法制裁，但它能限制Futurewei向母公司輸送技術(shù)，后來華為員工好像也不被允許進(jìn)入Futurewei。
大概因?yàn)槿绱?，華為對(duì)開源模塊的合規(guī)非常謹(jǐn)慎，畢竟來自美帝的即使是外部的貢獻(xiàn)都得考慮刪改。如果這是“按揭開源”的原因之一，我覺得特別能體諒。
二、編譯器的進(jìn)攻方向

現(xiàn)代高級(jí)編譯器多是三層架構(gòu): 前中后端。前端是翻譯各種語言，中端優(yōu)化，后端對(duì)應(yīng)出不同類型CPU的機(jī)器碼。中間優(yōu)化的過程，經(jīng)常用IR來表示，比如MapleIR。

周老設(shè)計(jì)Maple的初衷據(jù)說是前端用Javascript，即MapleJS，這樣可以實(shí)現(xiàn)跨平臺(tái)和在輕量化的智能iot設(shè)備上運(yùn)行和優(yōu)化。
機(jī)緣巧合，華為消費(fèi)者事業(yè)群(CBG)在努力實(shí)現(xiàn)對(duì)陣友商的安卓差異化時(shí)，想到靜態(tài)編譯Java來實(shí)現(xiàn)速度上超越競(jìng)爭對(duì)手，立項(xiàng)聯(lián)合2012的幾個(gè)團(tuán)隊(duì)一起攻堅(jiān)MapleJava。

雖然大家都知道Java虛擬機(jī)開銷很大，安卓代碼翔山也多，但挑戰(zhàn)Google里頂尖高手們連續(xù)優(yōu)化了10年的虛擬機(jī)(ART)，這個(gè)想法可以說無比大膽。

后來的事實(shí)證明，MapleJava這個(gè)思路有點(diǎn)天真了。
三、MapleJava的碰壁

MapleJava 1.0(即方舟1.0)可以說比較成功，它驗(yàn)證了部分靜態(tài)編譯的app可以比在谷歌虛擬機(jī)上跑得快。

此時(shí)剛好碰到美帝的無端制裁，所以余總裁高調(diào)宣布了鴻蒙和方舟編譯器。但這時(shí)，MapleJava只是實(shí)驗(yàn)室產(chǎn)品。

接下來，方舟2.0的任務(wù)就清晰了，編譯適配各種商用APP和優(yōu)化方舟runtime。

大量兼容性的困難隨之而來，安卓十年的生態(tài)顯然不是一個(gè)編譯器就可以隨便破掉的。大家發(fā)現(xiàn)方舟runtime即使替換掉ART，也無法完全繞開安卓核心服務(wù)。

這樣，因?yàn)闊o法完全擺脫了安卓，整個(gè)這件事的政治價(jià)值大幅度降低了。

更重要的是，拋開各種bug和兼容性等負(fù)面因素，方舟編譯過的App比標(biāo)準(zhǔn)安卓App在速度上的差異并沒有預(yù)期那么大，在兩者都足夠流暢的情況下，意義在哪里呢？

從今天看，MapleJava的方案被擱置。這也許是這百人團(tuán)隊(duì)中很多離職的原因。

客觀地說，MapleJava是一次很牛逼的嘗試，起碼繞開了谷歌虛擬機(jī)。遺憾的是，MapleJava的相應(yīng)runtime沒有完全開源，這使得開發(fā)者們沒法繼續(xù)發(fā)掘靜態(tài)編譯Java app的潛力。
就在前幾天，微軟最新的Windows 11宣布采用英特爾Bridge編譯器在x86上原生支持安卓App。
四、鴻蒙對(duì)標(biāo)誰？

MapleJava的不順利，導(dǎo)致了后來一系列宣傳上的困境，整個(gè)鴻蒙的戰(zhàn)略給社會(huì)帶來很多誤解。
華為堅(jiān)持說開源鴻蒙(LiteOS，后叫Open Harmony)和手機(jī)鴻蒙(HarmonyOS)之間是有關(guān)聯(lián)的，雖然兩者內(nèi)核都不一樣。我們探究這種關(guān)聯(lián)很可能指方舟和通訊協(xié)議。
早期方舟的開源也許更重要，這畢竟實(shí)際展示了挑戰(zhàn)巨人的勇氣。方舟開源包括了MapleC，這勉強(qiáng)可以看到對(duì)標(biāo)Clang-LLVM->蘋果Swift的一條路徑。如果手機(jī)鴻蒙選了這個(gè)路線，應(yīng)該是鴻蒙在性能上追趕蘋果iOS的唯一選擇。
蘋果是靜態(tài)編譯，加上自家編譯器對(duì)自研CPU/GPU/NPU的優(yōu)化，性能上是安卓沒法比的，而且硬件開銷也是最小的。

但是，MapleC這個(gè)路線還有n年的差距。說服開發(fā)者用開發(fā)效率低的C/C++語言來做原生鴻蒙程序，是個(gè)不可能的挑戰(zhàn)。
所以有傳言，華為會(huì)推出真正對(duì)標(biāo)蘋果Swift的自有語言：“Maple+倉頡”。不過新語言的學(xué)習(xí)周期和生態(tài)建立，都需要非常長的時(shí)間和投入。

與此相關(guān)的是，如果華為不能長期獲得ARMv9以后的授權(quán)，倉頡的優(yōu)化也許要從ARM轉(zhuǎn)到RISC-V。而RISC-V的生態(tài)差距仍舊過大，如何下手選擇兩難。
那么在MapleJava之后，華為的選擇是什么呢？
雖然最新的鴻蒙架構(gòu)圖里方舟runtime被稱為方舟“多語言”運(yùn)行時(shí)，但很多人覺得Javascript(MapleJS)是主打牌。

五、Javascript的選擇

Javascript是近年最紅的全棧語言，開發(fā)效率最高，可以跨平臺(tái)，甚至可以嵌入平臺(tái)內(nèi)作為子平臺(tái)跑，最典型的例子就是微信小程序。
手機(jī)用JS做App的先驅(qū)是Palm的WebOS。WebOS和Palm Pre手機(jī)設(shè)計(jì)理念非常超前：多任務(wù)卡片，全屏手勢(shì)，無線充電等都是多年后才被蘋果和安卓抄襲。
WebOS的標(biāo)準(zhǔn)Linux+JS作前端的架構(gòu)更是有前瞻性，但它超越了時(shí)代，那時(shí)硬件性能支持JS App還是比較吃力的，甚至當(dāng)時(shí)程序員們還不覺得JS是個(gè)語言。
WebOS失敗后，三星的Tizen/JS接棒再戰(zhàn)，仍以失敗告終。

多年以后，JS獲得了空前的發(fā)展。KaiOS, PWA等等JS生態(tài)野火重燃，加上硬件性能的冗余，鴻蒙原生JS應(yīng)用成功的概率提高了。網(wǎng)銀和電商App那種本來就是Webview不需要性能的更是沒有阻礙。
谷歌ChromeOS和強(qiáng)大的V8引擎也背書了鴻蒙用JS拓展到桌面領(lǐng)域是完全可行的。
當(dāng)然手機(jī)原生JS App的挑戰(zhàn)也很大，直接用現(xiàn)有框架(RN, Weex, Webview..)適配還是比較麻煩，而且很難調(diào)用底層和利用GPU等硬件特質(zhì)，游戲性能也受影響。關(guān)于這點(diǎn)，我還是很期待看到MapleJS的技術(shù)突破。
六、務(wù)實(shí)的做法

在上述JS生態(tài)建立前，鴻蒙手機(jī)的務(wù)實(shí)做法是同時(shí)支持安卓AOSP和原生JS應(yīng)用。但是鴻蒙手機(jī)系統(tǒng)未完全開源，MapleJS應(yīng)用開發(fā)框架仍不清晰，所以我們大多數(shù)人只看到了AOSP，外界出現(xiàn)了“套殼安卓”的聲音。

在AOSP開源的情況下，打造另一套未開源手機(jī)生態(tài)的價(jià)值在哪里，也確實(shí)讓人困惑。
如果芯片代工問題最終可以解決，各種去美化的IP核仍能買到，華為重新走鴻蒙+倉頡+麒麟的軟硬一體路線，那將是非常有勇氣和值得欽佩的。這里先為華為保留海思團(tuán)隊(duì)點(diǎn)個(gè)贊。

用于智能設(shè)備的開源鴻蒙(LiteOS)，在國內(nèi)自有知識(shí)產(chǎn)權(quán)和開源iot生態(tài)已經(jīng)百花齊放的情況下，價(jià)值在哪里，不在本文探討范圍內(nèi)。

我們目前看到的是，各種不同鴻蒙設(shè)備間的通訊機(jī)制(分布式軟總線，或叫“萬物互聯(lián)”)，成為鴻蒙的最大賣點(diǎn)。

七、谷歌的Fuchsia

正巧在鴻蒙2.0開源前，谷歌正式發(fā)布了Fuchsia。和沸騰黨說的相反，谷歌很低調(diào)，并沒有描繪Fuchsia的前景，只是說它是一個(gè)適合“connected devices”的全新的安全的操作系統(tǒng)。

從架構(gòu)看，F(xiàn)uchsia非常模塊化，適合拼裝快速開發(fā)。它似乎在耐心等待各種模塊(輪子)被造出來，而且鼓勵(lì)開發(fā)者嘗試新一些的技術(shù): Rust/Dart/Flutter…這說明谷歌這次并不著急。
Fuchsia和安卓的未來關(guān)系沒有人知道，包括谷歌自己。對(duì)谷歌來說，擺脫Linux GPL和陳舊的JDK也一直是夢(mèng)想，但它知道這需要漫長的時(shí)間和機(jī)緣，所以只能低調(diào)。
試圖對(duì)比開源鴻蒙2.0和Fuchsia我猜是徒勞的，兩者幾乎沒有共通點(diǎn)，除了都號(hào)稱微內(nèi)核。
八、愿景
值得八卦一下的是，LLVM和Swift之父Chris Lattner從蘋果跳槽到特斯拉主管Autopilot后，仍想把Swift引入特斯拉，結(jié)果他理念和馬斯克不合只半年就離職了。
這看來像是沒有完成從工具到應(yīng)用的思路轉(zhuǎn)換，迷戀打造鋒利的菜刀超過了做菜。
當(dāng)然這么草率評(píng)價(jià)大神，在一定程度上展示了我自己的愚蠢。這里只是想善意地祝福鴻蒙，不會(huì)因迷戀所謂工具而忘了初心。
從我個(gè)人的狹隘視角看，鴻蒙的愿景仍不夠清晰：就是她最終能給用戶和行業(yè)帶來什么；“萬物互聯(lián)”對(duì)用戶來說，和目前的工控、智能家居的區(qū)別有多大。
如果鴻蒙放棄最終和蘋果的性能對(duì)標(biāo)，退而和安卓比情懷和使用差異化，在芯片問題懸而未決的情況下是務(wù)實(shí)而且無奈的做法，即使會(huì)讓一些開發(fā)者失望。
九、未來的挑戰(zhàn)
華為雖然在產(chǎn)品線上完成了大量CT向IT的轉(zhuǎn)換，但坦率地說其在IT核心技術(shù)(CPU/GPU/OS/關(guān)鍵軟件等)上仍存在差距。加之華為還要分兵打造去美化的芯片生產(chǎn)體系，綜合挑戰(zhàn)是巨大的。
即使在跨平臺(tái)編譯這個(gè)小領(lǐng)域，我們也看到英特爾的Bridge和蘋果的Rosetta都展示了硬硬的肌肉。從情感上我們期望一家中國公司就能全方位席卷全球的各個(gè)科技巨頭，但冷靜和腳踏實(shí)地還是需要的。

如果華為能充分發(fā)揮CT上的領(lǐng)先優(yōu)勢(shì)，把核心CT做成組合專利和軟件IP組件的霸主，也許更符合任總今年“專注于軟件”的戰(zhàn)略。舉個(gè)也許不恰當(dāng)?shù)男±樱ツ甑摹倍嗥羺f(xié)同”功能就很不錯(cuò)。
參考微軟從痛罵開源到擁抱開源，本人認(rèn)為華為應(yīng)該重新考慮一下出山領(lǐng)導(dǎo)Open RAN。
在極端困難的情況下，華為已經(jīng)做到了超乎想象的勇敢和堅(jiān)韌，“軟件化和IP專利化”也許正是浴火重生前的“黃沙百戰(zhàn)穿金甲”。