华为公布的方舟编译器到底对安卓软件生态会有多大影响？ 第1页

看到问题下许多答案有误导，忍不住出来解释一下。

Android 平台的绝大多数应用是使用 Java 语言写的，CPU 只能理解汇编指令，无法直接识别 Java 语言的虚拟机指令；为了让 CPU 能运行 Java 语言编写的程序，一般有两种办法：

1. 「计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决」 引入一个中间层，这个中间层负责 Java代码的执行，然后这个中间层本身编译为 CPU 能理解的汇编指令，也就是 CPU -> 中间层 -> Java 代码。如果这个中间层采用 Java 语言直接作为输入，理解一句 Java 语句就把Java语言翻译一下让CPU 执行一段，我们一般称这种模式为「解释执行」。毋庸置疑这种方式效率是相当低效的。
2. 直接把 Java 语言翻译成 CPU 能理解的机器语言。这里又有两种方式：
1. 在程序运行之前直接把 Java 代码编译为机器语言。这种模式我们称之为 AOT （Ahead of time）编译。
2. 在程序运行起来之后，实时地把 Java 语言编译为机器语言然后执行。这种模式称之为 JIT（Just in time） 编译。

背景介绍完了回到 Android 平台上面，Android 平台分为几个阶段：

1. 在 Android 5.0 正式采用 ART 之前，Android 采用的是 解释执行 + 辣鸡 JIT 的方式执行 Java代码。在这个阶段是货真价实的「边解释边执行」的模式，代码效率相当低下，再加上那时候同样辣鸡的 GC （垃圾回收），Android 用起来真是惨不忍睹。
2. Android 5.0 ～ Android 6.0 。Google 推出了 ART （Android Runtime）来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式；Android 应用在安装的时候，系统会把所有Java代码提前编译为机器码。这种模式有两个缺点不能忍：
1. 安装速度巨慢。即使是现在吊炸天的 855 采用 AOT 模式编译一下安装包比较大的应用（如支付宝）可能就要一分钟。那个时候的 CPU 可不如现在，安装一个应用都让你等得头皮发麻。更要命的时候，系统 OTA 开机会对所有的应用执行 AOT 操作，这时候你的开机速度可能要半个小时。。。
2. 占用磁盘空间，Java 代码编译为机器码之后体积会急剧膨胀。
3. Android 7.0 ～ 现在。Google做了很大的改进，基于这样一个事实：我们使用一个应用的时候，基本每个人只使用它一小部分功能，为什么要把所有代码全编译呢？只编译你经常用的那部分代码不就 OK 了，这样安装的时候啥也不干速度飞快，等你用的时候系统就能知道哪部分代码经常被执行，把这部分代码编译为机器码，运行起来速度也快。于是 Google 又引入了 JIT，这时候的执行模式是 AOT + JIT + 解释执行。
1. 应用安装的时候不执行 AOT 编译，安装速度飞快。初次使用应用的时候没有机器码，因此只能解释执行。
2. 应用运行起来之后，系统收集经常被运行的代码的信息，做两件事：1）在必要的时候在运行时直接把 Java 代码编译为机器码 （JIT），然后使用机器码执行提高运行效率。2）把这个「经常被运行的代码信息保存起来」
3. 设备空闲的时候，系统拿出应用运行时候保存的「热点代码信息」直接把这些代码编译为机器码 （AOT）

关于 Android 7.0 系统的演进可以参阅这里：http://s3.amazonaws.com/connect.linaro.org/las16/Presentations/Tuesday/LAS16-201%20-%20ART%20JIT%20in%20Android%20N.pdf

Android 8.0上改进了解释器，解释模式执行效率大幅提升；Android 9.0上提供了预先放置热点代码的方式，应用在安装的时候就能知道常用代码会被提前编译。可以看到，当前 Android 平台的执行模式在空间占用+安装速度+运行速度上已经达到了一个很好的平衡。

回到华为的这个方舟编译器上面，

1. 现在的 Android 是边解释边执行的吗？可以说是，也可以说不是。上面我已经提到了，现在的 Android 是 解释执行 + 还算可以的JIT + AOT 的模式。并且，你也可以手动把应用的代码全部提前编译达到完全 AOT 的效果（很多答案里面提到的 AOT 就是说的这种）；不过这属于开倒车，Google 肯定不会这么做。这样做效果有多大呢？这个我有发言权。之前在支付宝做性能优化的时候，我干过这么一回事：让应用在后台运行的时候请求系统直接采用 everything 模式编译支付宝，本地测试启动速度有爆炸性提升（30%~50%）；但是灰度测试的时候效果不明显，为什么呢？其一是后台全编译运行成功率低，其二是系统的 JIT + 后台 AOT 不是吃素的；考虑到耗电/占空间的问题压根没上线。所以如果华为只是简单地用这种方式去避免所谓的「边解释边执行」那就相当滴 low，但是按照 GPU Turbo这种黑科技来看，我觉得不太可能是这个。
2. 除了 Android 系统的这种 AOT 之外，难道没有别的办法了吗？我不负责任地猜测一下，方舟编译器是不是在Android 应用打包成APK的时候，直接把 Java 代码编译为了机器码？注意这个跟Android系统的那个 AOT 是不样的，系统是在应用安装或者系统空闲的时候做编译；这种方式你下载到的安装包就是编译好的了，不需要系统动手。

如果是第一种，辣鸡华为。如果是第二种，吊炸天！！！当然还有别的可能，不管咋样，静待开源 ：）