鸿蒙之迷思：方舟应用开发框架仍不清晰，华为 HarmonyOS 尚未完全开源

本文通过追根溯源和道听途说，从“纯技术”层面探讨了鸿蒙演化到今天“不得已”的现状。就事论事，不讨论其他领域的争执。

一、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 专利化”也许正是浴火重生前的“黄沙百战穿金甲”。