本文通過追根溯源和道聽途說，從“純技術”層面探討了鴻蒙演化到今天“不得已”的現狀。就事論事，不討論其他領域的爭執。

一、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 專利化”也許正是浴火重生前的“黃沙百戰穿金甲”。