浅谈 Android Dex 文件
概述
为什么要了解 Dex 文件
了解了 Dex 文件以后，对日常开发中遇到一些问题能有更深的理解。如：APK 的瘦身、热修复、插件化、应用加固、Android 逆向工程、64 K 方法数限制。
什么是 Dex 文件
在明白什么是 Dex 文件之前，要先了解一下 JVM，Dalvik 和 ART。JVM 是 JAVA 虚拟机，用来运行 JAVA 字节码程序。Dalvik 是 Google 设计的用于 Android平台的运行时环境，适合移动环境下内存和处理器速度有限的系统。ART 即 Android Runtime，是 Google 为了替换 Dalvik 设计的新 Android 运行时环境，在Android 4.4推出。ART 比 Dalvik 的性能更好。Android 程序一般使用 Java 语言开发，但是 Dalvik 虚拟机并不支持直接执行 JAVA 字节码，所以会对编译生成的 .class 文件进行翻译、重构、解释、压缩等处理，这个处理过程是由 dx 进行处理，处理完成后生成的产物会以 .dex 结尾，称为 Dex 文件。Dex 文件格式是专为 Dalvik 设计的一种压缩格式。所以可以简单的理解为：Dex 文件是很多 .class 文件处理后的产物，最终可以在 Android 运行时环境执行。
Dex 文件是怎么生成的
java 代码转化为 dex 文件的流程如图所示，当然真的处理流程不会这么简单，这里只是一个形象的显示：
注：图片来源于网络
现在来通过一个简单的例子实现 java 代码到 dex 文件的转化。
从 .java 到 .class
先来创建一个 Hello.java 文件，为了便于分析，这里写一些简单的代码。代码如下：
在该文件的同级目录下面使用 JDK 的 javac 编译这个 java 文件。
javac 命令执行后会在当前目录生成 Hello.class 文件，Hello.class 文件已经可以直接在 JVM 虚拟机上直接执行。这里使用使用命令执行该文件。
执行后应该会在控制台打印出“hello! youzan”
这里也可以对 Hello.class 文件执行 javap 命令，进行反汇编。
执行结果如下：
其中 Code 之后都是具体的指令，供 JVM 虚拟机执行。指令的具体含义可以参考 JAVA 官方文档。
从 .class 到 .dex
上面生成的 .class 文件虽然已经可以在 JVM 环境中运行，但是如果要在 Android 运行时环境中执行还需要特殊的处理，那就是 dx 处理，它会对 .class 文件进行翻译、重构、解释、压缩等操作。
dx 处理会使用到一个工具 dx.jar，这个文件位于 SDK 中，具体的目录大致为 你的SDK根目录/build-tools/任意版本 里面。使用 dx 工具处理上面生成的Hello.class 文件，在 Hello.class 的目录下使用下面的命令：
执行完成后，会在当前目录下生成一个 Hello.dex 文件。这个 .dex 文件就可以直接在 Android 运行时环境执行，一般可以通过 PathClassLoader 去加载 dex 文件。现在在当前目录下执行 dexdump 命名来反编译：
执行结果如下（部分区域的含义已经在下面描述）：
到此为止，已经完成了将 Java 代码转变成 Dalvik 可执行的文件，即 dex。
Dex 文件的具体格式
现在来分析一下 Dex 文件的具体格式，就像 MP3，MP4，JPG，PNG 文件一样，Dex 文件也有它自己的格式，只有遵守了这些格式，才能被 Android 运行时环境正确识别。
Dex 文件整体布局如下图所示：
这些区域的数据互相关联，互相引用。由于篇幅原因，这里只是显示部分区域的关联，完整的请去官网自行查看相关数据整理。下图中的各字段都在后面的各区域的详细介绍中有具体介绍。
下面将分别对文件头、索引区、类定义区域进行简单的介绍。其它区域可以去 Android 官网了解。
文件头
文件头区域决定了该怎样来读取这个文件。具体的格式如下表(在文件中排列的顺序就是下面表格中的顺序)：
id 区
id 区存储着字符串，type，prototype，field， method 资源的真正数据在文件中的偏移量，我们可以根据 id 区的偏移量去找到该 id 对应的真实数据。
字符串 id 区域
这个区块是一个偏移量列表，每个偏移量对应了一个真正的字符串资源，每个偏移量占32位。我们可以通过偏移量找到对应的实际字符串数据。具体格式如下：
最终这个偏移的位置应该是落在数据区的。找到这个偏移量的位置后，根据下面的格式就可以读取出这个字符串资源的具体数据：
类型 id 区
这个区块是一个索引列表，索引的值对应字符串id区域偏移量列表中的某一项。数据格式如下：
如果我们要找到某个类型的值，需要先根据类型id列表中的索引值去字符串id列表中找到对应的项，这一项存储的偏移量对应的字符串资源就是这个类型的字符串描述。
方法原型 id 区
这个区块是一个方法原型 id 列表，数据格式为：
成员 id 区
这个区块存储着原型 id 列表，数据格式为：
方法 id 区
这个区块存储着方法 id 列表，数据格式为： 这个区块存储着原型 id 列表，数据格式为：
类定义区
这个区域存储的是类定义的列表，具体的数据结构如下：
解析 dex 文件的工具
这里推荐一个可以解析 dex 文件的工具 010 Editor。它可以通过预置的模板让我们更清晰的了解 dex 文件的格式。
Dex 文件在 Android Tinker 热修复中的应用
在目前的主流的 Android 热修复方案中，Tinker有免费、开源、用户量大等优点，因此在有赞也是基于 Tinker 搭建 Android 热修复服务。Tinker 热修复的主要原理就是通过对比旧 APK 的 dex 文件与新 APK 的 dex 文件，生成补丁包，然后在 APP 中通过补丁包与旧 APK 的 dex 文件合成新的 dex 文件。流程如下图所示：
注：图片来源于 Tinker 官网
补丁包的生成
Tinker 官方使用自研一套合成方案，就是 DexDiff。它基于 Dex文件格式的特性，具有补丁包小，消耗内存小等优点。在 DexDiff 算法中，会根据 Dex文件的格式，将 Dex 文件划分为不同的区块类，如下图：
这些区块有一个统一的数据结构，主要的数据有区块对应的实际数据类型及在文件中的偏移量。如下图：
有了区块数据中的实际数据类型与偏移量，再根据实际数据类型对应的数据结构就可以从文件中读出这个区块包含的实际数据。这里以 header 区域为例，读取代码如下(删除了部分无关代码，代码可以参照上面的 Dex 文件格式的文件头的介绍)：
从文件中读取到新旧 Dex 文件各区块的具体的数据后，就可以进行对比生成补丁包了。因为各区块的数据结构不一致，因此各区块有着相应的 diff 算法来处理各区块补丁生成与合成。算法列表如图：
这些算法会对比新旧 Dex 文件转化成数据结构以后数据的差异，然后生成相关的操作指令，存储到补丁文件，下发到客户端。
补丁的合成
客户端收到补丁文件后，会使用相同的读取方式，将旧 Dex 文件转换为相关的数据结构，然后使用补丁包中的操作指令，对旧 Dex 数据进行修改，生成新 Dex 数据，最后数据写入文件，生成新 Dex 文件，这样就完成了补丁的合成。
写在最后
本文并没有写什么特别深入的东西，对 dex 的文件格式也没有完全描述完全。主要是给大家分享一个 dex 文件的大致结构，还有一些在实际中的应用。让大家在以后遇到相关问题的时候，可以有一些方向去了解 dex 文件，然后解决问题。最后，如果大家有任何的建议或意见，欢迎反馈。
参考资源
Last updated