OpenHarmony应用开发语言选择：JavaScript在嵌入式和单片机中的应用与优势

OpenHarmony目前主要推广的应用程序开发语言是js。当谈到javascript时，大多数人理所当然地认为它不适合在微控制器或嵌入式系统上使用。它是脚本语言，是解释执行的，所以效率肯定不会高。当然，这是传统意义上的。偏见。

早期js只用在网页浏览器上的时候确实是这样。

但自从V8和nodejs的出现后，js逐渐在MVVM前端、移动H5和后端获得了第二次生命。微软还发明了 TypeScript 来解决脚本语言的类型不安全问题。由此可见其非常重视。基于此，它还创建了非常流行的vscode编辑器。不过ts最终还是先编译成js，但是写法更加规范和安全。谷歌的V8引擎更加强大。 V8更直接地通过JIT技术将抽象语法树转换为本地代码，放弃了一些字节码阶段可以进行的性能优化，但保证了执行速度。源代码-→抽象语法树-→字节码-→JIT-→本机代码（V8引擎没有中间字节码）。

所以js创建不再是传统意义上的低性能。

方舟JS运行时组件

ARK JavaScript Runtime是OpenHarmony上JS应用程序使用的运行时。包含JS对象的分配器和垃圾收集器（GC），符合ECMAScript规范的标准库，用于运行ARK前端组件生成的ARK字节码（abc）的解释器，以及用于存储隐藏类的内部内容。联合缓存、方舟JS运行时外部函数接口（AFFI）等模块。

以下是方舟编译器的故事。

之前我只知道大名鼎鼎的GCC和Clang编译器，没想到我们也有这么强大的编译器。这是值得我们自豪的，更值得我们学习和推广使用。

Android系统采用Java作为编程语言，开发方便，但代码不直接编译成机器语言。程序运行时，相当一部分代码需要通过手机上的虚拟机临时同步编译，影响了程序执行的效率。华为方舟编译器采用静态编译方式，是第一个替代Android虚拟机模式的静态编译器。虽然Android 7.0之后各个系统版本仍然存在一些变化，但基本上都是AOT+JIT+解释和执行之间的动态调整，以寻找更好的平衡点。然而，谷歌一直无法解决虚拟机，这是制约Android运行效率的最关键问题。

方舟编译器直接杀掉虚拟机，改变系统和应用的编译运行机制，将高级语言直接编译成机器码，让手机直接理解“高级语言”，省去额外的麻烦虚拟机动态编译的开销。提高了手机操作效率。同时，方舟编译器还可以理解程序特性并使用适当的指令来执行程序，因此可以最大限度地发挥芯片的能力。

方舟编译器采用机器码全流程执行的方式高效运行程序，并且架构得到了进一步优化，可以让开发者在开发环境中将高级语言一次性编译成机器码。在手机上安装应用程序后，程序可以全速运行，带来效率的提升。很大的进步。根据华为实验室的测试数据，EMUI 9.1仅将华为方舟编译器应用到系统组件System Server后，系统操作流畅度就提升了24%，系统响应性能提升了44%。

目前，方舟编译器主要关注Java代码性能。未来，方舟编译器将覆盖多种编程语言（包括C/C++、JS等）和多种芯片架构（包括CPU、GPU、IPU等），覆盖范围更广。业务场景。

方舟编译器的诞生经历了一个漫长的过程。它是一群充满激情的工程师在华为大平台工作多年，一步步发展到今天的必然产物。

2009年下半年开始，第一批编译器工程师加入华为硅谷研究院，开启了华为自研编译器和工具链的历史。初期，队伍人数不多，一只手就可以数过来。但幸运的是，经过十多年的积累，这个团队留下了一批中国最优秀的编译器专家。他们平均从事编译器相关行业20多年。对应的平均年龄为40+。作为一名IT行业的研究者，我相信这个时代才是生命的本质，对技术有着最透彻、最纯粹的理解。值得庆幸的是，华为对基础技术的持续投入，也催生了国内一批数百人的编译器和虚拟机相关团队。这里汇聚了国内顶尖的人才。可以说，中国四分之一的编译器和虚拟机都在华为。

