鸿蒙之迷思
本文来自微信公众号：金捷幡（ID：jin-jiefan），作者：金捷幡
害怕被说蹭热点，所以等了小一个月发表这篇文章。期间无数媒体铺垫盖地，信息通货膨胀到爆，但有价值的内容却寥寥无几。
本文通过追根溯源和道听途说，从“纯技术”层面探讨了鸿蒙演化到今天“不得已”的现状。
一、2012实验室
鸿蒙是个品牌，背后是n套核心的n套系统的组合。
鸿蒙中的关键曾经是方舟编译器，鸿蒙的开发代号还叫过Ark（方舟）。由于方舟团队的几位离职负责人在网上写过回忆录，所以我们能拼凑出当初发生了什么。
华为2012实验室有个了不起的组织架构，就是把研发实验室设到全球各地，这样那些不想到深圳工作的牛人可以安心在本地，不用拖家带口。
当然猎头也更方便，不少实验室设在其它巨头旁边。
从基站上的DSP到后来的麒麟和鲲鹏，华为自建编译器团队越来越必要，来实现性能的优化到自有指令集等等。
世界软件的灯塔在硅谷，所以华为编译器团队就在美研所组建。中国软件的灯塔之一在杭州，国内编译器团队集中在杭研所。
美研所在2014年请到Open64编译器的总架构师周志德老爷子。也许由于Open64日暮西山，而苹果支持的LLVM如日中天，不服气的周老和小伙伴们做起Maple编译器，这就是方舟的前身。
Maple为什么改叫方舟，网上众说纷纭。一种说法是周老的英文名字Fred Chow谐音就是“方舟”；另一种说法是2012世界大难来了要方舟来救命，这和2012实验室的名字吻合。今天方舟大量文件名仍保留了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专利化”也许正是浴火重生前的“黄沙百战穿金甲”。