华为鸿蒙系统HarmonyOS学习之十四：方舟编译器

    方舟编译器是华为自研的一个支持多种编程语言，多种芯片平台的联合编译编程平台，而经过方舟编译器编译适配后的APP，运行效率会大大提高，拥有更为流畅的体验，足以匹配IOS应用程序APP，华为方舟编译器所拥有的全新的应用编译和运行机制，能够从动态编译变为静态编译，直接将高级语言直接编译成机器码，彻底消除了虚拟机动态编译的额外开销，实现了开发和运行效率的兼容并举，所以方舟编译器也成为了华为鸿蒙OS系统发展中非常重要的一环。

**    方舟编译器**是基于GCC开发的交叉编译器套件，它包括了C、C++、Fortran的前端，也包括了这些语言的库(如libstdc++、libgcc等)。HCC运行在X86 linux架构服务器上，生成的二进制运行在Aarch64架构服务器上。

要想说明方舟编译器的原理，必须首先明确机器码、汇编器、编译器、解释器等基本概念，以及常用的程序的运行模式，才能很好的理解编译器的运行原理。

（一）机器码、汇编器、编译器、解释器的概念

• 机器码

 不论是低级语言，如汇编，还是如今广泛使用的各种高级语言，Java，C++ 等，对于 CPU 来说，它能认识的只有二进制的机器码。当然，机器码对开发人员来说，是天书。那么编写的代码来说，应该如何驱动 CPU 运行编写的程序呢？这个时候，在代码和CPU之间就需要一个翻译，将代码翻译成机器码给 CPU，它就知道该如何执行了。面对不同的终端，翻译内容也不一样，一个只知道 x86 指令集的去翻译 arm 的，肯定翻译不出来。肯定需要通过汇编器、编译器或者解释器等翻译工具，实现这种翻译。

• 汇编器

  将汇编代码直接翻译成机器码。由于汇编代码一般和机器码都是一一对应的，所以它的速度非常快。但是汇编语言，可读性很差， 用来开发和编写大型程序对于普通开发者基本是不现实的。

• 编译器

   编译器将我们平常开发用的高级语言，例如 Java/C++ 等，翻译成机器码供 CPU 使用。这种编译很慢，但是执行起来会很快。

• 解释器

   程序不需要编译，程序在运行时才翻译成机器语言，每执行一次都要翻译一次。因此效率比较低。这种运行方式就慢了很多。 典型的解释型语言，php/js/python 等。

（二）java虚拟机的代码执行方式

       Java 程序的执行依赖于 Java 虚拟机（JVM），JVM 能直接识别的叫做字节码。Java 代码经过编译会生成 Class 文件，即字节码文件，再交由 JVM 处理。而 JVM 又是怎么执行 Class 文件的呢？这里以 HotSpot 为例，Class 文件被虚拟机加载后会存放在方法区，实际运行时，虚拟机会执行方法区中的代码。

    将字节码翻译成机器码的工作自然就由 JVM 来承担了。在 HotSpot 中，有几种翻译形式。

• 解释执行

    逐条将字节码翻译成机器码并执行

• 即时编译（Just-in-time ，JIT）

  将一个方法中包含的所有字节码编译成机器码后再执行。

     前者的优势在于无需等待编译，而后者的优势在于实际运行速度更快。HotSpot 默认采用混合模式，综合了解释执行和即时编译两 者的优点。它会先解释执行字节码，而后将其中反复执行的热点代码，以方法为单位进行即时编译。

（三）andriod的执行方式的变革历程

   开发 Android 目前用的最多的还是 Java，即使不是 Java，也是 JVM 语言。Android 工程中的 java 源文件经过编译也是生成 Class 文件，最后被打包成 DEX 字节码文件，负责将 DEX 字节码翻译成机器码的是 Dalvik 或者 Art。

   在 Android 5.0 之前，还是 Dalvik 的天下。Dalvik 是解释执行加上 JIT，每次app运行的时候，它动态的将一部分 Dalvik 字节码 解释为机器码。随着 App 的运行，更多的字节码被编译和缓存。因为 JIT 只编译了一部分代码，它具有更小的内存占用和更少的设备物理空间占用。但是，边解释边执行，效率低下，这也是后来 Dalvik 遭到抛弃的原因。

   从 Android 4.4 开始，Android 引入了 Art，到 Android 5.0，Art 正式代替了 Dalvik。Art 使用的是 AOT（Ahead of Time）的编译方式，即在应用的安装过程中，就将所有的 Dex 字节码翻译成机器码存储在设备空间中，完全抛弃了 JIT，带来的好处是显而易见的。

