ART深入浅出(7) - OAT文件的格式
本文基于Android 7.1，不过因为从BSP拿到的版本略有区别，所以本文提到的源码未必与读者找到的源码完全一致。本文在提供源码片断时，将按照 <源码相对android工程的路径>:<行号> <类名> <函数名> 的方式，如果行号对不上，请参考类名和函数名来找到对应的源码。
了解ART的基本运作原理，就需要了解ART编译出的代码是怎么运行的。我们将使用oatdump得到的代码，进行仔细分析。
从简单示例出发
以一个非常简单的函数为例：
frameworks/base/core/java/android/app/Activity.java:988
988 public void onCreate(@Nullable Bundle savedInstanceState,
989 @Nullable PersistableBundle persistentState) {
990 onCreate(savedInstanceState);
991 }这个函数，仅仅是调用了同名的onCreate函数的实现。
编译成oat文件后（存放在boot.oat内），用oatdump出来，我找到对应的dex代码
129: void android.app.Activity.onCreate(android.os.Bundle, android.os.PersistableBundle) (dex_method_idx=2085)
DEX CODE:
0x0000: 6e20 2408 1000 | invoke-virtual {v0, v1}, void android.app.Activity.onCreate(android.os.Bundle) // method@2084
0x0003: 0e00 | return-void这个dex代码看起来也非常简单。
接下来，我们看看编译出的机器码，反汇编后是什么:
QuickMethodFrameInfo
frame_size_in_bytes: 48
core_spill_mask: 0x000040e0 (r5, r6, r7, r14)
fp_spill_mask: 0x00000000
vr_stack_locations:
ins: v0[sp + #52] v1[sp + #56] v2[sp + #60]
method*: v3[sp + #0]
outs: v0[sp + #4] v1[sp + #8]
CODE: (code_offset=0x0337a6d5 size_offset=0x0337a6d0 size=66)...
0x0337a6d4: f5ad5c00 sub r12, sp, #8192
0x0337a6d8: f8dcc000 ldr.w r12, [r12, #0]
StackMap [native_pc=0x337a6dd] (dex_pc=0x0, native_pc_offset=0x8, dex_register_map_offset=0xffffffff, inline_info_offset=0xffffffff, register_mask=0x0, stack_mask=0b000000)
0x0337a6dc: b5e0 push {r5, r6, r7, lr}
0x0337a6de: b088 sub sp, sp, #32
0x0337a6e0: 9000 str r0, [sp, #0]
0x0337a6e2: f8b9c000 ldrh.w r12, [r9, #0] ; state_and_flags
0x0337a6e6: f1bc0f00 cmp.w r12, #0
0x0337a6ea: d10a bne +20 (0x0337a702)
0x0337a6ec: 461d mov r5, r3
0x0337a6ee: 460e mov r6, r1
0x0337a6f0: 4617 mov r7, r2
0x0337a6f2: 6808 ldr r0, [r1, #0]
0x0337a6f4: f8d004c8 ldr.w r0, [r0, #1224]
0x0337a6f8: f8d0e020 ldr.w lr, [r0, #32]
0x0337a6fc: 47f0 blx lr
StackMap [native_pc=0x337a6ff] (dex_pc=0x0, native_pc_offset=0x2a, dex_register_map_offset=0x0, inline_info_offset=0xffffffff, register_mask=0xe0, stack_mask=0b000000)
v0: in register (6) [entry 0]
v1: in register (7) [entry 1]
v2: in register (5) [entry 2]
0x0337a6fe: b008 add sp, sp, #32
0x0337a700: bde0 pop {r5, r6, r7, pc}
0x0337a702: 9103 str r1, [sp, #12]
0x0337a704: 9204 str r2, [sp, #16]
0x0337a706: 9305 str r3, [sp, #20]
0x0337a708: f8d9e2a8 ldr.w lr, [r9, #680] ; pTestSuspend
0x0337a70c: 47f0 blx lr
StackMap [native_pc=0x337a70f] (dex_pc=0x0, native_pc_offset=0x3a, dex_register_map_offset=0x3, inline_info_offset=0xffffffff, register_mask=0x0, stack_mask=0b111000)
v0: in stack (12) [entry 3]
v1: in stack (16) [entry 4]
v2: in stack (20) [entry 5]
0x0337a70e: 9903 ldr r1, [sp, #12]
0x0337a710: 9a04 ldr r2, [sp, #16]
0x0337a712: 9b05 ldr r3, [sp, #20]
0x0337a714: e7ea b -44 (0x0337a6ec)
这个代码很长，你也许会奇怪，为什么简单的一句源码，会产生如此多的机器码呢？下面我为大家分段解析。
解析时，请大家注意对照我说的部分
QuickMethodFrameInfo
首先，看到的”QuickMethodFrameInfo”部分，定义了相关代码的信息，包含：frame_size_in_bytes： 这个信息指出堆栈的大小。该例子中的值是48。下面的机器码中(0x0337a6dc-0x0337a6de)，我们可以看到push指令和sub指令正好占用了堆栈的48字节。
core_spill_mask： 需要保存的寄存器值。这个值是0x000040e0，对应的就是0x337a6dc的 push {r5, r6, r7, lr} (lr即r14)。
vr_stack_locations: 则定义了dex寄存器在堆栈上的位置。
Code部分
接下来，CODE部分，包含了所有相关的代码。CODE部分包括5部分：
1. 堆栈检测部分：0x0337a6d4-0x337a6d8，检测现在的堆栈是否溢出的，否则将会产生一个堆栈溢出的错误
2. 程序头部分：0x0337a6dc-0x0337a6f0, 主要是保护现场，保存参数，检查停止点等
3. 程序正文部分：0x0337a6f2-0x0337a6fc，dex字节码的实现部分
4. 程序结尾部分：0x0337a6fe-0x0337a700 负责恢复现场，然后返回
5. 执行检查点部分：0x0337a702-0x0337a714: 调用检查点，执行一些任务，比如GC等等。
这些部分，包含了一个程序大部分组成。
第一部分的堆栈检测比较简单，我们不详细说了，从第二部分开始。
程序头部分
这一部分的代码
0x0337a6dc: b5e0 push {r5, r6, r7, lr}
0x0337a6de: b088 sub sp, sp, #32
0x0337a6e0: 9000 str r0, [sp, #0]
0x0337a6e2: f8b9c000 ldrh.w r12, [r9, #0] ; state_and_flags
0x0337a6e6: f1bc0f00 cmp.w r12, #0
0x0337a6ea: d10a bne +20 (0x0337a702)
0x0337a6ec: 461d mov r5, r3
0x0337a6ee: 460e mov r6, r1
0x0337a6f0: 4617 mov r7, r2需要注意的是，在ART里面，参数传递是使用r0~r3 (ARM架构），这一点与标准的C stdcall是一样的。不过，r0是被固定为参数ArtMethod*，即目前被调用函数的指针，如果是非static函数，那么r1则是this指针，否则r1就是第一个参数。依次是java函数中声明的其他参数。
如果参数超过了寄存器的数目，则用堆栈传递。关于堆栈传递参数的方法，我们会在后面章节中详细说明。
这里看到，前两条语句是保存寄存器并分配堆栈。第3条语句(0x0337a6e0) 将r0(ArtMethod*)的值放在了栈顶。这是ART的规范要求，所有的java method，必须在堆栈上放入它的函数指针，这样在遍历栈的时候，ART就知道这个栈归属哪个函数。
第4～6句 (0x0337a6e2-0x0337a6ea) 是读取 Thread对象的state_and_flags成员，判断是否有检查点，如果有则转到检查点来执行。
r9参数总是放的当前线程的Thread对象指针。
第7句以后，则是保存参数到寄存器中，以便后面使用（实际上并没有使用，这说明ART的编译器还存在优化的空间）。
调用部分
要调用一个函数，ART必须做的事情是：1. 得到这个函数的入口地址；2. 准备参数；3. 调用
0x0337a6f2: 6808 ldr r0, [r1, #0]
0x0337a6f4: f8d004c8 ldr.w r0, [r0, #1224]
0x0337a6f8: f8d0e020 ldr.w lr, [r0, #32]
0x0337a6fc: 47f0 blx lr在这里，r1是this指针，第0x0337a6f2是取得this的class对象，放到r0，然后从r0中取得被调用的onCreate函数的ArtMethod*指针，再保存到r0中。第三步是从ArtMethod中取得入口地址（放在32偏移处），最后调用。
onCreate(Bundle) 函数需要3个参数：
r0: 指向onCreate(Bundle)的ArtMethod*;
r1: this指针
r2: Bundle对象指针。
我们看到，ART巧妙的将ArtMethod的值取到R0后，就把它作为参数来使用。而r1,r2的值自进入函数后就没有被改变，所以就直接使用了。
最后一步调用blx跳转到函数入口。 blx指令是跳转到寄存器指定的地址，同时把下条指令的地址放入到lr寄存器，方便函数调用后返回。
程序结束部分
这部分很简单，就是恢复堆栈和寄存器。
因为这个函数没有返回值，所以这里省略了返回值的处理。正常情况下，返回值是放在r0,r1寄存器内的。
检查点调用部分
检查点是ART内一个非常重要的功能，ART依靠检查点来实现GC、异常处理等一系列关键功能。
ART为每个线程都分配了一个Thread对象，这个对象中有一个pTestSuspend入口，这个入口就是用来执行检查点函数调用的。
0x0337a702: 9103 str r1, [sp, #12]
0x0337a704: 9204 str r2, [sp, #16]
0x0337a706: 9305 str r3, [sp, #20]
0x0337a708: f8d9e2a8 ldr.w lr, [r9, #680] ; pTestSuspend
0x0337a70c: 47f0 blx lr
0x0337a70e: 9903 ldr r1, [sp, #12]
0x0337a710: 9a04 ldr r2, [sp, #16]
0x0337a712: 9b05 ldr r3, [sp, #20]
0x0337a714: e7ea b -44 (0x0337a6ec)这段代码从0x0337a702-0x0337a712 是调用pTestSuspend入口的，调用入口不需要参数，所以前面它保存了r1, r2, r3三个参数，调用后又恢复了r1,r2,r3参数。至于要保存那些参数，根据实际情况定。
在最后一条语句，则是返回到调用现场，继续运行。这里它没有使用blx这样的调用，而是直接用b指令，目的应该是为了尽量减少寄存器的使用。
了解dex各类指令以及异常的实现方法
接下来，我们了解下各类dex指令的实现。这些指令的实现都和class、object、method、field的实现结构密切相关，但是，在我们具体了解这些结构的具体内容之前，我们先了解下ART是怎样使用它们的，就更容易理解这些结构为什么被设计成那种样子。
上文提到了invoke的实现，这里我们就不再解释
dex指令的实现
const-string
boot内的字符串查找
dex代码：
0x001e: 1b02 5501 0000 | const-string/jumbo v2, " doesn't implement Cloneable" // string@341对应的机器码反汇编后是
0x02d7a184: 4a1f ldr r2, [pc, #124] ; 0x6fbf9ef0
0x02d7a186: 4601 mov r1, r0
0x02d7a188: 4607 mov r7, r0
0x02d7a18a: 4690 mov r8, r2
0x02d7a18c: 6808 ldr r0, [r1, #0] 其中0x02d7a184就是加载字符串地址的代码。可以看到，读取pc偏移124的值（0x6fbf93f0) 即时字符串对象的地址。
pc + 124得到的值是 0x2D7A202 , 让他对齐到4字节后，就是地址 0x2D7A204:
0x02d7a204: 9ef0 ldr r6, [sp, #960]
0x02d7a206: 6fbf ldr r7, [r7, #120] 注意这里0x2d7a204位置不是代码，而是数据，但是反汇编器没有识别，仍旧当作代码来解析。我们看到，204处是9ef0, 206处是6fbf，合在一起，正是一个4字节地址：0x6fbf93f0 (因为arm是小端）。
这个地址是一个绝对地址，它实际指向的是boot.art映射的内存。我摘取的代码来自boot.oat。因为art会把boot.art加载到一个固定地址，所以，这里的代码可以这样处理。
另外需要注意的是，这里得到的地址，并不是字符串的地址，而是java String对象的地址。因为C语言里面的字符串是字符数组，是无法让java语言处理的。
应用的字符串查找方法
如果是应用程序的oat文件，没有对应的art映射文件，应该如何处理呢？
实际上，ART是通过bss段的数据来实现的。
为了说明这个问题，我们下载一个应用的oat看看。
adb pull /data/dalvik-cache/arm/system@app@Bluetooth@Bluetooth.apk@classes.dex
oatdump --oat-file=system@app@Bluetooth@Bluetooth.apk@classes.dex > bluetooth.txt首先，我用readelf -a system@app@Bluetooth@Bluetooth.apk@classes.dex 看看这个文件的结构（只摘抄关键的部分）：
节头：
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
.....
[ 3] .bss NOBITS 00f0b000 000000 06b354 00 A 0 0 4096
....
Symbol table '.dynsym' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00001000 0x8f3000 OBJECT GLOBAL DEFAULT 1 oatdata
2: 008f4000 0x6165a0 OBJECT GLOBAL DEFAULT 2 oatexec
3: 00f0a59c 4 OBJECT GLOBAL DEFAULT 2 oatlastword
4: 00f0b000 0x6b354 OBJECT GLOBAL DEFAULT 3 oatbss
5: 00f76350 4 OBJECT GLOBAL DEFAULT 3 oatbsslastword请注意下，“节头”中第3条 .bss，起始位置是 00f0b000，大小是06354， 对应”Symbol table ‘.dynsym’ 中的第4条，即“oatbss”部分。
bss段是用来指定没有初始值的全局和静态变量的，在文件中没有分配空间，但是加载到内存中时，需要分配空间。程序启动时，系统会自动清零。
oatbss段，就被ART用来存放各种全局变量和静态变量，其中就包括这些常量字符串对象。
经过计算，oatbss的范围是 0x00f0b000-0x00f76354 (最后4字节即时oatbsslastword)
下面，我们在看看一个加载的例子。首先，看一下dex的写法：
0x0005: 1b08 e74f 0000 | const-string/jumbo v8, "Ra" // string@20455这条指令，是加载dex文件中，索引为20455的字符串。
的对应的汇编代码：
0x008f4366: f6456086 movw r0, #24198
0x008f436a: f2c00065 movt r0, #101
0x008f436e: 4478 add r0, pc
0x008f4370: 900b str r0, [sp, #44]
0x008f4372: 6802 ldr r2, [r0, #0]
0x008f4374: 2a00 cmp r2, #0
0x008f4376: f00081f8 beq.w +1008 (0x008f476a)
0x008f437a: 9206 str r2, [sp, #24]movw是将立即数放入寄存器低16位，movt是放入到高16位。故此，前两条语句，使 r0的值为 0x655e86。
第三条语句含义为r0 = r0 + pc，此时pc的值0x008f4372, 这时，r0的值为 0xF4A1F8。该值正好在 0x00f0b000-0x00f76354 范围内，即是oatbss内部的内容。所以，这是取一个静态的字符串对象的地址。
第6，7条指令(cmp r2, #0; beq.w +1008 ) 则是判断对象是否初始化，没有初始化，就去加载这个字符串。加载字符串的地址是 0x008f476a:
0x008f476a: 900e str r0, [sp, #56]
0x008f476c: f64470e7 movw r0, #20455
0x008f4770: f8d9e154 ldr.w lr, [r9, #340] ; pResolveString
0x008f4774: 47f0 blx lr
0x008f4776: 4602 mov r2, r0
0x008f4778: 980e ldr r0, [sp, #56]
0x008f477a: e5fe b -1028 (0x008f437a) 首先，ART保存了r0寄存器（因为r0要作为参数和返回值），然后从pThread (r9) 中取得pResolveString的地址，然后调用。得到的结果，保存在r2中，然后恢复r0值，在跳转到回去，继续执行。
ART为了避免寄存器被污染，所以为每次加载字符串的地方都生成了这种辅助代码。
const-class
根据各种情况，可以分为多种实现
method 加载本身所在类
ArtMethod第一个成员就是declaring_class, 因此这种情况下，直接从ArtMethod指针中获取就可以。比如下面的例子
5: java.lang.Object java.text.AttributedCharacterIterator$Attribute.readResolve() (dex_method_idx=9453)
DEX CODE:
....
0x0004: 1c02 8c03 | const-class v2, java.text.AttributedCharacterIterator$Attribute // type@908 要加载的就是method所在的类
对应的机器码是
CODE: (code_offset=0x02d7c6dd size_offset=0x02d7c6d8 size=240)...
...
0x02d7c6e4: e92d45e0 push {r5, r6, r7, r8, r10, lr}
0x02d7c6e8: b086 sub sp, sp, #24
0x02d7c6ea: 9000 str r0, [sp, #0]
0x02d7c6ec: f8b9c000 ldrh.w r12, [r9, #0] ; state_and_flags
0x02d7c6f0: f1bc0f00 cmp.w r12, #0
0x02d7c6f4: d158 bne +176 (0x02d7c7a8)
0x02d7c6f6: 4605 mov r5, r0
...
0x02d7c706: 682f ldr r7, [r5, #0]
0x02d7c708: 42b8 cmp r0, r7 我保留了入口部分的代码，可以看到，r0是入参，ArtMethod指针，首先r0被保存到r5，然后，取r5 + 0偏移位置的值(即delcaring_class_)，就获得了class的地址。
其他情况下取得class的方法
如果要取得一个和当前method没有任何关系的class，就要用到ArtMethod中一个非常重要的成员： dex_cache_resolved_types_ 中。在arm平台，它的偏移是24
比如，下面的例子：
0x0010: 1c02 e400 | const-class v2, java.lang.Enum // type@228java.lang.Enum类与当前的method没有任何关联，它的获取是通过
art_method->dex_cache_resolved_types_[228] 获取的。下面的代码如下：（请注意注释)
0x02da522a: 69b9 ldr r1, [r7, #24] //r7 是ArtMethod指针，即当前函数, 将 r1 = art_method->dex_cache_resolved_types_
0x02da522c: f8d11390 ldr.w r1, [r1, #912] //取 r1[912]。 912 = 228 * 4
0x02da5230: 9104 str r1, [sp, #16]
0x02da5232: 4288 cmp r0, r1
一个class地址占用4字节（即使是64位的架构，class也是占用4字节），所以228 * 4 = 912，即是 偏移地址。
需要注意的是，上面例子，我给出的是java.lang.Enum，这是一个基础类，所以可以认为这个类一定是被解析过的，可以直接使用的，如果加载一个任意类，那么ART就不能保证这个类一定被解析过，所以需要检查一下，如果没有加载，就会先去加载。比如下面的例子
0x008c: 1c08 5001 | const-class v8, android.net.dhcp.DhcpPacket$ParseException // type@336对应的机器码：
0x00904da4: f8db1018 ldr.w r1, [r11, #24]
0x00904da8: f8d11540 ldr.w r1, [r1, #1344]
0x00904dac: 2900 cmp r1, #0
0x00904dae: f0008165 beq.w +714 (0x0090507c)
0x00904db2: 9105 str r1, [sp, #20]这里，r11是ArtMethod*指针。取得对象后，会检测一下是否为空(0)，如果为空，就会跳转到 0x0090507c：
0x0090507c: f44f70a8 mov.w r0, #336
0x00905080: f8d9e150 ldr.w lr, [r9, #336] ; pInitializeType
0x00905084: 47f0 blx lr
0x00905086: 4601 mov r1, r0
0x00905088: e693 b -730 (0x00904db2)这里，r9就是pThread指针，调用pInitiliazeType函数，参数是class的索引：336。初始化成功后，就再跳回去继续执行。
new-instance
在dex中，new一个对象，被分拆成两个指令：new-instance和invoke-direct。即先创建对象，然后在调用构造函数。我们重点关注的是创建对象
例如
0x0006: 2200 6d01 | new-instance v0, android.net.metrics.IpConnectivityLog // type@365 0x00905fe4: 9900 ldr r1, [sp, #0]
0x00905fe6: f240106d movw r0, #365
0x00905fea: f8d9e11c ldr.w lr, [r9, #284] ; pAllocObject
0x00905fee: 47f0 blx lrr9是pThread指针，调用pThread->pAllocObject。其中，参数r0是class的index, 参数r1是调用者的ArtMethod。
因为ArtMethod中包含很多信息，所以这个信息是很重要的。
基本上所有的实现都是这样的。
get/put instance field
ART会将所有的field转换为它们在object中的偏移，所以field的存取相对简单很多。
iget
比如：
0x0018: 5432 6b01 | iget-object v2, v3, Landroid/net/DhcpResults; android.net.dhcp.DhcpClient.mDhcpLease // field@363它的含义是 v2 = v3.mDhcpLease。
对应的实现
0x00906872: 6b2a ldr r2, [r5, #48]
0x00906874: 9207 str r2, [sp, #28]r5 即对应的v3寄存器对象，#48就是field mDhcpLease在v3中的偏移。v2对应的sp + 28的位置（因为寄存器不够用了），所以，它先被加载到r2寄存器，然后再存入到sp上。
之所以用r2寄存器，是因为r2寄存器马上要作为参数传递给即将调用的函数。这是ART一个优化措施。
iput
iput的实现与iget的实现非常类似，查找field的方法都是一样的。但是iput-object有一个不同的地方：iput-object要同步card-table。
card-table是一个GC相关的数据。简单来说，card-table是记录object引用关系的。
iput-object会导致对象的引用关系发生变化，这时，ART就要更新对应的card-table，让GC能够知道那块内存变脏了，需要重新查找。
直接看机器码：
0x00906c52: 65fe str r6, [r7, #92]
0x00906c54: f8d90080 ldr.w r0, [r9, #128] ; card_table
0x00906c58: 09f9 lsrs r1, r7, #7
0x00906c5a: 5440 strb r0, [r0, r1]第一条指令就是实现iput-object的： r7.field = r6。92就是field的offset
剩下的语句，翻译成c伪代码就是:
card_table = pThread->card_table;
card_table[r7 >> 7] = card_table&0xff;ART中，card_table不是位，而是以字节为单位管理一块内存，一个字节对应128字节的数据，所以r7 >> 7 后就能得到它的索引。如果对应内存脏了，那么对应的字节就会设置为一个特定值。
这个特定值正好是card_table地址的最低字节。
ART这样设计自然是为了效率。
get/put static field
sget, sput的实现与iget, iput非常类似，只是object需要换成class的指针。ART的class对象后面同样放置了static field的值，而且是sget,sput都直接使用偏移来访问。同样的sput-object指令也会更新card-table，方法也是一样的。有兴趣的读者可以自己查阅。