来源:金融自媒体
来源:金杰体
怕被人说蹭热点，等了一个月才发表这篇文章。这期间无数媒体铺垫，信息膨胀爆炸，但有价值的内容少之又少。
通过追根溯源和道听途说，从“纯技术”的层面探讨鸿蒙系统“最后手段”的现状。
一、2012年实验室
鸿蒙系统是一个品牌，背后是N套核心系统的组合。
鸿蒙系统的钥匙曾经是方舟编译器，鸿蒙系统的开发代码也叫方舟。由于方舟团队几位即将离任的领导人都在网上写过回忆录，我们可以拼凑一下当初发生的事情。
华为2012实验室有一个显著的组织架构，就是在世界各地设立RD实验室，让那些不想在深圳工作的同事可以安心在当地工作，不需要用已婚有子女。
当然，猎头也更方便。很多实验室都位于其他巨头旁边。
从基站上的DSP，到后来的麒麟、鲲鹏，华为越来越需要建立自己的编译器团队，把性能优化到自己的指令集等等。
世界软件的灯塔在硅谷，所以在美院成立了华为编译器团队。中国软件的灯塔之一在杭州，国内编译器团队集中在杭州研究院。
2014年，美院邀请了Open64编译器总架构师周志德。或许是因为Open64第64届正值黄昏，而苹果支持的LLVM正如火如荼，周老和他不服气的朋友们启动了Maple compiler，也就是Ark的前身。
枫叶为什么要改名为方舟？网上众说纷纭。一种说法是，周老的英文名Fred Chow谐音为“方舟”；另一种说法是，2012年，世界陷入大麻烦，方舟被请求帮助，这与2012年实验室的名称一致。
孟晚舟被枫叶扣押后，改名是大势所趋。然而时至今日，方舟的大量文件名仍然保留着Maple或Mpl等。
美帝制裁后，华为美院出现了法律悖论。因为Futurewei是美国公司，美帝不能制裁，但可以限制Futurewei向母公司转让技术。后来，华为员工似乎不被允许进入Futurewei。
正因为如此，华为对开源模块的合规性非常谨慎。毕竟连美帝的外来贡献都要删。如果这是“增加房贷来源”的原因之一，我觉得特别体贴。
二、编译器的攻击方向
大多数现代编译器都有三层架构:前端、中间和后端。前端翻译各种语言，中端优化，后端对应不同类型CPU的机器码。优化的中间过程往往用IR表示，比如MapleIR。
周老设计Maple的初衷据说是在前端使用Javascript，即MapleJS，这样就可以跨平台、在轻量级智能物联网设备上运行和优化。
无独有偶，华为消费者业务组在努力实现安卓对友商差异化的同时，想到了静态编译Java以在速度上超越竞争对手，并在2012年成立了一个项目，与几个团队共同进攻MapleJava。
虽然我们都知道Java虚拟机价格昂贵，Android代码众多，但挑战谷歌顶级专家连续10年优化虚拟机，是一个大胆的想法。
后来事实证明MapleJava有点幼稚。
第三，MapleJava碰壁了
MapleJava 1.0可以说是相当成功的，它验证了一些静态编译的app可以比Google虚拟机运行得更快。
在这个时候，我正好遇到了美帝的无端制裁，于是俞校长高调宣布了关于和方舟编译器的事情。但此时，MapleJava还只是一个实验室产品。
接下来，方舟2.0的任务很明确，编译适配各种商业app，优化方舟运行时。
一大堆兼容性难题随之而来，Android的十年生态显然不是一个编译器就能随便打破的。发现即使方舟运行时取代了ART，也无法完全绕过Android核心服务。
这样一来，由于我们无法彻底摆脱Android，整个事情的政治价值就大打折扣了。
更重要的是，尽管存在bug、兼容性等各种负面因素，但Ark编译的App与标准的Android App在速度上的差异并没有想象中的那么大。当两者都足够流畅的时候又有什么意义呢？
从今天来看，MapleJava的方案已经被搁置。也许这就是这些100人团队中很多人离开的原因。
客观来说，MapleJava是一个很牛逼的尝试，至少绕过了Google虚拟机。遗憾的是，MapleJava对应的运行时并没有完全开源，这使得开发者无法继续挖掘Java app静态编译的潜力。
就在几天前，微软最新的Windows 11宣布在搭载英特尔Bridge编译器的x86上原生支持Android应用。
4.鸿蒙系统反对谁？
MapleJava的失败导致了一系列的宣传困难，鸿蒙系统的整个战略给社会带来了许多误解。
华为坚持认为，开源鸿蒙系统和手机鸿蒙系统之间存在联系，尽管两者的核心不同。当我们探索这种联系时，我们可能会提到方舟和通信协议。
Ark的早期开源可能更重要。毕竟它其实表现出了挑战巨头的勇气。Ark开源包括MapleC，勉强能看到一条对标Clang的路径——LLVM->苹果Swift。如果手机鸿蒙系统选择这条路线，应该是鸿蒙系统在性能上赶超苹果iOS的唯一选择。
苹果的静态编译，加上自家编译器对自研CPU/GPU/NPU的优化，性能上是安卓无法比拟的，硬件开销微乎其微。
但是在MapleC还是有n年的差距。说服开发人员使用低效的C/C++语言来制作原生鸿蒙系统程序是一个不可能的挑战。
所以传言华为会推出自己的语言:“Maple+仓颉”，这是苹果Swift真正的标杆。但是，学习一门新的语言，建立一个生态环境，需要很长的时间和投入。
与此相关的是，如果华为在ARMv9之后长期得不到授权，仓颉的优化可能要从ARM转移到RISC-V，但是RISC-V的生态差距还是太大，选择如何入手是一个两难的选择。
那么华为在MapleJava之后的选择是什么？
虽然在最新的鸿蒙系统架构图中，Ark运行时被称为Ark的“多语言”运行时，但很多人认为Javascript是主要的玩牌者。
第五，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的挑战也很大。直接用现有框架适配还是比较麻烦，底层调用和利用GPU等硬件特性也比较困难，游戏性能也受到影响。在这方面，我还是很期待看到MapleJS的技术突破。
六。实际的方法
在JS生态建立之前，鸿蒙系统手机的务实做法是同时支持安卓AOSP和原生JS应用。但是鸿蒙系统的手机系统还没有完全开源，MapleJS的应用开发框架还不清晰，所以我们大多数人只看到AOSP，外面出现了“嵌套Android”的声音。
有了AOSP开源，再创造一套未开放的手机生态系统有什么价值，真的很困惑。
如果最终能解决芯片代工的问题，还能买到各种美化的ip核，华为再次走鸿蒙系统+仓颉+麒麟的软硬一体化路线，将是非常勇敢和令人敬佩的。这里为华为留住海思团队点个赞。
鉴于国内知识产权和开源物联网生态已经开花结果，开源鸿蒙系统对于智能设备的价值超出了本文的范围。
目前，我们看到的是，不同鸿蒙系统设备之间的通信机制已经成为鸿蒙系统的最大卖点。
七、谷歌的紫红色
就在鸿蒙系统2.0开源之前，谷歌正式发布了Fuchsia。与沸腾党所说的相反，谷歌保持低调，没有描述Fuchsia的未来，只是说这是一个全新的、安全的、适合“连接设备”的操作系统。
从架构的角度来看，Fuchsia非常模块化，适合快速组装和开发。它似乎在耐心等待各种模块的搭建，并鼓励开发者尝试一些新技术:Rust/Dart/Flutter……可见谷歌这次并不着急。
Fuchsia和Android的未来关系是未知的，包括谷歌自己。对于谷歌来说，摆脱Linux GPL和老JDK一直是个梦想，但它知道这需要很长的时间和机会，所以只能保持低调。
我猜，试图比较开源的鸿蒙系统2.0和Fuchsia是徒劳的。除了都被称为微内核之外，它们几乎没有什么共同之处。
八。视力
值得八卦的是，LLVM和Swift之父克里斯·拉特纳在从苹果跳槽到特斯拉的自动驾驶负责人之后，仍然想把Swift引入特斯拉。结果他和马斯克的理念不一样才半年就走了。
看来我们还没有完成从工具到应用的转变，执着于制作锋利的菜刀多于烹饪。
当然，如此草率的评价大神，一定程度上说明了我自己的愚蠢。在这里，我只想祝福鸿蒙系统，我不会因为迷恋所谓的工具而忘记自己的初心。
从我个人狭隘的角度来看，鸿蒙系统的视野还是不够清晰:她最终能给用户和行业带来什么；“万物互联”对于用户来说，和现在的工业控制、智能家居有什么区别？
如果鸿蒙系统放弃与苹果的最终性能对标，而与安卓在感受和使用上有所作为，在芯片问题仍未解决的情况下，这将是务实和无奈的，即使会让部分开发者失望。
九。未来的挑战
虽然华为在产品线上完成了大量的CT到IT的转换，但坦白说，其IT核心技术还是有差距的。此外，华为还要分兵建立美化的芯片生产体系，综合挑战巨大。
即使在跨平台编译这个小领域，我们也能看到，无论是英特尔的Bridge，还是苹果的Rosetta，都显示出了硬肌肉。感情上，我们期待一家中国公司能横扫全球科技巨头，但还是要冷静，脚踏实地。
如果华为能充分发挥在CT领域的领先优势，将核心CT打造成组合专利和软件IP组件的霸主，或许更符合今年任总“专注软件”的战略。举个可能不太恰当的小例子，去年的“多屏协同”功能就很不错了。
提到微软从痛骂开源到拥抱开源，我觉得华为应该重新考虑领导Open RAN。
在极其困难的情况下，华为表现出了超乎想象的勇敢和坚韧。“软件化、IP专利化”可能是重生前的“黄沙穿金甲”。