编译器团队从零开始创业。其经历的产品包括多核芯片仿真、基于GDB的调试器、基于GCC和LLVM的编译器设计。为公司主渠道提供了大量的工具链，也创造了很多性能优化。的奇迹。但我始终相信，最大的收获在于培养了一大批人才。

在体验了这些产品后，我们感觉华为内部的产品需求比较复杂，需要独立的软件编程系统来支撑。单纯依靠开源分散的软件来定制不同的业务需求，效率低下，而且无论是编译/虚拟机等系统软件还是应用软件团队都没有积累，是一种巨大的浪费。还有一个重要因素。我们聚集了来自不同的国际大公司，对这个行业有非常深入的了解。我们知道对于华为这样的大公司来说，拥有自己的编程系统是多么重要。我们都非常渴望这样做。

最终推动我们做出决定的是一个设计编程语言的项目。其要求是能否开发出一种新的高级语言，类似于matlab，同时能够利用DSP的硬件能力。传统 DSP 软件的开发严重依赖于类似汇编的内在函数。当更换芯片时，此类软件必须重新设计和实现。因此，提出新语言的要求是非常直观的，兼顾生产力和性能。这就是我们的高级语言Cm的诞生。这是一种基于 C 的语言，结合了类似 matlab 的数据类型和操作。为了追求性能，大量的优化需要从高层IR开始，即对语法树进行彻底的优化。工作重点在前端，语法树必须深度改造。

GCC没有被我们选中，因为它的前端太过晦涩，需要lex/yacc等工具来自动生成一些代码。这些代码人工理解起来比较困难，而且开发新语言需要频繁改动前端。 Clang的前端是手写的，非常容易阅读，因此我们以此作为Cm的设计和实现的基础。 Cm 取得了巨大的成功。但暴露出的问题是，在别人的开源编译器上进行深度改造效率太低。具体问题还有很多，这里不再讨论。

至此，自主编程系统的问题又再次进入我们的脑海，无法摆脱。首先，从纯粹的技术角度来看，华为的业务从最初的CT发展到了今天的ICT。编译工程师面对的芯片范围从DSP、CPU、GPU到NPU，面临着各种各样的计算类型和数据访问类型。编译器还需要适应多种类型的优化和实现。虽然存在各种差异，但也存在共同点。依靠开源项目来实现上述目标几乎是不可能的，或者说效率很低。最大的原因是每一个改变，特别是IR和基础优化的改变，很难基于别人的项目成功完成。其次，从公司业务的角度来看，华为内部庞大的软件开发团队和无数的软件项目其实有很多共同点。一个稍微通用的软件开发全栈，从编程语言开始一直到内核，适合大多数项目。有很大的好处，特别是在版本维护、演进和优化方面。

基于以上现实，我们一直在思考的是，应该有一种自行设计的中间语言，即编译器的IR，作为编译和运行所有软件的基础。这样就避免了对进口产品进行基本改变的痛苦，也无需考虑是否跟随进口产品的演进，制定自己的技术路线。我个人坚信，华为庞大的软件开发体量迫使我们必须有一个独立控制、独立进化的软件编译和分析框架。在这里，我们要求这个IR具有高度的可扩展性，并且能够消化最常见的语言特征，无论是动态的还是静态的（当然，这个要求很可能不会立即满足，但我愿意并且能够对其进行大幅修改）。在此基础上，编译器的输出应该是多样化的。可以直接编译成二进制，也可以不同级别输出为IR，即以中间代码的形式打包，类似于Java字节码。它可以直接发送到硬件，也可以以多种格式分发中间代码。下图显示了我们的意思。

