2019 年 4 月 11 日，在上海的华为新品发布会上，除了可以拍电影月亮的华为 P30 系列，余承东还特地抛了两项软件层面的“重磅炸弹”，分别是方舟编译器和 EROFS 超级文件系统；其中，华为方舟编译器可以构建“架构级优化和明显提高性能”，可以解决问题安卓程序“边说明边继续执行”的问题，从而被余承东称作 “安卓性能革命”。发布会完结之后，华为方舟编译器引发了外界的热议。那么，方舟编译器到底是什么？它的 “革命性” 究竟反映在哪里？面临这些问题，华为再一在两周之后举办了媒体沙龙，对方舟编译器展开了更为精细的理解。

Android 生态中编译器的工作原理在理解方舟编译器之前，我们必需得首先理解 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 编译器。按照华为方面的众说纷纭：方舟编译器编译器的应用于在开发阶段就已完成；也就是说，只要是经过编译器编译器的应用于，在应用于市场上下架了以后，用户iTunes APK 的就是编译器过的了。换句话说，通过方舟编译器，开发者的应用于在iTunes之前就早已转化成沦为机器可以辨识的代码，因而可以在手机上较慢加装、启动和运营，而需要在经过 VM 的编译器——或许上，方舟编译器是将编译器过程提早到应用于开发阶段，从而大幅增加了智能手机和操作系统的运营开销。按照华为方面的众说纷纭，使用华为编译器之后，提高效果如下：EMUI 9.1 意味着对系统组件 System Server 应用于了方舟编译器之后，系统简洁速度提高了 24%，系统响应速度提高了 44%；第三方应用于（目前使用了新浪微博公里／小时版）的操作者简洁度提高了 60%。

不可忽视的是，实质上，要想要构建华为所言的效果，就首先必须第三方的应用于开发者使用方舟编译器对自家的 App 提早展开改建，从而需要下架华为应用于商店——这也是余承东在 4 月 11 日的发布会敦促开发者积极参与的原因。除了代码编译器，方舟编译器也获取了更加高效的内存机制，它与 Android 内存重复使用的不同之处在于：内存管理是程序开发与运营时必须重点考虑到的部分，也和系统简洁度息息相关。

Android 在内存重复使用上使用集中于重复使用机制，倾听全局重复使用时更加必须停止应用于，这也是随机卡顿的根因之一。而方舟编译器获取了更加高效的内存重复使用机制，重复使用时需要停止应用于，随时用随时重复使用，大大提高运营速度。另外，在方舟编译器的编译器环境下， 还可以对代码展开优化。

目前，由于 Android ART 的 AoT 和 JIT 动态编译器因为是运营在手机上，不受资源所限，因而不能用于非常简单的优化算法。而方舟编译器由于是在应用于开发阶段展开编译器，所以可以容许有所不同应用于灵活性使用有所不同的编译器优化方案，而且因为在研发环境编译器会受到手机性能的容许，可以用于更加多先进设备的优化算法，从而使得每个应用于的性能达到最佳。2019，全面开源只不过，在 4 月 11 日的发布会上，华为方面早已回应，方舟编译器也将对外开放给第三方合作伙伴，期望联合建构开发者生态的“方舟朋友圈”。

目前，华为早已宣告方舟编译器不会从 2019 年全面开源；其中，华为将在 2019 年 8 月的华为终端开发者大会宣告方舟编译器框架代码开源，先前不会在 2019 年 11 月的绿盟开发者大会构建原始方舟编译器代码开源。对于华为方舟编译器的开源，将维持注目。

(公众号：)录：本文部分内容编成深知乎平台作者 weishu 的问内容，早已取得作者许可。原创文章，予以许可禁令刊登。

下文闻刊登须知。

本文来源：欧博abg官网-www.radiomazal.com