Android MultiDex 分包及加载原理

Problem

日常开发中，一旦项目变的庞大起来，很容易遇到如下的编译错误：

trouble writing output:
Too many field references: 131000; max is 65536.
You may try using --multi-dex option.

//低版本编译会遇到类似这种
Conversion to Dalvik format failed:
Unable to execute dex: method ID not in [0, 0xffff]: 65536

错误信息也很明确，表示单个Dex文件内可以包含的方法引用数不能超过65536，正好是2的16次方64Kb，有时候也叫“64K引用限制”。

如何规避

遇到以上问题，第一反应当然是精简代码：

• 检查应用的直接和传递依赖项：简单说就是一个类能解决的问题不要引入一个库，这种也是日常开发中最常见的，很多时候我们为了用到某一个轮子，而引入了一整辆马车。这种可以通过精简一些第三方库、support包等。
• 通过代码压缩、移除未使用的代码：很多代码年久失修，其实可以重构或者删除掉。

即使如此，上述策略还是无法彻底解决64K引用的问题，官方提供了将一个Dex拆分为多个Dex的库来越过这一限制，这就是MultiDex。

引入MultiDex

MultiDex可以理解为一个工具集，一方面在编译打包时将你的代码从之前的生成一个Classes.dex 变为生成Classes.dex、Classes1.dex…ClassesN.dex多个Dex文件；另一方面它也提供了应用运行时对这多个Dex的加载。

Android 5.0之前版本支持多Dex

Android5.0之前编译版本要支持编译时对Dex进行分包，需要如下配置：

android {
	defaultConfig {
		...
		minSdkVersion 15
		targetSdkVersion 28
		//启用多Dex
		multiDexEnabled true
	}
	...
}
dependencies {
  implementation 'com.android.support:multidex:1.0.3'
}

Android 5.0之前使用Dalvik执行应用代码，默认情况下，Dalvik限制每个APK只能使用一个Classes.dex，所以要支持运行时多Dex加载，需要配置当前Application类，要么继承MultiDexApplication，要么在当前Application中调用如下方法:

@Override
protected void attachBaseContext(Context base) {
	super.attachBaseContext(base);
	//运行时多Dex加载， 继承MultiDexApplication最终也是调用这个方法
	MultiDex.install(this);
}

Android 5.0之后版本支持多Dex

Android 5.0之后的版本使用ART运行时，它本身支持从APK文件中加载多个Dex文件。并且ART在应用安装时执行预编译，会扫描所有的ClassesN.dex， 统一优化为.oat文件。并且编译时如果minSdkVersion>=21, 则默认情况下支持分包，不需要引入上述support库。

综上，Android 5.0之前需要引入对应的support库来支持编译时分包和运行时加载多Dex，而Android 5.0之后由于使用ART虚拟机，运行时本身支持加载多Dex，minSdkVersion >=21 编译期也本身支持分包，因此不必引入相关配置。

MultiDex 分包原理

引入 multiDexEnabledtrue 之后，就可以支持打包生成多个Dex文件，因此，这一过程肯定是在编译期间发生，从官方的打包流程图也可以看出，最终是通过dex工具将class文件转换为Dex文件，

dx实际上是个脚本，其执行对应的jar包路径为 /sdk/build-tools/27.0.x/lib/dx.jar ，我们可以将其导入AndroidStudio，分析其源码：

//找到对应的入口类
//com.android.dx.command.Main.java
public class Main {
	public static void main(String[] args) {
		//读取入参args
		if (arg.equals("--dex")) {
			com.android.dx.command.dexer.Main.main(without(args, i));
			break;
		}
		...
	}
}

//com.android.dx.command.dexer.Main.java
public static void main(String[] argArray) throws IOException {
	DxContext context = new DxContext();
	//封装入参, Arguments构造函数中指定了maxNumberOfIdxPerDex=65536
	Main.Arguments arguments = new Main.Arguments(context);
	arguments.parse(argArray);
	//执行
	int result = (new Main(context)).runDx(arguments);
	if (result != 0) {
		System.exit(result);
	}
}