基于此，走自主研发之路是不可避免的，尤其是目前GCC、LLVM、Open64等IR的设计没有考虑到Java等语言的特性，包括对象模型和各种动态特性的描述。与其不断地修补基础知识，不如从头开始设计一个具有全新概念的 IR。这是上图中的红枫木 IR。对于技术人员来说，如果有一个编译器，其中每个单元都有自己的基因，那就太好了。这对大家来说也是有点技术含量的。

方舟编译器原来的名字是MAPLE（Multiple ArchitectureProgramming Language&Environment），和我们上图的意思是一致的。在开源代码中可以看到很多maple字样，文件后缀有.mpl和.mplt等。MapleIR是重新设计的。与传统编译器最大的区别在于，我们在IR中引入了对象的概念，以及异常处理、同步操作等。因此，它能够表达的语义比LLVM和GCC更接近高级语言，包括语言的动态本质。

从上图中的描述可以看出，方舟编译器会输出中间代码格式的软件包，并且中间代码是平台无关的。这意味着在未来的规划中，我们可以服务于分布式、多设备的系统，每个设备接收到的软件包可以是二进制或中间代码格式。根据设备的功能，中间代码中包含的信息可能会有所不同。为了实现这一能力，方舟引擎应运而生。这是一个中间代码的执行引擎，类似于Java虚拟机。因此，设备既可以直接运行机器代码，也可以使用方舟引擎运行中间代码。它与Java虚拟机有两个不同之处。首先，方舟引擎输入的Maple IR是针对多语言的。因此，它的表达范围比Java字节码要大得多。只要它可以编译成Maple IR，引擎就可以执行它。第二个是方舟引擎未来将包含模拟功能，这意味着开发者可以模拟一些设备并在没有实际硬件的情况下运行方舟软件。

Ark最早的产品可以追溯到2016年，它是一个JavaScript程序的编译器和虚拟机，代号MapleJS。其目标设备是物联网。借助华为的LiteOS，可以支持大多数IoT小型设备。 MapleJS的整体内存消耗在十几KB的水平，比三星的JerryScript要好。

最近流行的方舟编译器产品是针对Android系统下Java程序的静态编译（最初代号为MapleJava）。将Java代码直接编译为机器代码，所有动态语义都通过静态方法解决。在这种情况下，Java虚拟机不需要存在。在Android系统中，不再需要ART（Android Runtime）。最常见的滞后原因，即GC，可以通过引用计数来解决（环引用是通过按需触发的备份GC来处理的，触发频率很低，可以忽略不计）。这也是方舟取得流畅度提升的主要原因之一。一般来说，静态编译最强大的就是可以看到更多的程序信息，这其实也是为我们以后更宏伟的计划做准备。常见的虚拟机JIT编译可以获得profiling信息的优点，也可以通过静态编译的方式训练来获得。但两者在信息类型和数据量上有各自的差异。

上图描述的MapleIR的核心设计思想是兼容几种常见语言。这一要求背后的长期愿景是消除跨语言障碍。例如，如果要在Java编程中调用C库，则必须通过JNI机制来完成。这种实现的成本非常高，因为两种不同语言的数据类型和调用约定完全不同，而且涉及到跨语言的异常传播和内存管理，必须通过虚拟机进行昂贵的处理，这是非常低效的。如果两种语言都可以翻译成MapleIR，IR上的数据类型可以集成，调用约定可以在相当程度上统一，那么效率可以大大提高。我们称这个计划为“拆墙行动”。在拆墙这个动作的基础上，在我们长远的理念中，我们需要优化整个方案。这是一个跨语言的全程序优化，对我们自己来说是一个巨大的挑战。

