去年 8 月，华为将鸿蒙操作系统的配套软件方舟编译器的部分源码开源，引发了国内开发者的关注。目前在 Gitee 上，方舟编译器已经拥有 6.8K star 和 1.1K fork。

方舟编译器

作为华为新系统的配套编译器，与尚未公布源码的鸿蒙操作系统不同，方舟编译器最早是华为于去年 4 月在 P30 系列手机发布会上公布的，并在去年 8 月将部分源码公布在了代码托管平台上。 

华为曾表示方舟编译器早期是用于大幅提升手机端安卓系统的运行效率。官方给出的资料显示，方舟不是传统意义上从高级语言到机器码的“万能翻译”，更像是一个编译运行系统。一方面，方舟编译器首次在 Java 领域绕过虚拟机，首次尝试将 Java/C/C++ 等混合代码一次编译成机器码直接在系统上运行，彻底告别 Java 的 JNI 额外开销，也彻底告别了虚拟机 GC 内存回收带来的应用进程掉线，使手机系统操作流畅度大幅提升。

而随着跨端操作系统鸿蒙的发布，方舟编译器的方向则开始往协助鸿蒙操作系统布局边缘计算、服务器等跨端领域转移。

操作系统与编译器

如果说计算机是汽车，那么操作系统就像汽车的控制台，而编译器则是连接控制台和汽车发动机里最核心的汽油燃烧技术，将软件变成计算机的动力。可以说，编译器的编译性能和效率，将直接影响终端用户的使用体验。

目前市面上流行的操作系统，基本上都拥有自己配套的编译器组件。

Linux 系统

各种发行版的 Linux 系统基本上都使用开源的 GCC 编译器。GCC 是由自由软件运动之父 Richard Stallman 在上个世纪 80 年代创立。它原本只处理 C 语言，后续扩展可以处理 C++、Objective-C、Java 等其他语言。GCC 被认为是跨平台软件的编译器首选。 

微软 Windows 系统

使用 CL 编译器。它直接集成在 Visual Studio 或 Visual C++ 的开发者环境中，一般不单独使用。 

苹果 Mac 和 iOS 系统

最初使用 GCC 编译器，现已替代为 Clang + LLVM。苹果之所以将 GCC 更换为自己旗下的 LLVM，是因为他们发现开源的 GCC 开发者根本使唤不动，他们不愿意专门为了苹果公司的要求优化和改进 GCC 代码，所以苹果索性将编译器后端直接替换为 LLVM（Low Level Virtual Machine，底层虚拟机），并且将 LLVM 的发明者 —— 天才少年 Chris Lattner 招入麾下，后来还顺带让他带头搞了编译器前端 Clang 和新编程语言 Swift 。 

安卓系统

安卓主要使用预编译的 Java 语言开发，还有近年新推出的与 Java 兼容的 Kotlin。安卓的最初版本通过虚拟机运行，不需要编译器，后续版本加入了 JIT 和 AOT 编译机制。

Intel 的 ICC 编译器

ICC 编译器，全称 Intel C++ Compiler，是 Intel 开发的 C/C++/Fortran 编译器套装，适用于 Linux、Microsoft 和 Mac OS X 操作系统，广泛应用于高性能计算、分布式计算等商业计算领域。 

SGI 等公司推出的 Open64 编译器

SGI（S 代表超级计算机，G 代表图形工作站，I 代表具有突破性的洞察力）生产的超级计算机，主要应用于巨大的实验室，采用的是 Open64 编译器。

编译器的瓶颈

对传统编译器而言，编译时点、跨语言编译是制约应用程序执行效率的瓶颈。应用程序的执行要经过字节码到机器码的转换，程序员在编程时使用上述 C、C++、Java、C# 等程序语言，但硬件的执行逻辑是基于 0 和 1 的二进制。因此要让硬件能够“读懂”指令，就需要编译器把“程序语言”转译成“机器语言”。 

（1）编译时点：根据编译器工作时点的不同，编译方式可分为两种，但执行效率仍有提升空间。一种是“边执行、边翻译”，程序调用了某一句指令，编译器就实时将其转译为二进制码（早期版本安卓使用该方案，程序执行效率低下）；另一种是引进高性能虚拟机（在安卓系统中为 ART，即 Android Run Time），在程序安装时或系统空闲时就提前将代码转译完毕，进一步提升了程序执行效率，但新的问题在于程序安装时间长。 

（2）跨语言编译：程序往往使用不同语言编写，对编译效率产生较大影响。例如采用 Java 和 C/C++ 等多种语言混合开发的应用程序，在运行时需要借助通用接口来协调不同代码（即 Java Native Interface，JNI）。通用接口需要占用硬件资源，同时不同代码的协调本身就低效，所以传统编译器下跨语言应用的执行效率较低。 

据官方介绍，方舟编译器对以上两大瓶颈的解决方案是：将编译过程提前至开发者环节。在安卓的体系下，一些复杂动态语义的编译仍需交由虚拟机完成。方舟编译器开发团队通过梳理 Java 的动态语义，进行了大规模的数据建模，尤其是在跨语言编译时，提高了动态语义分析的精度；另外，华为设计了一套动态语义匹配机制，降低了运行时动态语义的开销。最终结果是，方舟编译器能够在应用程序执行之前，就将 Java 代码编译成机器语言，极大释放了硬件资源，这一点对于多终端尤其是物联网边缘计算而言尤为重要。

方舟的应用实例

虽然已经开源并公布了一些特性，但方舟编译器目前仅开源了部分代码，普通开发者很难窥知全貌。因此，关于方舟现在究竟能不能用仍然是很多吃瓜群众讨论的话题。

去年 6 月，贴吧的搞机大佬通过 root 后的华为手机获得了系统固件信息，证实了手机上已经在跑着方舟。 

去年 10 月，隶属于中科院软件研究所的程序语言与编译技术实验室（PLCT） 在一个培训项目 pacific 上实现了基于方舟编译器的 Hello World 程序，成为业内首个方舟编译器 runtime 实现，“实现了从 0 到 1 的一个跨越”。该项目代码目前在 Gitee 的方舟编译器孵化器中。

今年 4 月，方舟编译器孵化器开源 MapleEngine 项目，完善了方舟编程体系的版图。MapleEngine 也叫方舟引擎，是方舟编程体系的重要环节。据悉，方舟编程体系的整体目标是构建一个软件开发的全栈技术，包括编程语言、多语言前端、编译器、执行引擎以及一系列工具链。

整个方舟体系依靠 MapleIR 贯穿前后，MapleIR 是程序的中间表示，是编程体系中程序的表达方式。编译器把 MapleIR 转换成机器码或者保留 MapleIR 中间码，方舟引擎则担负着执行该中间码的任务。可以认为方舟引擎和 JVM 类似，但超越了 JVM，因为它不再是执行单一的 Java 程序。理论上说，只要能翻译成 MapleIR 的程序，都可以由方舟引擎执行。 

此外，最近知乎上也有大神对支持方舟编译器的某新闻类 APP 进行了测试，结果证实该 APP 确实能够通过方舟跑通。

无论如何，如今距离方舟编译器开源已经过去了一年，希望今年我们可以看到鸿蒙与方舟令人心服口服的 “ code show ” 。

参考链接：

https://www.oschina.net/question/2918182_2310841

https://www.oschina.net/news/110785/pacific-0-1-released

https://zhuanlan.zhihu.com/p/161995928

https://zhuanlan.zhihu.com/p/154438363