Android ART

转载：https://www.jianshu.com/p/bdb6c29aca83

在了解 Android 运行时之前，我们需要了解什么是运行时环境以及一些基本概念，即 Java 虚拟机（JVM）和 Dalvik 虚拟机（DVM）的功能。

什么是运行时？
简单来说，运行时就是一个供操作系统使用的系统，它负责将你用高级语言（比如 Java）编写的代码转换成 CPU/处理器能够理解的机器码。

运行时由你的程序运行时所执行的指令构成，尽管本质上它们不属于程序代码的任何一部分。

CPU （或者更通用的说法电脑）只能够理解机器语言（二进制代码），所以为了使程序能够在 CPU 上运行，就必须将它们翻译成机器码，这一工作由翻译器完成。

这里按序列出历代翻译器：
1.汇编器
它直接将汇编语言翻译成机器码，所以它的速度非常快。

2.编译器
它将源码翻译成汇编语言，然后再用汇编器转换成机器码。这种方式编译过程很慢但是执行速度很快。但是使用编译器最大的问题是编译出来的机器码依赖于特定的平台。换句话说，在一台机器上可以运行的代码在另一台不同的机器上可能就无法运行。

3.解释器
它在执行程序时才翻译代码。由于代码翻译是在执行阶段才发生，所以执行速度很慢。

JAVA 代码是怎么执行的？
为了使代码和平台无关，JAVA开发了 JVM，即 Java 虚拟机。它为每一个平台开发一个 JVM，也就意味着 JVM 是和平台相关的。Java 编译器将 .java 文件转换成 .class文件，也就是字节码。最终将字节码提供给 JVM，由 JVM 将它转换成机器码。

这比解释器要快但是比 C++ 编译要慢。

Android 代码是怎么执行的
在 Android 中，Java 类被转换成 DEX 字节码。DEX 字节码通过 ART 或者 Dalvik runtime 转换成机器码。这里 DEX 字节码和设备架构无关。

Dalvik 是一个基于 JIT（Just in time）编译的引擎。使用 Dalvik 存在一些缺点，所以从 Android 4.4（Kitkat）开始引入了 ART 作为运行时，从 Android 5.0（Lollipop）开始 ART 就全面取代了Dalvik。Android 7.0 向 ART 中添加了一个 just-in-time（JIT）编译器，这样就可以在应用运行时持续的提高其性能。

重点：Dalvik 使用 JIT（Just in time）编译而 ART 使用 AOT（Ahead of time）编译。

下图描述了 Dalvik 虚拟机和 Java 虚拟机之间的差别。

Just In Time (JIT)
使用 Dalvik JIT 编译器，每次应用在运行时，它实时的将一部分 Dalvik 字节码翻译成机器码。在程序的执行过程中，更多的代码被被编译并缓存。由于 JIT 只翻译一部分代码，它消耗的更少的内存，占用的更少的物理存储空间。

Ahead Of Time（AOT）
ART 内置了一个 Ahead-of-Time 编译器。在应用的安装期间，他就将 DEX 字节码翻译成机器码并存储在设备的存储器上。这个过程只在将应用安装到设备上时发生。由于不再需要 JIT 编译，代码的执行速度要快得多。

由于 ART 直接运行的是应用的机器码（native execution），它所占用的 CPU 资源要少于 使用 JIT 编译的 Dalvik。由于占用较少的 CPU 资源也就消耗更少的电池资源。

ART 和 Dalvik 一样使用的是相同的 DEX 字节码。编译好的应用如果使用 ART 在安装时需要额外的时间用于编译，同时还需要更多的空间用于存储编译后的代码。

Android 为什么要使用虚拟机？
Android 使用虚拟机作为其运行环境是为了运行 APK 文件构成的 Android 应用。它的优点有：

应用代码和核心的操作系统分离。所以即使任意一个程序中包含恶意的代码也不会直接影响系统文件。这使得 Android 操作系统更稳定可靠。
它提高了跨平台兼容性或者说平台独立性。这意味着即使某一个应用是在 PC 上编译的，它也可以通过虚拟机在移动平台上执行。