显然，我们的理想不是做一个编译器，而是做一个软件开发系统。这是一个相当大的范围，可以理解为软件开发的生态系统。我们今天所做的一切，包括Java静态编译，都是为了这个目标做准备。其未来已着眼于建立完整的软件开发体系。这整个生态系统中必须提到的就是编程语言和编程框架。软件开发人员看到的是编程语言和相关框架。因此，这是生态系统的入口。未来，方舟必须尝试使用语言，即使失败。基于此，需要一个强大的、具有相对自动适配能力的编译器前端。这个前端最大的特点一定是可以最大程度的自动化，减少语言设计过程中各种迭代带来的开发成本。

另外，大量基于一致IR的开发工具，包括调试、调优等，也一定会出现。为此，我们愿意与业界的共同爱好者共同构建完整的方舟系统。为编程语言、编译、分布式异构编程框架、分布式操作系统等领域奠定了基础。

OpenHarmony 上的 Node.js，得益于方舟编译器的强大帮助，性能也得到了很大的提升。它可以直接编译成机器指令执行，无需经过解释器或虚拟机。而它的JS UI框架是基于ACE架构模型的。系统UI和各种API调用直接调用底层C++接口，所以效率肯定没有问题。

了解 ACE 框架：

自适应通信环境（Adaptive Communication Environment），简称ACE。它是一个采用C++ Template技术制作的开源跨平台网络应用库套件。

ACE 自适应通信环境（ADAPTIVE Communication Environment）是一个免费提供的开源面向对象 (OO) 框架，它实现了并发通信软件的许多核心模式。 ACE 提供了一组丰富的可重用 C++ 包装器外观和框架组件，可以跨多个平台完成常见的通信软件任务，包括：事件多路分解和事件处理程序分派、信号处理和服务初始化。、进程间通信、共享内存管理、消息路由、分布式服务的动态（重新）配置、并发执行和同步等。

ACE的目标用户是高性能、实时通信服务和应用程序的开发人员。它使用进程间通信、事件多路分解、显式动态链接和并发性简化了 OO 网络应用程序和服务的开发。此外，ACE 通过在运行时将服务动态链接到应用程序来自动执行系统配置和重新配置。

以下是ACE的架构图：

从这张图中，我们可以清楚地看到ACE框架的大概轮廓。

从下往上，有C风格的OS适配层，它是对不同操作系统底层调用的封装；

上层是C++封装类，将各种系统调用和系统对象封装成C++类对象；

再往上就是框架层，主要是Reactor、Acceptor、Connector和Proactor。

以上是ACE提供的一些服务组件。

有人会说js没有duck模型用法。编译时如何知道类型？它只能被解释和执行。这里有一个限制，OpenHarmony上的js只支持ES2015标准和严格模式（use strict），这意味着以前广泛使用的js被拒绝了。事实上，这是一件好事。 JS语法不断发展，越来越标准化，已经不再是传统脚本语言的范围。

OpenHarmony是真正面向未来、万物互联的全场景操作系统。

想象一下，未来任何设备都可以发挥自己独特的能力，并且每个设备只需要发挥自己的能力即可。他们可以快速相互连接、能力互助、资源共享。无需安装应用程序或繁琐的操作。即使个别硬件性能不好，只要搭载鸿蒙，也能轻松连接使用，不会占用太多性能。这次经历非常令人兴奋。音效不错，但是里面没有歌曲的话控制起来不太方便。只需滑动手机即可通过扬声器播放歌曲。在手机上编辑不方便。只需滑动手指，即可切换到计算机上工作。电影在手机上观看，直接传输到电视上供全家人观看。这些在华为产品上已经成为现实。华为的创新确实是国内第一。仅凭OpenHarmony软总线技术的创新，相信路上还会有更多精彩的场景体验。

最后推荐一下这个优秀的系统。希望更多的人加入openharmony团队，共同丰富生态系统。目前还不够完善，比如开发板太少，甚至没有一个能够运行openharmony3.0所有功能的旗舰版。我认为这是openharmony目前最大的痛点，但未来是有希望的。

Openharmony 的一些亮点：

分布式：基于软总线的跨终端无缝体验

