解读| 华为方舟编译器是如何实现Android 性能革命的？
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 编译器。按照华为方面的说法：方舟编译器编译的应用在开发阶段就已完成；也就是说，只要是经过编译器编译的应用，在应用市场上上架了以后，用户下载APK 的就是编译过的了。
换句话说，通过方舟编译器，开发者的应用在下载之前就已经转化成为机器可以识别的代码，因而可以在手机上快速安装、启动和运行，而无需在经过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的回答内容，已经获得作者授权。
https://m.leiphone.com/news/201904/oshefuZTLnU00mJO.html
心得：好吧，其实我整天都看不懂，只知道好像很厉害
有厉害的人可以解释个吗感谢
这样子卓卓是不是在效能上要成功反超果果了呢！
太令人期待啦！
PS. 这应该不是偏颇的媒体吧…拜托别水桶我