鴻蒙之迷思

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

鴻蒙是個品牌，背后是n套核心的n套系統的組合。
鴻蒙中的關鍵曾經是方舟編譯器，鴻蒙的開發代號還叫過Ark(方舟)。由于方舟團隊的幾位離職負責人在網上寫過回憶錄，所以我們能拼湊出當初發生了什么。
華為2012實驗室有個了不起的組織架構，就是把研發實驗室設到全球各地，這樣那些不想到深圳工作的牛人可以安心在本地，不用拖家帶口。

當然獵頭也更方便，不少實驗室設在其它巨頭旁邊。
從****上的DSP到后來的麒麟和鯤鵬，華為自建編譯器團隊越來越必要，來實現性能的優化到自有指令集等等。

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

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

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

現代高級編譯器多是三層架構: 前中后端。前端是翻譯各種語言，中端優化，后端對應出不同類型CPU的機器碼。中間優化的過程，經常用IR來表示，比如MapleIR。

周老設計Maple的初衷據說是前端用Javascript，即MapleJS，這樣可以實現跨平臺和在輕量化的智能iot設備上運行和優化。
機緣巧合，華為消費者事業群(CBG)在努力實現對陣友商的安卓差異化時，想到靜態編譯Java來實現速度上超越競爭對手，立項聯合2012的幾個團隊一起攻堅MapleJava。

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

后來的事實證明，MapleJava這個思路有點天真了。
三、MapleJava的碰壁

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

此時剛好碰到美帝的無端制裁，所以余總裁高調宣布了鴻蒙和方舟編譯器。但這時，MapleJava只是實驗室產品。

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

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

這樣，因為無法完全擺脫了安卓，整個這件事的政治價值大幅度降低了。

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

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

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

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

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

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

五、Javascript的選擇

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

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

在上述JS生態建立前，鴻蒙手機的務實做法是同時支持安卓AOSP和原生JS應用。但是鴻蒙手機系統未完全開源，MapleJS應用開發框架仍不清晰，所以我們大多數人只看到了AOSP，外界出現了“套殼安卓”的聲音。

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

用于智能設備的開源鴻蒙(LiteOS)，在國內自有知識產權和開源iot生態已經百花齊放的情況下，價值在哪里，不在本文探討范圍內。

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

七、谷歌的Fuchsia

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

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

如果華為能充分發揮CT上的領先優勢，把核心CT做成組合專利和軟件IP組件的霸主，也許更符合任總今年“專注于軟件”的戰略。舉個也許不恰當的小例子，去年的”多屏協同”功能就很不錯。
參考微軟從痛罵開源到擁抱開源，本人認為華為應該重新考慮一下出山領導Open RAN。
在極端困難的情況下，華為已經做到了超乎想象的勇敢和堅韌，“軟件化和IP專利化”也許正是浴火重生前的“黃沙百戰穿金甲”。