dex文件经过dex2oat编译，会生成.art、.oat两个文件，oat是一个android定制的elf文件，原唤坦始dex也保存在其中。8.0后，dex单独保存到.vdex文件中。art文件类似于一个内存映像，缓存常用的ArtField、ArtMethod、DexCache等内容，加载后可直接使用，避免解析耗时。
以boot.art为例，它分为Image Section和Bitmap Section区域。每个Section在文件中的偏移量和大小由ImageSection类来描述。
主要Section介绍：
Bitmap Section：
Bitmap区域是一个位图，用于描述Object Section里各个Object的地址，以8字节对齐。如果一个比特位的值为1，则它指向Object Section中的一个Object对象。
假设Object存储的基地址是0x70000000，如果位图第N个比特位为1，那么这个比特位指向的Object对象地址为0x70000000+N*8。
art/runtime/image.h：
oat文件本质上是一个ELF文件，它将OAT文件格式内嵌在ELF文件里。
在oat文件的dymanic section中，导出了三个符号oatdata、oatexec和oatlastword，分别用来描述oatdata和oatexec段加载到内存后的起止地址。
oatdata段中，包含原dex文件的完整内容(8.0后在.vdex文件)，dex文件里面的类方法所对脊橡应的本樱链旁地机器指令保存在oatexec段中。
OAT主要内容介绍：
vdex格式：
boot.art、boot.oat、boot.vdex三者是一体的，相互依赖。
zygote启动创建Heap的时候，会加载boot.art，然后加载boot.oat，再然后加载boot.vdex。
调用流程如下：
dextra
vdexExtractor
compact_dex_converter
Android 9（Pie）推出了一种新型Dex文件，即Compact Dex（Cdex）。Cdex是一种ART内部文件格式，它压缩各种Dex数据结构（例如方法头）并对多索引文件中的常见数据blob（例如字符串）进行重复数据删除。来自输入应用程序的Dex文件的重复数据删除数据存储在Vdex容器的共享部分中。
由于Vdex容器存储的是Cdex文件而不是标准的Dex，因此需要借助compact_dex_converter工具来实现提取dex。
安装提取工具步骤(ubuntu)：
提取： (工具并不完美，提取dex后有些不能正常jadx反编译)
*** 作方法如码埋下：?1、使用File Magic打开OAT文件。
?2、尽管某些文件皮腔必须以二进制文件格式打开（即在开发它的程序或设备中），但您也许可以使用通用软件查看器打开它。根据确切的文件格式，您可以使用通用软件查看器，如File Magic [下载]打开OAT文件。立即下载File Magic，用一个程序打开OAT文件和数百个其他文件燃模衫类型。
深入理解Android Runtime申国骏
2022-08-08 12:31·字数:2599·阅读:2340
image.png
上图是Android整体的架构，Android Runtime之于Android而言相当于心脏之于人体，是Android程序加载和运行的环境。这篇文章主要针对Android Runtime部分进行展开，探讨Android Runtime的发展以及目前现状，并介绍应用Profile-Guided Optimization(PGO)技术对应用启动速度进行优化的可行性。转载请注明来源「申国骏」
App运行时演进
JVM
Android原生代码使用Java或者Kotlin编写，这些代码会通过javac或者kotlinc编译成.class文件，在Android之前，这些.class文件会被输入到JVM中执行。JVM可以简单分为三个子系统，分别是Class Loader、Runtime Data Area以及Execution Engine。其中Class Loader主要负责加载类、校验字节码、符号引用链接及对静态变量和静态方法分配内存并初始化。Runtime Data负责存储数据，分为方法区、堆区、栈区、程序计数器以及本地方法栈。Execution Engine负责二进制代码的执行以及垃圾回收。
image.png
Execution Engine中，会采用Interpreter或者JIT执行。其中Interpreter表示在运行的过程中对二进制代码进行解释，每次执行相同的二进制代码都进行解释比较浪费资源，因此对于热区的二进制代码会进行JIT即时编译，对二进制代码编译成机器码，这样相同的二进制代码执行时，就不用再次进行解释。
image.png
DVM(Android 2.1/2.2)
JVM是stack-based的运行环境，在移动设备中对性能和存储空间要求较高，因此Android使用了register-based的Dalvik VM。从JVM转换到DVM我们需要将.class文件转换为.dex文件，从.class转换到.dex的过程需要经过 desugar ->proguard ->dex compiler三个过程，这三个过程后来逐步变成 proguard ->D8(Desugar) 直到演变到今天只需要一步R8(D8(Desugar))。
image.png
我们主要关注Android中Runtime Engine与JVM的区别。在Android早期的版本里面，只存在Interpreter解释器，到了Android2.2版本将JIT引入，这个版本Dalvik与JVM的Runtime Engine区别不大。
image.png
ART-AOT(Android 4.4/5.0)
为了加快应用的启动速度和体验，到了Android4.4，Google提供了一个新的运行时环境ART(Android Runtime)，到了Android5.0，ART替换Dalvik成为唯一的运贺键高行时环境。
image.png
ART运行时环境中，采用了AOT(Ahead-of-time)编译方式，即在应用安装的时候就将.dex提前编译成机器码，经过AOT编译之禅尺后.dex文件会生成.oat文件。这样在应用启动执行的时候，因为不需要进行解释编译，大大加快了启动速度。
image.png
然而AOT带来了以下两个问题：
应用安装时间大幅增加，由于在安装的过程中同时需要编译成机器码，应用安装时间会比较长，特别在系统升级的时候，需要对所有应用进行重新编译，出现了经典的升级等待噩梦。
image.png
应用占用过多的存储空间，由于所有应用都被编译成.oat机器码，应用所占的存储亮冲空间大大增加，使得本来并不充裕的存储空间变得雪上加霜。
进一步思考对应用全量进行编译可能是没有必要的，因为用户可能只会用到一个应用的部分常用功能，并且全量编译之后更大的机器码加载会占用IO资源。
ART-PGO(Android 7.0)
从Android7.0开始，Google重新引入了JIT的编译方式，不再对应用进行全量编译，结合AOT、JIT、Interpreter三者的优势提出了PGO(Profile-guided optimization)的编译方式。
在应用执行的过程中，先使用Interpreter直接解释，当某些二进制代码被调用次数较多时，会生成一个Profile文件记录这些方法存储起来，当二进制代码被频繁调用时，则直接进行JIT即时编译并缓存起来。
当应用处于空闲（屏幕关闭且充电）的状态时，编译守护进程会根据Profile文件进行AOT编译。
当应用重新打开时，进行过JIT和AOT编译的代码可以直接执行。
这样就可以在应用安装速度以及应用打开速度之间取得平衡。
image.png
image.png
JIT 工作流程：
image.png
ART-Cloud Profile(Android 9.0)
不过这里还是有一个问题，就是当用户第一次安装应用的时候并没有进行任何的AOT优化，通常会经过用户多次的使用才能使得启动速度得到优化。
image.png
考虑到一个应用通常会有一些用户经常使用执行的代码（例如启动部分以及用户常用功能）并且大多数时候会有先行版本用于收集Profile数据，因此Google考虑将用户生成的Profile文件上传到Google Play中，并在应用安装时同时带上这个Profile文件，在安装的过程中，会根据这个Profile对应用进行部分的AOT编译。这样当用户安装完第一次打开的时候，就能达到较快的启动速度。
image.png
image.png
Profile in cloude 需要系统应用市场支持，在国内市场使用Google Play的占比非常低，因此cloud profile的优化在国内几乎是没有作用的，不过Profile的机制提供了一个可以做启动优化的思路。早在2019年，支付宝就在秒开技术的回应的里面提到过profile-based compile的技术，参考：如何看待今日头条自媒体发布谣言称「支付宝几乎秒开是因为采用华为方舟编译器」？，这也是我们一直研究Profile技术的原因。困扰着我们的一直有两个问题，第一个问题是如何生成Profile文件，第二个问题是怎么使用生成的Profile文件。对于第一个问题的解决相对还是有思路的，因为app运行就会生成profile文件，因此我们手动运行几次app就能在文件系统中收集到这个文件，不过如何以一种较为自动化的手段收集仍然是个问题。第二个问题我们知道Profile文件最终生成的位置，因此我们可以把生成的文件放到相应的系统目录，不过大多数手机和应用都没有权限直接放置这个文件。因此Profile优化技术一直都没有落地，直到Baseline Proflie让我们看到了希望。
Baseline Profile
Baseline Profile是一套生成和使用Profile文件的工具，在2022年一月份开始进入视野，随后在Google I/O 2022随着Jetpack新变化得到广泛关注。其背景是Google Map加快了发版速度，Cloud Profle还没完全收集好就上新版，导致Cloud Proflie失效。还有一个背景是Jetpack Compose 不是系统代码，因此没有完全编译成机器码，而且Jetpack Compose库比较大，因此在Profile生成之前使用了Jetpack Compose的应用启动会产生性能问题。最后Google为了解决这些问题，创造了收集Profile的BaselineProfileRule Macrobenchmark以及使用Profile的ProfileInstaller。
使用Baseline Profile的机制可以在Android7及以上的手机上得到应用的启动加速，因为从上述知道Android7就已经开始有PGO(Profile-guided optimization)的编译方式。生成的Profile文件会打包到apk里面，并且会结合Google Play的Cloud Profile来引导AOT编译。虽然在国内基本上用不了Cloud Profile，不过Baseline Profile是可以独立于Google Play单独使用的。
image.png
在使用了Baseline Proflie之后，有道词典的启动速度从线上统计上看，冷启动时间有15%的提升。
这篇文章主要介绍了Android Runtime的演进以及对于应用启动的影响，下一篇文章我会详细介绍关于Profile&dex文件优化、Baseline Profile工具库原理，以及在实际 *** 作上如何使用的问题，敬请大家期待一下！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）