启动耗时分析(三)-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

禁止转载,如需转载请通过简信或评论联系作者。