ART 的优点
应用运行更快，因为 DEX 字节码的翻译在应用安装是就已经完成。
减少应用的启动时间，因为直接执行的是 native 代码。
提高设备的续航能力，因为节约了用于一行一行解释字节码所需要的电池。
改善的垃圾回收器
改善的开发者工具
ART 的缺点
应用安装需要更长的时间，因为 DEX 字节码需要在安装时就翻译成机器码。
由于在安装时时生成的 native 机器码是存储在内部存储器上，所以需要更多的内部存储空间。
结论
DEX 是专门为 Android 设计的一种字节码格式，主要是为了消耗更少的内存进行优化。ART 是为了在低端设备上运行多个虚拟机而开发的，这一目的通过使用 DEX 字节码实现。它使得应用的 UI 反应更及时。这就是我个人的全部观点。更多关于 ART 和 Dalvik 的细节可以参考Android 官方文档。

本文译自Closer Look At Android Runtime: DVM vs ART

ART 参数介绍

我们知道在Android N 中对其 ART做了比较大的变化。主要是同一程序的代码可能同时运行在本地机器码（编译）、解释和JIT（Just In Time）的混合运行模式，并且不同的用户，同一应用程序的代码，可能运行不同的编译代码。因为有了Profile-guided JIT/AOT Compilation，那么不同的用户行为对同一app可能会有不同的编译结果。N 上做此变化的其目的是为了在安装时间、内存占用、电池消耗和性能之间获得最好的折衷。

ART是在Android KitKat引入并在Lollipop中设为默认的运行方式。ART的主要特征之一就是安装时对应用的AOT编译。这种方式的主要优点就是优化产生的本地代码性能更好，执行起来需要更少的电量。劣势在于安装文件所需的空间和时间。在Lollipop和Marshmallow（译者注：Android 6.0）中，大的应用需要数分钟才能安装完。为了改变这种状态，Android N实现了一个混合模式的运行环境。应用在安装时不做编译，而是解释字节码，所以可以快速启动。ART中有一种新的、更快的解释器，通过一种新的JIT完成，但是这种JIT的信息不是持久化的。取而代之的是，代码在执行期间被分析，分析结果保存起来。然后，当设备idle和充电的时候，ART会执行针对“热代码”进行AOT编译，其他代码不做编译。为了得到更优的代码，ART采用了几种技巧包括深度内联。

对同一个应用可以编译数次，或者找到变“热”的代码路径或者对已经编译的代码进行新的优化，这取决于分析器在随后的执行中的分析数据。

这种混合使用AOT、解释、JIT的策略有如下优点：
即使是大应用，安装时间也能缩短到几秒
系统升级能更快地安装，因为不再需要优化这一步
应用的内存占用更小，有些情况下可以降低50%
改善了性能
更低的电池消耗

JIT architecture

JIT compilation works in this manner:

The user runs the app, which then triggers ART to load the .dex file.

If the .oat file (the AOT binary for the .dex file) is available, ART uses them directly. Note that .oat files are generated regularly. However, that does not imply they contain compiled code (AOT binary).

If no .oat file is available, ART runs through either JIT or an interpreter to execute the .dex file. ART will always use the .oat files if available. Otherwise, it will use the APK and extract it in memory to get to the .dex incurring a big memory overhead (equal to the size of the dex files).

JIT is enabled for any application that is not compiled according to the “speed” compilation filter (which says, compile as much as you can from the app).

The JIT profile data is dumped to a file in a system directory. Only the application has access to the directory.

The AOT compilation (dex2oat) daemon parses that file to drive its compilation.

Android N的编译模式
在compiler_filter.h，我们可以看到dex2oat一共有12种编译模式：

enum Filter {   
    VerifyNone,           // Skip verification but mark all classes as verified anyway.
    kVerifyAtRuntime,     // Delay verication to runtime, do not compile anything.
    kVerifyProfile,       // Verify only the classes in the profile, compile only JNI stubs.
    kInterpretOnly,       // Verify everything, compile only JNI stubs.
    kTime,                // Compile methods, but minimize compilation time.
    kSpaceProfile,        // Maximize space savings based on profile.
    kSpace,               // Maximize space savings.
    kBalanced,            // Good performance return on compilation investment.
    kSpeedProfile,        // Maximize runtime performance based on profile.
    kSpeed,               // Maximize runtime performance.
    kEverythingProfile,   // Compile everything capable of being compiled based on profile.
    kEverything,          // Compile everything capable of being compiled.
};

