ART、OAT格式介绍与dex文件提取

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_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是应用安装时生成的虚拟机可执行二进制文件，察中如果应用还存在，删除了下次手机开机时还会再次生成，卸载软件时会同时删除dex文件。所以没有必要手动删除dex文件。

对于Android DEX文件进行优化，需要乱亩注意的一点是DEX文件的结构是紧凑的，但是我们还是要想方设法的进行提高程序的运行速度，我们就仍然需要对DEX文件进行进一步优化。

调整所有字段的字节序（LITTLE_ENDIAN）和对齐结构中的每一个域 验证DEX文件中的所有类 对一些特定的类进行优化，对方法里的 *** 作码进行优化 。优化后的文件大小会有所增加，应该是原Android DEX文件的1-4倍。 优化发生的时机有两败陪山个：对于预置应用，可以在系统编译后，生成优化文件，以ODEX结尾。

这样在发布时除APK文件（不包含DEX）以外，还有一个相应的Android DEX文件；对于非预置应用，包含在APK文件里的DEX文件会在运行时被优化，优化后的文件将被保存在缓存中。

每一个Android应用都运行在一个Dalvik虚拟机实例里，而每一个虚拟机实例都是一个独立的进程空间。虚拟机的线程机制，内存分配和管理，Mutex等等都是依赖底层 *** 作系统而实现的。

---