public int runDx(Main.Arguments arguments) throws IOException {
	//一堆分装参数，初始化IO逻辑
	...
    int var3;
    try {
		 //gradle中enable MultiDex
        if (this.args.multiDex) {
            var3 = this.runMultiDex();
            return var3;
        }
        var3 = this.runMonoDex();
    } finally {
        this.closeOutput(humanOutRaw);
    }
    return var3;
}


private int runMultiDex() throws IOException {
	assert !this.args.incremental;
	//看来是去读一个关键文件 mainDexListFile(主Dex相关)
   if (this.args.mainDexListFile != null) {
		// 保存主Dex中需要打包的Classes
       this.classesInMainDex = new HashSet();
		// 从mainDexListFile中读取需要打包在MainDex中的类并保存
      readPathsFromFile(this.args.mainDexListFile, this.classesInMainDex);
    }
	
	//起一个线程池
    this.dexOutPool =Executors.newFixedThreadPool(this.args.numThreads);
    if (!this.processAllFiles()) {
        return 1;
    } else if (!this.libraryDexBuffers.isEmpty()) {
        throw new DexException("Library dex files are not supported in multi-dex mode");
    } else {
			//提交对应任务，通过DexWriter将Class转化为Dex文件
        if (this.outputDex != null) {
            this.dexOutputFutures.add(this.dexOutPool.submit(new Main.DexWriter(this.outputDex)));
            this.outputDex = null;
        }
		 //
        if (this.args.jarOutput) {
           ...
        } else if (this.args.outName != null) {
            File outDir = new File(this.args.outName);
            assert outDir.isDirectory();
            for(int i = 0; i < this.dexOutputArrays.size(); ++i) {
				//getDexFileName(i)==>i  == 0 ? "classes.dex" : "classes" + (i + 1) + ".dex";
            FileOutputStream out = new FileOutputStream(new File(outDir, getDexFileName(i)));
             try {
                  out.write((byte[])this.dexOutputArrays.get(i));
              } finally {
                  this.closeOutput(out);
              }
           }
        }
        return 0;
    }
}
//每个提交的任务中对Class进行单独处理，包括进行校验方法引用数等，这里篇幅有限，不再深入，感兴趣的同学自行研究

上面提到的MainDex中的类主要是由mainDexListFile指定的，而mainDexListFile的生成是通过SDK中的mainDexClasses、mainDexClasses.rules、mainDexClassesNoAapt.rules等相关脚本生成，具体逻辑可以自行研究。

总结一下， MultiDex的分包是在编译期借助dx和mainDexClasses等脚本，确定主Dex（仅包含入口类和引用类）和其他Dex的具体字节码组成，并且生成对应文件的过程，篇幅所限，后续可对照相关源码深入研究。

MultiDex 加载原理

如果对Android ClassLoader比较熟悉的话，其实多Dex加载的原理也比较简单，后续的插件化和热修复也用到了类似思想，以下是源码的一些关键路径分析：

//MultiDex.java
public static void install(Context context) {
	//通过context拿到当前application信息
	...
	//sourceDir: data/app/com..xxxx/base.apk
	//dataDir: data/data/com.xxxx
	doInstallation(context,
		new File(applicationInfo.sourceDir),
		new File(applicationInfo.dataDir),
		CODE_CACHE_SECONDARY_FOLDER_NAME,
		NO_KEY_PREFIX,
		true);
}

private static void doInstallation(...) {
	...
	//拿到当前application对应Classloader
	ClassLoader loader = mainContext.getClassLoader(); //PathClassLoader
	//ClassesN.dex对应释放路径
	File dexDir = getDexDir(mainContext, dataDir, secondaryFolderName);
	//将目录下的base.apk解压提取classesN.dex，源码后续分析
	MultiDexExtractor extractor = new MultiDexExtractor(sourceApk, dexDir);	
	IOException closeException = null;
	try {
		List<? extends File> files =
			extractor.load(mainContext, prefsKeyPrefix, false);
		try {
			//重点代码
			installSecondaryDexes(loader, dexDir, files);
			//容错 Some IOException causes may be fixed by a clean extraction.
			} catch (IOException e) {
				if (!reinstallOnPatchRecoverableException) {
					throw e;
				}
				files = extractor.load(mainContext, prefsKeyPrefix, true);
				installSecondaryDexes(loader, dexDir, files);
			}
		} finally {
			...
		}
}

