虚拟机对于 Dex 文件的解析

以下基于 Android_4.0.4源码进行分析。

先丢一张虚拟机用到的数据结构。我们的起点在

native private static int openDexFile(String sourceName, String outputName, int flags) throws IOException @ DexFile.java

重点 1

重点 2

@DvmDex.cpp

//根据 DexFile 的信息填充 DvmDex

static DvmDex* allocateAuxStructres(DexFile* pDexFile){

DvmDex* pDvmDex

const DexHeader* pHeader

u4 stringCount, classCount, methodCount, fileCount

pDvmDex = (DvmDex*) calloc(1, sizeof(DvmDex))

pDvmDex->pDexFile = pDexFile

pDvmDex->pHeader = pDexFile->pHeader

pHeader = pDvmDex->pHeader

stringCount = pHeader->stringIdsSize

classCount = pHeader->typeIdsSize

methodCount = pHeader->methodIdsSize

filedCount = pHeader->fileIdsSize

//根据实际的数量分配内存

pDvmDex->pResStrings = (struct StringObject ) calloc(stringCount, sizeof(struct stringObject ))

pDvmDex->pResClasses = (struct ClassObject ) calloc(ClassObject, sizeof(struct ClassObject ))

pDvmDex->pResMethods = (struct Method ) calloc(methodCount, sizeof(struct Method ))

pDvmDex->pResFilds = (struct Field ) calloc(fieldCount, sizeof(struct Field ))

...

pDvmDex->pInterfaceCache = dvmAllocAtomicCache(DEX_INTERFACE_CACHE_SIZE)

}

* 从上面看出来,DvmDex 包含 DexFile,DexFile 包含 DexHeader。通过解析 DexHeader，将常量池，方法区，字段等信息在内存的首地址存入 DexFile；然后通过 DexFile 的信息在 DvmDex 中分配合适的内存。于是 Dex 文件便初步解析完成了，并且保存在了内存。在进行类加载的时候，一个类的信息在内存中以 ClassObject 的结构保存。同时在 DexFile 中有一个 ClassLookup* pClassLookup 作为一个哈希表作为缓存保存已经加载了的类。

另外native private static int openDexFile(String sourceName, String outputName, int flags)的返回值是一个 int。明显这个 int 是对应 native 中一个对象的句柄。那么来看 Dalvik_dalvik_system_DexFile_openDexFile()@dalvik_system_DexFile.cpp 中的返回值是 DexOrJar。

于是在 DexFile 中的 cookie 保存的便是这个 DexOrJar 的地址。

https://github.com/Wi1ls/DexParse

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反编译)

Android类加载（一）——DVM、ART、Dexopt、DexAot名词解析

Android类加载（二）——双亲委托机制

Android类加载（三）——源码解读

DVM基于寄存器，JVM基于栈

寄存器是CPU上面的一块存储空间，栈是内存上面的一段连续的存储空间，所以CPU直接访问自己上面的一块空间的数据的效率肯定要大于访问内存上面的数据。基于栈架构的程序在运行时虚拟机需要频繁的从栈上读取或写入数据，这个过程需要更多的指令分派与内存访问次数，会耗费不少CPU时间，对于像手机设备资源有限的设备来说，这是相当大的一笔开销。DVM基于寄存器架构。数据的访问通过寄存器间直接传递，这样的访问方式比基于栈方式要快很多。

执行的字节码文件不一样

DVM执行的是.dex文件，JVM执行的是.class文件。

DVM解释执行的是dex字节码.dex：.java –>.class –>.dex –>.apk

JVM运行的是java字节码.class：.java –>.class –>.jar

本质上java文件编译后都是字节码，只不过JVM运行的是.class字节码，而DVM运行的是.dex字节码

Dalvik：Dalvik是谷歌公司自己设计用于Android平台的Java虚拟机（DVM）。支持已转换为.dex格式的应用程序的运行。.dex格式是专门为DVM设计的一种压缩格式，适合内存和处理器有限的系统，例如Android系统。（DVM负责解释.dex文件为机器码）

ART：Android Runtime，Android4.4中引入的一个开发者选项，也是Android5.0及更高版本的默认模式。在应用安装的时候把字节码预编译成机器语言，这一机制叫做Ahead-Of-Time（AOT）预编译。这样应用程序虽然安装会很慢，但是执行效率将更高，启动更快。

---