华为的方舟编译器如何革命？脱离安卓后会不会用在鸿蒙上

czhuosu

在上海的华为新品发布会上，除了可以拍月亮的华为 P30 系列，余承东还亲自抛出了两项软件层面的“重磅炸弹”，分别是方舟编译器和 EROFS 超级文件系统;其中，华为方舟编译器可以实现“架构级优化和显著提升性能”，可以解决安卓程序“边解释边执行”的问题，从而被余承东称之为 “安卓性能革命”。

发布会结束之后，华为方舟编译器引起了外界的热议。
那么，方舟编译器究竟是什么?它的 “革命性” 到底体现在哪里?面对这些问题，华为终于在两周之后举行了媒体沙龙，对方舟编译器进行了更加细致的解读。
4 V/ x, g3 o' @7 |: p' g Android 生态中编译器的工作原理
在了解方舟编译器之前，我们必须得首先了解 Android 操作系统中的编译器的运行机制。
( A6 q% a( c  ^1 n$ B 从 VirtualXposed/处了解到，当前 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代码提前编译为机器码。这种模式有两个缺点：
( C- B& x; O5 ?# I 安装速度巨慢。即使是高通骁龙 855 采用 AOT 模式编译一下安装包比较大的应用(如支付宝)可能就要一分钟。
! O: b. Q8 O" ] 而那个时候的 CPU 并不如现在，安装一个应用需要很长时间。更要命的是，系统 OTA 开机会对所有的应用执行 AOT 操作，这时候开机速度可能需要很长时间。
占用磁盘空间，Java 代码编译为机器码之后体积会急剧膨胀。到了 Android 7.0，Google 做了很大的改进;这一改进是基于这样一个事实：我们使用一个应用的时候，基本每个人只使用它一小部分功能，为什么要把所有代码全编译呢?因此只编译用户经常用的那部分代码就 OK 了，这样安装的时候速度比较快，等用户启动的时候系统就能知道哪部分代码经常被执行，把这部分代码编译为机器码，运行起来速度也快。
于是 Google 又引入了 JIT，这时候的执行模式是 AOT + JIT + 解释执行。具体来看：
7 l5 z- h% J: ] 应用安装的时候不执行 AOT 编译，安装速度飞快。初次使用应用的时候没有机器码，因此只能解释执行。应用运行起来之后，系统收集经常被运行的代码的信息，做两件事：1)在必要的时候在运行时直接把 Java 代码编译为机器码 (JIT)，然后使用机器码执行提高运行效率。2)把这个「经常被运行的代码信息保存起来」。设备空闲的时候，系统拿出应用运行时候保存的「热点代码信息」直接把这些代码编译为机器码 (AOT)。Android 8.0 上改进了解释器，解释模式执行效率大幅提升;Android 10.0 上提供了预先放置热点代码的方式，应用在安装的时候就能知道常用代码会被提前编译。可以看到，当前 Android 平台的执行模式在空间占用+安装速度+运行速度上已经达到了一个很好的平衡。
& R2 t- R, `1 @# S+ d$ L 总结来看，目前的 Android 采用的是解释执行 + 还算可以的 JIT + AOT 的综合模式;但并没有摆脱这样一个前提，即应用在被打包成 APK 的时候，采用的还是 Java 代码。换句话说，在 APK 变成用户可应用的过程中，还经历了一个在 Android 系统内部的编译过程，这是一个绕不过的坎。

按照华为方面在媒体沙龙中的解读，这个在现有 Android 中绕不过去的坎，被称为虚拟机(Virtual Machine，简称 VM)，它包含翻译器和编译器，其目的就是把 Java 高级语言转换成机器能懂的语言——这一转换过程导致卡顿，并且 VM 的统一回收内存垃圾额也会带来卡顿。
华为方舟编译器究竟改变了什么?
4 @2 r1 N; R8 p" U; @6 N" K 首先，方舟编译器是配合华为 EMUI 9.1 操作系统而打造的一个编译工具。
) y2 k  J* T" s, P9 M 按照华为方面的说法，虽然方舟编译器是在 2019 年 4 月 11 日发布，但是华为早在 5 年前就开始布局，2013 年推出了自研编译器 HCC，2014 年编程大神 Fred Chow 加入，担任华为编译器技术首席科学家，2016 年华为成立编译器与编程语言实验室，投入了数百的专家团队经历了多次尝试，才在 EMUI 9.1 上实现了机器代码的翻译。

& z- I$ `% _: K# p7 p, ~! A) R 按照上述 Android 操作系统的代码运行逻辑，华为编译器最大的优势在于，它绕过了 VM。
简单来说，在百人专家团队的打造下，华为方舟编译器可以将高级语言(Java)直接变成机器码，无需再通过 Android 操作系统中内置的 VM 编译器。按照华为方面的说法：方舟编译器编译的应用在开发阶段就已完成;也就是说，只要是经过编译器编译的应用，在应用市场上上架了以后，用户下载 APK 的就是编译过的了。
# @8 H- a5 u, d

换句话说，通过方舟编译器，开发者的应用在下载之前就已经转化成为机器可以识别的代码，因而可以在手机上快速安装、启动和运行，而无需在经过 VM 的编译——某种程度上，方舟编译器是将编译过程提前到应用开发阶段，从而大幅度减少了智能手机和操作系统的运行负担。
9 j" g* o5 u( \- R; Q8 d 按照华为方面的说法，采用华为编译器之后，提升效果如下：
EMUI 9.1 仅仅对系统组件 System Server 应用了方舟编译器之后，系统流畅速度提升了 24%，系统响应速度提升了 44%;第三方应用(目前采用了新浪微博极速版)的操作流畅度提升了 60%。不可忽视的是，实际上，要想实现华为所言的效果，就首先需要第三方的应用开发者采用方舟编译器对自家的 App 提前进行改造，从而能够上架华为应用商店——这也是余承东在 4 月 11 日的发布会呼吁开发者积极参与的原因。
6 a4 T1 R. y/ J" n9 T6 T* F3 {/ E 除了代码编译，方舟编译器也提供了更高效的内存机制，它与 Android 内存回收的不同之处在于：
5 N1 z6 }6 o5 J$ s2 F 内存管理是程序开发与运行时需要重点考虑的部分，也和系统流畅度息息相关。Android 在内存回收上采用集中回收机制，发声全局回收时更需要暂停应用，这也是随机卡顿的根因之一。而方舟编译器提供了更高效的内存回收机制，回收时无需暂停应用，随时用随时回收，大大提高运行速度。
6 L1 n- ]- A8 S: N; D

! z, y3 m, _7 r& a" f* }+ d 另外，在方舟编译器的编译环境下， 还可以对代码进行优化。目前，由于 Android ART 的 AoT 和 JIT 动态编译因为是运行在手机上，受资源所限，因而只能使用简单的优化算法。而方舟编译器由于是在应用开发阶段进行编译，所以可以允许不同应用灵活采用不同的编译优化方案，而且因为在开发环境编译不会受到手机性能的限制，可以使用更多先进的优化算法，从而使得每个应用的性能达到最佳。
(文章内容来源网络，如有侵权请联系我们)



5 K! K% l0 n4 s0 V% ?来源：http://www.yidianzixun.com/article/0M6pEfDE
5 R9 {* K( Y. C/ H+ W  i' U1 z0 a免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！