以上12种编译模式按照排列次序逐渐增强，那系统默认采用了哪些编译模式呢？我们可以在在手机上执行getprop | grep pm查看:

pm.dexopt.ab-ota: [speed-profile]
pm.dexopt.bg-dexopt: [speed-profile]
pm.dexopt.boot: [verify-profile]
pm.dexopt.core-app: [speed]
pm.dexopt.first-boot: [interpret-only]
pm.dexopt.forced-dexopt: [speed]
pm.dexopt.install: [interpret-only]
pm.dexopt.nsys-library: [speed]
pm.dexopt.shared-apk: [speed]

其含义如下，

install(应用安装)与first-boot(应用首次启动)使用的是[interpret-only]，即只verify，代码解释执行即不编译任何的机器码，它的性能与Dalvik时完全一致。

ab-ota(系统升级)与bg-dexopt(后台编译)使用的是[speed-profile]，即只根据“热代码”的profile配置来编译。这也是N中混合编译的核心模式。

对于动态加载的代码，即forced-dexopt，它采用的是[speed]模式，即最大限度的编译机器码，它的表现与之前的AOT编译一致。

总的来说，程序使用loaddex动态加载的代码是无法享受混合编译带来的好处，我们应当尽量采用ClassN.dex方式来符合Google的规范。这不仅在ota还是混合编译上，都会带来很大的提升。

Profile-guided compilation

JIT WORK FLOW

dex2oat编译

首先我们来看系统在什么时候会对各个应用做JIT/AOT编译呢？手机在充电＋空闲等多个条件下，通过BackgroundDexOptService.java中的JobSchedule下触发编译优化。

js.schedule(new JobInfo.Builder(JOB_IDLE_OPTIMIZE, sDexoptServiceName)
.setRequiresDeviceIdle(true)
.setRequiresCharging(true)
.setPeriodic(TimeUnit.DAYS.toMillis(1))
.build());
dex2oat编译参数

对于[speed-profile]模式，dex2oat编译命令的核心参数如下：

dex2oat --dex-file=./base.apk --oat-file=./base.odex --compiler-filter=speed-profile --app-image-file=./base.art
–profile-file=./primary.prof …
其流程：若dex2oat参数中有输入profile文件，会读取profile中的数据。与以往不同的是，这里不仅会根据profile文件来生成base.odex文件，同时还会生成称为app_image的base.art文件。

与boot.art类似，base.art文件主要为了加快应用的对“热代码”的加载与缓存。在apk启动时系统加载应用的oat文件以及可能存在的app image文件，app image的作用是记录已经编译好的“热代码”，并且在启动时一次性把它们加载到缓存。预先加载代替用时查找以提升应用的性能。

JIT 参数

dalvik.vm.usejit - Whether or not the JIT is enabled.

dalvik.vm.jitinitialsize (default 64K) - The initial capacity of the code cache. The code cache will regularly GC and increase if needed. It is possible to view the size of the code cache for your app with:
$ adb shell dumpsys meminfo -d

dalvik.vm.jitmaxsize (default 64M) - The maximum capacity of the code cache.

dalvik.vm.jitthreshold (default 10000) - This is the threshold that the “hotness” counter of a method needs to pass in order for the method to be JIT compiled. The “hotness” counter is a metric internal to the runtime. It includes the number of calls, backward branches & other factors.

dalvik.vm.usejitprofiles <true|false> - Whether or not JIT profiles are enabled; this may be used even if usejit is false.

dalvik.vm.jitprithreadweight (default todalvik.vm.jitthreshold / 20) - The weight of the JIT “samples” (see jitthreshold) for the application UI thread. Use to speed up compilation of methods that directly affect users experience when interacting with the app.

dalvik.vm.jittransitionweight (dalvik.vm.jitthreshold / 10) - The weight of the method invocation that transitions between compile code and interpreter. This helps make sure the methods involved are compiled to minimize transitions (which are expensive).

点击下方链接免费获取Android进阶资料:
https://shimo.im/docs/tXXKHgdjPYj6WT8d/