[TOC]

文章转自：https://zhuanlan.zhihu.com/p/24305296

概述

动态加载技术（插件化）系列已经坑了有一段时间了，不过UP主我并没有放弃治疗哈，相信在不就的未来就可以看到“系统Api Hook模式”和插件化框架Frontia的更新了。今天要讲的是动态加载技术的亲戚 —— MultiDex。他们的核心原理之一都是dex文件的加载。

MultiDex是Google为了解决“65535方法数超标”以及“INSTALL_FAILED_DEXOPT”问题而开发的一个Support库，具体如何使用MultiDex现在市面已经有一大堆教程（可以参考给 App 启用 MultiDex 功能），这里不再赘述。这篇日志主要是配合源码分析MultiDex的工作原理，以及提供一些MultiDex优化的方案。

Dex的工作机制

在Android中，对Dex文件操作对应的类叫做DexFile。在CLASSLOADER 的工作机制中，我们说到：

对于 Java 程序来说，编写程序就是编写类，运行程序也就是运行类（编译得到的class文件），其中起到关键作用的就是类加载器 ClassLoader。

​ Android程序的每一个Class都是由ClassLoader#loadClass方法加载进内存的，更准确来说，一个ClassLoader实例会有一个或者多个DexFile实例，调用了ClassLoader#loadClass之后，ClassLoader会通过类名，在自己的DexFile数组里面查找有没有那个DexFile对象里面存在这个类，如果都没有就抛ClassNotFound异常。ClassLoader通过调用DexFile的一个叫defineClass的Native方法去加载指定的类，这点与JVM略有不同，后者是直接调用ClassLoader#defineCLass方法，反正最后实际加载类的方法都叫defineClass就没错了?

创建DexFile对象

首先来看看造DexFile对象的构方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public final class DexFile {
    private int mCookie;
    private final String mFileName;
    ...
 
    public DexFile(File file) throws IOException {
        this(file.getPath());
    }
 
    public DexFile(String fileName) throws IOException {
        mCookie = openDexFile(fileName, null, 0);
        mFileName = fileName;
        guard.open("close");
    }
 
    private DexFile(String sourceName, String outputName, int flags) throws IOException {
        mCookie = openDexFile(sourceName, outputName, flags);
        mFileName = sourceName;
        guard.open("close");
    }
 
    static public DexFile loadDex(String sourcePathName, String outputPathName,
        int flags) throws IOException {
        return new DexFile(sourcePathName, outputPathName, flags);
    }
 
    public Class loadClass(String name, ClassLoader loader) {
        String slashName = name.replace('.', '/');
        return loadClassBinaryName(slashName, loader);
    }
 
    public Class loadClassBinaryName(String name, ClassLoader loader) {
        return defineClass(name, loader, mCookie);
    }
    private native static Class defineClass(String name, ClassLoader loader, int cookie);
 
    native private static int openDexFile(String sourceName, String outputName,
        int flags) throws IOException;
 
    native private static int openDexFile(byte[] fileContents)
    ...
}

我们知道ClassLoader主要是通过DexFile.loadDex这个静态方法来创建它需要的DexFile实例的，这里创建DexFile的时候，保存了Dex文件的文件路径mFileName，同时调用了openDexFile的Native方法打开Dex文件并返回了一个mCookie的整型变量（我不知道这个干啥用的，我猜它是一个C++用的资源句柄，用于Native层访问具体的Dex文件）。在Native层的openDexFile方法里，主要做了检查当前创建来的Dex文件是否是有效的Dex文件，还是是一个带有Dex文件的压缩包，还是一个无效的Dex文件。

加载Dex文件里的类

加载类的时候，ClassLoader又是通过DexFile#loadClass这个方法来完成的，这个方法里调用了defineClass这个Native方法，看来DexFile才是加载Class的具体API，加载Dex文件和加载具体Class都是通过Native方法完成，ClassLoader有点名不副实啊。

MultiDex的工作机制

当一个Dex文件太肥的时候（方法数目太多、文件太大），在打包Apk文件的时候就会出问题，就算打包的时候不出问题，在Android 5.0以下设备上安装或运行Apk也会出问题（具体原因可以参考给 App 启用 MultiDex 功能）。既然一个Dex文件不行的话，那就把这个硕大的Dex文件拆分成若干个小的Dex文件，刚好一个ClassLoader可以有多个DexFile，这就是MultiDex的基本设计思路。

工作流程

MultiDex的工作流程具体分为两个部分，一个部分是打包构建Apk的时候，将Dex文件拆分成若干个小的Dex文件，这个Android Studio已经帮我们做了（设置 “multiDexEnabled true”），另一部分就是在启动Apk的时候，同时加载多个Dex文件（具体是加载Dex文件优化后的Odex文件，不过文件名还是.dex），这一部分工作从Android 5.0开始系统已经帮我们做了，但是在Android 5.0以前还是需要通过MultiDex Support库来支持（MultiDex.install(Context)）。

所以我们需要关心的是第二部分，这个过程的简单示意流程图如下。

img
源码分析

现在官方已经部署的MultiDex Support版本是com.android.support:multidex:1.0.1，但是现在仓库的master分支已经有了许多新的提交（其中最明显的区别是加入了FileLock来控制多进程同步问题），所以这里分析的源码都是最新的master分支上的。

MultiDex Support的入口是MultiDex.install(Context)，先从这里入手吧。（这次我把具体的分析都写在代码的注释了，这样看是不是更简洁明了些？）