2019 年 4 月 11 日，在上海的华为新品发布会上，除了可以拍月亮的华为 P30 系列，余承东还亲自抛出了两项软件层面的“重磅炸弹”，分别是方舟编译器和 EROFS 超级文件系统；其中，华为方舟编译器可以实现“架构级优化和显著提升性能”，可以解决安卓程序“边解释边执行”的问题，从而被余承东称之为 “安卓性能革命”。
发布会结束之后，华为方舟编译器引起了外界的热议。
那么，方舟编译器究竟是什么？它的 “革命性” 到底体现在哪里？面对这些问题，华为终于在两周之后举行了媒体沙龙，对方舟编译器进行了更加细致的解读。
在了解方舟编译器之前，我们必须得首先了解 Android 操作系统中的编译器的运行机制。
雷锋网从 VirtualXposed/太极的作者 weishu 处了解到，当前 Android 平台的绝大多数应用是使用 Java 语言写的，CPU 只能理解汇编指令，无法直接识别 Java 语言的虚拟机指令；为了让 CPU 能运行 Java 语言编写的程序，一般有两种办法：
引入一个中间层，这个中间层负责 Java 代码的执行，然后这个中间层本身编译为 CPU 能理解的汇编指令，也就是 CPU -> 中间层 -> Java 代码。如果这个中间层采用 Java 语言直接作为输入，理解一句 Java 语句就把Java语言翻译一下让 CPU 执行一段，我们一般称这种模式为「解释执行」。毋庸置疑这种方式效率是相当低效的。
直接把 Java 语言翻译成 CPU 能理解的机器语言。这里又有两种方式：第一，在程序运行之前直接把 Java 代码编译为机器语言。这种模式称之为 AOT（Ahead of time）编译；第二，在程序运行起来之后，实时地把 Java 语言编译为机器语言然后执行。这种模式称之为 JIT（Just in time） 编译。
具体在 Android 平台上，代码编译经历了数个阶段。
在 Android 5.0 正式采用 ART 之前，Android 采用的是解释执行 + JIT 的方式执行 Java 代码。在这个阶段是货真价实的「边解释边执行」的模式，代码效率相当低下，再加上那时候同样表现不行的 GC（垃圾回收），Android 非常难用。
在 Android 5.0 至 Android 6.0 阶段，Google 推出了 ART（Android Runtime）来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式；Android 应用在安装的时候，系统会把所有Java代码提前编译为机器码。这种模式有两个缺点：
安装速度巨慢。即使是高通骁龙 855 采用 AOT 模式编译一下安装包比较大的应用（如支付宝）可能就要一分钟。而那个时候的 CPU 并不如现在，安装一个应用需要很长时间。更要命的是，系统 OTA 开机会对所有的应用执行 AOT 操作，这时候开机速度可能需要很长时间。
占用磁盘空间，Java 代码编译为机器码之后体积会急剧膨胀。
到了 Android 7.0，Google 做了很大的改进；这一改进是基于这样一个事实：我们使用一个应用的时候，基本每个人只使用它一小部分功能，为什么要把所有代码全编译呢？因此只编译用户经常用的那部分代码就 OK 了，这样安装的时候速度比较快，等用户启动的时候系统就能知道哪部分代码经常被执行，把这部分代码编译为机器码，运行起来速度也快。
于是 Google 又引入了 JIT，这时候的执行模式是 AOT + JIT + 解释执行。具体来看：
应用安装的时候不执行 AOT 编译，安装速度飞快。初次使用应用的时候没有机器码，因此只能解释执行。
应用运行起来之后，系统收集经常被运行的代码的信息，做两件事：1）在必要的时候在运行时直接把 Java 代码编译为机器码 （JIT），然后使用机器码执行提高运行效率。2）把这个「经常被运行的代码信息保存起来」。
设备空闲的时候，系统拿出应用运行时候保存的「热点代码信息」直接把这些代码编译为机器码 （AOT）。
Android 8.0 上改进了解释器，解释模式执行效率大幅提升；Android 10.0 上提供了预先放置热点代码的方式，应用在安装的时候就能知道常用代码会被提前编译。可以看到，当前 Android 平台的执行模式在空间占用+安装速度+运行速度上已经达到了一个很好的平衡。
总结来看，目前的 Android 采用的是解释执行 + 还算可以的 JIT + AOT 的综合模式；但并没有摆脱这样一个前提，即应用在被打包成 APK 的时候，采用的还是 Java 代码。换句话说，在 APK 变成用户可应用的过程中，还经历了一个在 Android 系统内部的编译过程，这是一个绕不过的坎。
按照华为方面在媒体沙龙中的解读，这个在现有 Android 中绕不过去的坎，被称为虚拟机（Virtual Machine，简称 VM），它包含翻译器和编译器，其目的就是把 Java 高级语言转换成机器能懂的语言——这一转换过程导致卡顿，并且 VM 的统一回收内存垃圾额也会带来卡顿。
华为方舟编译器究竟改变了什么？
首先，方舟编译器是配合华为 EMUI 9.1 操作系统而打造的一个编译工具。
按照华为方面的说法，虽然方舟编译器是在 2019 年 4 月 11 日发布，但是华为早在 5 年前就开始布局，2013 年推出了自研编译器 HCC，2014 年编程大神 Fred Chow 加入，担任华为编译器技术首席科学家，2016 年华为成立编译器与编程语言实验室，投入了数百的专家团队经历了多次尝试，才在 EMUI 9.1 上实现了机器代码的翻译。
按照上述 Android 操作系统的代码运行逻辑，华为编译器最大的优势在于，它绕过了 VM。
简单来说，在百人专家团队的打造下，华为方舟编译器可以将高级语言（Java）直接变成机器码，无需再通过 Android 操作系统中内置的 VM 编译器。按照华为方面的说法：方舟编译器编译的应用在开发阶段就已完成；也就是说，只要是经过编译器编译的应用，在应用市场上上架了以后，用户下载 APK 的就是编译过的了。
换句话说，通过方舟编译器，开发者的应用在下载之前就已经转化成为机器可以识别的代码，因而可以在手机上快速安装、启动和运行，而无需在经过 VM 的编译——某种程度上，方舟编译器是将编译过程提前到应用开发阶段，从而大幅度减少了智能手机和操作系统的运行负担。
按照华为方面的说法，采用华为编译器之后，提升效果如下：
EMUI 9.1 仅仅对系统组件 System Server 应用了方舟编译器之后，系统流畅速度提升了 24%，系统响应速度提升了 44%；
第三方应用（目前采用了新浪微博极速版）的操作流畅度提升了 60%。
不可忽视的是，实际上，要想实现华为所言的效果，就首先需要第三方的应用开发者采用方舟编译器对自家的 App 提前进行改造，从而能够上架华为应用商店——这也是余承东在 4 月 11 日的发布会呼吁开发者积极参与的原因。
除了代码编译，方舟编译器也提供了更高效的内存机制，它与 Android 内存回收的不同之处在于：
内存管理是程序开发与运行时需要重点考虑的部分，也和系统流畅度息息相关。Android 在内存回收上采用集中回收机制，发声全局回收时更需要暂停应用，这也是随机卡顿的根因之一。而方舟编译器提供了更高效的内存回收机制，回收时无需暂停应用，随时用随时回收，大大提高运行速度。
另外，在方舟编译器的编译环境下， 还可以对代码进行优化。目前，由于 Android ART 的 AoT 和 JIT 动态编译因为是运行在手机上，受资源所限，因而只能使用简单的优化算法。而方舟编译器由于是在应用开发阶段进行编译，所以可以允许不同应用灵活采用不同的编译优化方案，而且因为在开发环境编译不会受到手机性能的限制，可以使用更多先进的优化算法，从而使得每个应用的性能达到最佳。
其实，在 4 月 11 日的发布会上，华为方面已经表示，方舟编译器也将开放给第三方合作伙伴，希望共同构建开发者生态的“方舟朋友圈”。
目前，华为已经宣布方舟编译器会从 2019 年全面开源；其中，华为将在 2019 年 8 月的华为终端开发者大会宣布方舟编译框架代码开源，后续会在 2019 年 11 月的绿盟开发者大会实现完整方舟编译器代码开源。
对于华为方舟编译器的开源，雷锋网将保持关注。
雷锋网注：本文部分内容编自知乎平台作者 weishu 的回答内容，已经获得作者授权。
正在生成分享图...
覃倩雯