ART dex2oat Compiler –Quick 和Optimizing

我们知道,在Android的最初的几个版本,Android的app 运行在Dalvik中,完全是解释性执行.在Android2.2中,Google把JVM中常用的技术JIT带进了Dalvik,并且增加了多线程的处理能力.在L 中,正式推出ART.

下面是ART 的架构图.

首先ART兼容Dalvik.也就是说ART 能运行”dex”(Dalvik执行文件).因此对Androidapp的开发者来说,他们没有什么区别.两者最大的区别是:ART把JIT(Just-in-Time)变成了AOT(Ahead-of-Time).JIT需要在每次运行app时都需要执行一遍,而AOT 只需要执行一次,而后续再运行此app是不需要再执行,其明显提高了性能.当然ART 这样做,也是有代价的,那就是以空间换时间.ART能对应用的所有code做优化,其把bitcode 编译为ELF文件.而ELF文件也往往比odex文件大很多.而JIT 只能对local/method做优化.ART的另一个缺点是其第一次执行优化时需要更长的时间.这也是导致第一次开机时间过长的原因.

ART把bitcode 编译为ELF文件目前有两种方式，Quick和Optimizing。也就是其=--compiler-backend有两种方式。--compiler-backend=(Quick|Optimizing)

Quick

Quick 是Dalvik JIT编译器的AOT版本。其性能比Dalvik好。其优点是编译快也是其生成nativecode比较快。然而其运行效率差。

Optimizing

为了更好的支持ART，google针对ARM 的AArch64 和AArch32 指令集对Optimizing compiler 做了相关的优化。而且预留了相关优化的接口供硬件厂商进行优化。相比Quick 其缺点是生成native code比较慢。但是其运行的效率比较高。

和Quick比，Optimizing主要做了两方面的改进。

• 其优化完全从头开始，以产生卓越的代码质量。在Optimizing 中用一个IR (IntermediateRepresentation) 二不像Quick中使用两个IR。其对常量和全局变量有了全新的优化。
• 另一个主要的改进是改进的寄存器分配形式。Quick 使用非常简单的算法来分配寄存器。Quick的目标是speed 而不是效率，这就导致了大量的寄存器被泄露给堆栈。而Optimizing采用LinearScan Register Allocation 算法，其在compiler的时候比较慢，但是提供了更好的运行perfromance。用更少的寄存器来节省堆栈和更好地利用可用的寄存器，减少的代码执行，从而提高了性能。

How to

使用下面的属性可以改变编译方式。

dalvik.vm.dex2oat-flags=--compiler-backend=Quick

BTW,在Android N中，有将会有JIT/AOT compilation.其目的是加快app的安装。详见

https://developer.android.com/preview/api-overview.html#jit_aot