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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、Javascript的選擇

Javascript是近年最紅的全棧語言，開發(fā)效率最高，可以跨平臺，甚至可以嵌入平臺內(nèi)作為子平臺跑，最典型的例子就是微信小程序。
手機(jī)用JS做App的先驅(qū)是Palm的WebOS。WebOS和Palm Pre手機(jī)設(shè)計理念非常超前：多任務(wù)卡片，全屏手勢，無線充電等都是多年后才被蘋果和安卓抄襲。
WebOS的標(biāo)準(zhǔn)Linux+JS作前端的架構(gòu)更是有前瞻性，但它超越了時代，那時硬件性能支持JS App還是比較吃力的，甚至當(dāng)時程序員們還不覺得JS是個語言。
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)于這點，我還是很期待看到MapleJS的技術(shù)突破。
六、務(wù)實的做法

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

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

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

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

七、谷歌的Fuchsia

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

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

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