//
private static void installSecondaryDexes(ClassLoader loader, File dexDir,List<? extends File> files) {
	if (!files.isEmpty()) {
		if (Build.VERSION.SDK_INT >= 19) {
			V19.install(loader, files, dexDir);
		} else if (Build.VERSION.SDK_INT >= 14) {
			V14.install(loader, files);
		} else {
			V4.install(loader, files);
		}
	}
}

//以V19为例
private static final class V19 {
	static void install(ClassLoader loader..) {
		//获取当前ClassLoader 的pathList
		Field pathListField = findField(loader, "pathList");
		Object dexPathList = pathListField.get(loader);
		
		//通过调用DexPathList.makeDexElements(ArrayList files, File optimizedDirectory); 传入之前释放出来的Classes1.dex...ClassesN.dex所在路径，生成对应的DexElements, 然后和当前已加载主Dex的Classloader对应的DexPathList中的DexElement合并，之后再通过发射设置给当前ClassLoader对应的DexPthList，这样，当前ClassLoader就拥有一个包含所有DexElement的dexPathList,也就可以访问其他多个Dex的
		expandFieldArray(dexPathList, "dexElements", 			makeDexElements(dexPathList,
			new ArrayList <File> (additionalClassPathEntries), 			optimizedDirectory,
			suppressedExceptions));
	}
}

//反射替换
private static void expandFieldArray(Object instance, String fieldName,
	Object[] extraElements) {
	Field jlrField = findField(instance, fieldName);
	Object[] original = (Object[]) jlrField.get(instance);
	Object[] combined = (Object[]) Array.newInstance(
	original.getClass().getComponentType(), original.length + 	extraElements.length);
	System.arraycopy(original, 0, combined, 0, original.length);
	System.arraycopy(extraElements, 0, combined, original.length, 		extraElements.length);
	jlrField.set(instance, combined);
}

//构造DexClement[]
private static Object[] makeDexElements(
	Object dexPathList, ArrayList <File> files, File optimizedDirectory,
	ArrayList <IOException> suppressedExceptions)
	throws IllegalAccessException, InvocationTargetException,
	NoSuchMethodException {
	Method makeDexElements =
	findMethod(dexPathList, "makeDexElements", ArrayList.class, File.class,ArrayList.class);
	return (Object[]) makeDexElements.invoke(dexPathList, files, optimizedDirectory,suppressedExceptions);
}

对照源码可以看出，MultiDex的加载原理比较简单，主要是从ClassLoader入手，通过反射调用使得当前加载了主Dex文件的ClassLoader也可以读取到其他Dex。但我们从中可以看出这里有很多IO操作，容易出现ANR问题，这也决定了我们的分包Dex也不能过大。

MultiDex的局限性

• 如果分包的Dex过大，上述install过程涉及IO等操作，容易触发ANR问题；

• 当运行的版本低于 Android 5.0（API 级别 21）时，使用多 dex 文件不足以避开 linearalloc 限制（参考google：https://issuetracker.google.com/issues/37008143）。此上限在 Android 4.0（API 级别 14）中有所提高，但这并未完全解决该问题。在低于 Android 4.0 的版本中，可能会在达到 DEX 索引限制之前达到 linearalloc 限制。因此，如果您的目标 API 级别低于 14，请在这些版本的平台上进行全面测试，因为您的应用可能会在启动时或加载特定类组时出现问题。代码压缩可以减少甚至有可能消除这些问题。

总结

由于Dex文件结构的限制，方法引用数不能超过64K，因此除了努力缩减代码之外，官方也提供了一套工具库，一方面支持编译时分包，一个APK中包含多个Dex，同时也利用ClassLoader原理巧妙的绕过了Dalvik加载APK时只加载一个Dex的限制。而Android 5.0 N之后引入ART，这些问题被巧妙的隐藏或者解决了，但MultiDex的加载原理ClassLoader在后续的热修复插件化等方案中应用的很广泛。

参考资料：
https://developer.android.com/studio/build/multidex#mdex-gradle
https://yangxiaobinhaoshuai.github.io/