• Apps 运行的更快，因为 DEX 字节码的解释在安装过程中已经完成，直接运行机器码
• 减少了应用的启动时间，因为本地代码可以直接执行。
• 节省电量消耗，不需要再去一行一行的解释字节码。
• 增强了垃圾回收。
• 增强了开发者工具。

   事实上，这种完全基于 AOT 的模式也已经被 Android 抛弃了。如果你用过 5.0 或者 6.0 的安卓机，你一定不会忘记安装应用带来的漫长等待。由于需要在安装期间翻译字节码，所以安装过程会很长，尤其对 一些大型应用来说。另外，安装过程中翻译出来的机器码也占用了更大的机身存储空间。

     Android 7.0，Android 又加入了 JIT，一个具备代码分析功能的即时 (JIT) 编译器。事实上，根据二八定律，经常运行的热点代码可能只占 20%，甚至更少，我们没有必要通过 AOT 提前将所有字节码都翻译成机器码。安装过程中放弃 AOT，加快安装速度，所以初次使用时得解释执行。当你在使用应用时，JIT 就开始分析代码了，在合适的时候将字节码翻译成机器码，在 Android 应用运行时持续提高其性能。另外，设备空闲的时候，AOT 就发挥作用了，它会将热点代码翻译成机器码并保存下来，进一步提高运行效率。这么看下来，现在的 Android 是 解释执行 、JIT、AOT 同时存在的。下面这张官网的图片很好的说明了Art 下的 JIT 架构.

关于解释器，高版本中的 Android 实现也不再那么孱弱了，根据官网相关介绍：

通过引入 Mterp（一种解释器，具有以汇编语言编写的核心提取/解码/解释机制），Android 7.0 版本中的解释器性能得以显著提升。Mterp 模仿了快速 Dalvik 解释器，并支持 arm、arm64、x86、x86_64、mips 和 mips64。对于计算代码而言，ART 的 Mterp 大致相当于 Dalvik 的快速解释器。 不过，有时候，它的速度可能会显著变慢，甚至急剧变慢：

• 调用性能。
• 字符串操作和 Dalvik 中其他被视为内嵌函数的高频用户方法。
• 堆栈内存使用量较高。

Android 8.0 解决了这些问题。

说了这么多，无非是安装速度，空间占用，运行速度的平衡，目前 Android 应该已经做得很好了,但仍然存在不少诟病。

（四）方舟编译器采用的技术

 **方舟编译器，安卓性能革命突破：**方舟编译器是业界首个多语言联合优化的编译器，开发者在开发环境中可以一次性将多语言统一编译为一套机器码，运行时无需产生跨语言带来的额外消耗，并可以进行跨语言的联合优化，提升运行效率。安卓自身的编译技术在不断的发展，但始终需要在运行中依赖虚拟机来进行动态编译和解释执行，对系统资源消耗较大。而方舟编译器在开发环境中就可以完成全部代码的编译，手机安装应用程序后无需依赖虚拟机资源，即可全速运行程序，带来效率上的极大提升。举一个例子：EMUI 9.1仅仅对系统组件System Server应用了华为方舟编译器后，就带来了系统操作流畅度提升24%，系统响应性能提升44%的收益

**方舟编译器，高效的回收机制：**内存管理是程序开发与运行时需要重点考虑的部分，也和系统流畅度息息相关。安卓在内存回收上采用集中回收机制，发声全局回收时更需要暂停应用，这也是随机卡顿的根因之一。而方舟编译器提供了更高效的内存回收机制，回收时无需暂停应用，随时用随时回收，大大提高运行速度。

** 方舟编译器，应用级编译优化：**代码优化是编译器最为核心的功能，也是评判一个编译器优劣最重要的标准。当前由于安卓应用使用了虚拟机机制，难以面向不同应用对虚拟机进行针对性的灵活优化。安卓ART的AoT和JIT动态编译因为是运行在手机上，受资源所限，因而只能使用简单的优化算法。而方舟编译器由于是在应用开发阶段进行编译，所以可以允许不同应用灵活采用不同的编译优化方案，而且因为在开发环境编译不会受到手机性能的限制，可以使用更多先进的优化算法，从而使得每个应用的性能达到最佳。

**简单易用，开放开源：**华为在持续进行技术创新的同时，也注重将技术成果回馈行业，华为方舟编译器在开发构建的阶段为开发者提供快速的集成编译环境，大大降低了开发者的学习成本和使用成本，令产业与更多用户受益。华为方舟编译器会开始全面开源，邀请整个产业和生态来一起共同关注和提升安卓性能体验。

**超级文件系统，读取更顺畅： **在业界规模商用F2FS文件系统，替代了传统的EXT4文件系统，令用户分区的文件读写流畅度提升20%；而超级文件系统(EROFS)采用专利压缩算法加持，使得系统分区随机读性能平均提升20%，并减少14%系统空间占用。

**超级文件系统，安全又高效：**超级文件系统天然只读设计，系统分区不可被三方改写，更为安全。

**HiAI生态开放共享，更多智能体验：**HiAI开放能力不断增强，支持算子数量增加至147算子，API上线数量增加33个API，接入原子化服务超3200项。已经有很多合作伙伴利用HiAI开放平台给消费者提供了很多创新体验，比如storysign利用HiAI的API能力帮助残障人士进行无障碍的阅读。通过开放的全球生态系统，以及1400+生态合作伙伴和560000+的开发者，用户将会获得更多更丰富的智慧场景体验。