启动耗时分析（三）-ART编译分析

原创文章，转载请注明出处，多谢！

一、ART简介

编译方式：具有JIT（Just-In-Time）和AOT(Ahead-of-Time)两种编译方式。
执行方式：解释器执行 和 执行编译后的机器码 两种执行方式。
机器码生成方式：JIT生成的机器码缓存在内存中，优化解释模式的执行，属于运行时优化。而OAT生成的机器码缓存为文件，属于持久化优化，每次编译会更新文件，但是更新频率并不高。

ART 包括一个编译器（dex2oat 工具）和一个为启动 Zygote 而加载的运行时 (libart.so)。dex2oat工具接受一个 APK 文件，并生成一个或多个编译生成文件，然后运行时将会加载这些文件。文件的个数、扩展名和名称会因版本而异，但在 Android O 版本中，将会生成以下文件：

• .vdex：其中包含 APK 的未压缩 DEX 代码，另外还有一些旨在加快验证速度的元数据。
• .odex：其中包含 APK 中已经过 AOT 编译的方法代码。
• .art (optional)：其中包含 APK 中列出的某些字符串和类的 ART 内部表示，用于加快应用启动速度。

ART 如何编译 DEX 代码还有个compile filter以参数的形式来决定：从 Android O 开始，有四个官方支持的过滤器：

• verify：只运行 DEX 代码验证。
• quicken：运行 DEX 代码验证，并优化一些 DEX 指令，以获得更好的解释器性能。
• speed-profile：运行 DEX 代码验证，并对配置文件中列出的方法进行 AOT 编译。
• speed：运行 DEX 代码验证，并对所有方法进行 AOT 编译。

verify 和quicken 他俩都没执行编译，之后代码执行需要跑解释器。而speed-profile 和 speed 都执行了编译，区别是speed-profile根据profile记录的热点函数来编译，属于部分编译，而speed属于全编。

执行效率上：
verify < quicken < speed-profile < speed

编译速度上：
verify > quicken > speed-profile > speed

二、ART编译流程

好，了解这些之后，来看看ART编译工作流：

1. 获取APK，通过dex2oat工具，按编译过滤规则来处理APK, 对应三方应用来说，会在data/app/应用包名+后续一串乱码/oat/arm下生成.vdex 、.odex、.art文件。

2. 解析.odex，加载目标类进内存。

3. 执行方法，先看当前方法是否被编译过，如果被编译过，优先使用JIT编译出来的机器码。如果没被编译过，走解释器执行，通过profile文件记录执行信息，超过一定执行次数之后，当前方法会变为hot code, 该方法会通过JIT thread pool起子线程走JIT编译，生成机器码缓存在内存。

4. JIT编译过程会判断是否有足够内存，如果没有会触发回收。

5. 在应用安装，动态加载， 系统升级， 后台优化( BackgroundDexoptService)等场景下，会触发dex2oat按filter来编译。

以安装今日头条为例：

看dex2oat打印：

05-21 17:57:39.616 24172 24172 I dex2oat : /system/bin/dex2oat --input-vdex-fd=-1 --output-vdex-fd=20 --compiler-filter=quicken -j6 --classpath-dir=/data/app/com.ss.android.article.news-04WytBf3RuKm3X6VBBOP3g== --class-loader-context=PCL[/system/framework/org.apache.http.legacy.boot.jar] --generate-mini-debug-info --compact-dex-level=none --compilation-reason=install

compiler-filter=quicken filter选择
-j6 6个线程执行
classpath-dir=/data/app/com.ss.android.article.news-04WytBf3RuKm3X6VBBOP3g== 编译后文件生成路径
compilation-reason=install 编译原因

或者dumpsys package也可以

Dexopt state:
[com.ss.android.article.news]
path: /data/app/com.ss.android.article.news-22v64QNFAxsuXgieztZHkQ==/base.apk
arm: [status=quicken] [reason=install]

既然选择的是quicken，那安装过程就没有编译，之后的启动会走解释模式，考虑的点应该是加快安装速度，减少内存压力以及减少CPU抢占时间。

看下系统属性配置：

[pm.dexopt.bg-dexopt]: [speed] 后台优化
[pm.dexopt.boot]: [verify] 系统升级
[pm.dexopt.first-boot]: [quicken] 首次启动
[pm.dexopt.install]: [speed-profile] 应用安装
...

Android P上开始install的compile-filter调整为了speed-profile，但是首次安装profile应该不存在，因此又调整为quicken。

三、启动时间相关
主要还是看执行模式

• Android大版本之间相同场景的执行模式是否有区别， dex2oat编译的时候会耗时，并且是多线程的，cpu占用率也会比较高。
• 方法执行是走的解释模式还是执行机器码，执行时间会有差别。

处理方法
如果应用running时间差距比较大，则可以将应用强制按speed进行编译，对比执行效率差异。
adb shell cmd package compile -c -f -m speed <包名>
应用编译成speed模式后，理论上同平台的机器对比，相同阶段（比如同一个inflate）耗时应该接近。若按speed编译后还存在差异，那就得看是否是其他方面的问题了。

参考：
ART Configuration
JIT Compilation