鸿蒙OS的“分布式OS架构”和“分布式软总线技术”，通过公共通信平台、分布式数据管理、分布式能力调度和虚拟外设四大能力，让开发者可以专注于自己的业务逻辑，例如开发跨平台开发等。同一终端上的终端分布式应用也让终端消费者享受到强大的跨终端业务协作能力带来的针对各种使用场景的无缝体验。

分布式软总线：

它是多种终端设备的统一基础，为设备之间的互联提供统一的分布式通信能力。能够快速发现和连接设备，高效分发任务和传输数据。

分布式数据管理：

分布式数据管理是基于分布式软总线的能力，实现应用数据和用户数据的分布式管理。用户数据不再绑定于单一物理设备，业务逻辑与数据存储分离，应用跨设备运行时数据无缝连接，为打造一致、流畅的用户体验创造了基础条件。

分布式任务调度：

分布式任务调度基于分布式软总线、分布式数据管理、分布式Profile等技术特性，构建统一的分布式服务管理（发现、同步、注册、调用）机制，支持跨设备应用的远程启动。远程调用、远程连接、迁移等操作可以根据不同设备的能力、位置、业务运行状况、资源使用情况以及用户习惯和意图，选择合适的设备来运行分布式任务。

鸿蒙OS将N个设备组合成一个“超级终端”，硬件互助、资源共享，可以根据个人需求自由调用。华为消费者业务软件部总裁王成录在鸿蒙OS 2暨华为全场景新品发布会上表示，“超级终端”提供手机与PC、平板、音箱等设备无线连接的组合在控制中心，只需手指简单地将不同设备的图标滑动在一起即可实现深度连接，提供了万物互联时代的全新连接和操作方式。

Android和iOS受限于系统体积较大，难以在小内存终端上广泛部署。

鸿蒙OS定位为面向未来的物联网操作系统。为了满足万物互联全场景智能时代对OS的新要求，实现模块化解耦，根据不同设备的硬件能力和需求进行组装。它可以在不同的设备上使用。可灵活部署。同时，鸿蒙OS通过分布式软总线连接不同终端，让应用程序可以轻松调用其他终端的硬件外设能力，为消费者带来无缝的跨终端协作体验。

生态共享：让开发者“同文同写”，让终端“同轨同车”

鸿蒙OS配备了多终端开发的统一IDE（集成开发工具），可以支持开发者实现一次性开发、多终端部署，最终实现跨终端生态共享。跨终端生态系统将打破终端被不同系统隔离的“孤岛效应”，大大降低用户在不同终端之间传输数据的门槛，提高使用效率和便利性。

鸿蒙2.0全面开源，助力硬件厂商和开发者

2020年，华为面向开发者发布了鸿蒙2.0 Beta版本，并宣布将鸿蒙操作系统源代码捐赠给Open Atom开源基金会进行开源孵化。根据华为公布的开源路线图，2021年10月后，鸿蒙将面向所有4GB以上设备开源。

对于硬件厂商：华为开源代码、SDK、开发板/模组、HUAWEI DevEco等平台和工具链，为鸿蒙OS设备提供一站式开发环境。

对于应用开发者：鸿蒙采用分布式软总线技术，为开发者提供包括编程框架、API、DevEco、方舟编译器等一系列平台和工具链，帮助开发者快速开发基于鸿蒙系统。应用软件。

使合作伙伴能够快速、低成本地连接用户：

合作伙伴的智能硬件产品可以基于鸿蒙操作系统，实现极简网络配置、通用卡、极简交互、硬件互助等能力。用户只需手机轻触即可将智能设备接入互联网，无需安装APP即可随时控制，有效解决设备智能功能使用率低的问题。

各个合作厂商的产品可以集成为一个“超级终端”：

基于鸿蒙OS，合作品牌厂商的单独设备可以根据消费者的不同需求、不同场景，将不同设备的软硬件能力结合起来，融合成一个“超级终端”。

引用：

方舟编程系统 - 知乎