MultiDex与热修复实现原理

Posted DroidMind

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MultiDex与热修复实现原理相关的知识，希望对你有一定的参考价值。

推荐书籍：
深入探索android热修复技术原理:
https://pan.baidu.com/s/1lsDQdE1Z-_VDidtSGcpVrA
提取码获取方式：扫描关注下面微信公众号，回复关键字: androidfix

在这里插入图片描述

一、Android的ClassLoader体系

这里写图片描述

由上图可以看出，在叶子节点上，我们能使用到的是DexClassLoader和PathClassLoader，他们有如下使用场景：

  1. PathClassLoader是Android应用中的默认加载器，PathClassLoader只能加载/data/app中的apk，也就是已经安装到手机中的apk。这个也是PathClassLoader作为默认的类加载器的原因，因为一般程序都是安装了，在打开，这时候PathClassLoader就去加载指定的apk(解压成dex，然后在优化成odex)就可以了。

  2. DexClassLoader可以加载任何路径的apk/dex/jar，PathClassLoader只能加载已安装到系统中（即/data/app目录下）的apk文件。

从上面我们知道，DexClassLoader和PathClassLoader加载原理其实是一样的，就是使用场景不一样。

二、DexClassLoader动态加载的实现

第一步：创建DexClassLoader对象，加载对应的apk/dex/jar文件。

is = getAssets().open("app.apk");
file = new File(getFilesDir(), "plugin.apk");

fos = new FileOutputStream(file);
byte[] buffer = new byte[1024];
int len;
while ((len = is.read(buffer)) != -1) {
	fos.write(buffer, 0, len);
}
fos.flush();
String apkPath = file.getAbsolutePath();
dexClassLoader = new DexClassLoader(apkPath, getFilesDir().getAbsolutePath(), null, getClassLoader());

下面来看看DexClassLoader的构造函数

public class DexClassLoader extends BaseDexClassLoader {
	// dexPath：是加载apk/dex/jar的路径
	// optimizedDirectory：是dex的输出路径(因为加载apk/jar的时候会解压除dex文件，这个路径就是保存dex文件的)
	// libraryPath：是加载的时候需要用到的lib库，这个一般不用
	// parent：给DexClassLoader指定父加载器
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), libraryPath, parent);
    }
}

可以看到它调用的是父类的构造函数，所以直接来看BaseDexClassLoader的构造函数。

public BaseDexClassLoader(String dexPath, File optimizedDirectory,
		String libraryPath, ClassLoader parent) {
	super(parent);
	this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}

可以看到，它创建了一个DexPathList实例，下面来看看构造函数。

private final Element[] dexElements;

// definingContext对应的就是当前classLoader
// dexPath对应的就是上面传进来的apk/dex/jar的路径
// libraryPath就是上面传进来的加载的时候需要用到的lib库的目录，这个一般不用
// optimizedDirectory就是上面传进来的dex的输出路径
public DexPathList(ClassLoader definingContext, String dexPath,
		String libraryPath, File optimizedDirectory) {
	ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
	this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
									   suppressedExceptions);
}

可以看到它调用的是makeDexElements方法，这个方法就是得到一个装有dex文件的数组Element[]，每个Element对象里面包含一个DexFile对象成员，它对应的就是dex文件。

static class Element {
	private final File file; 
	private final boolean isDirectory; 
	private final File zip;
	private final DexFile dexFile;
	......
}

具体的我们后面再说，下面先看看makeDexElements方法。

// files是一个ArrayList<File>列表，它对应的就是apk/dex/jar文件，因为我们可以指定多个文件。
// optimizedDirectory是前面传入dex的输出路径
// suppressedExceptions为一个异常列表
private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory,
										 ArrayList<IOException> suppressedExceptions) {
	ArrayList<Element> elements = new ArrayList<Element>();
	/*
	 * Open all files and load the (direct or contained) dex files
	 * up front.
	 */
	for (File file : files) {
		File zip = null;
		DexFile dex = null;
		String name = file.getName();
		
		// 如果是一个dex文件
		if (name.endsWith(DEX_SUFFIX)) {
			// Raw dex file (not inside a zip/jar).
			try {
				dex = loadDexFile(file, optimizedDirectory);
			} catch (IOException ex) {
				System.logE("Unable to load dex file: " + file, ex);
			}
		// 如果是一个apk或者jar或者zip文件
		} else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX)
				|| name.endsWith(ZIP_SUFFIX)) {
			zip = file;

			try {
				dex = loadDexFile(file, optimizedDirectory);
			} catch (IOException suppressed) {
				/*
				 * IOException might get thrown "legitimately" by the DexFile constructor if the
				 * zip file turns out to be resource-only (that is, no classes.dex file in it).
				 * Let dex == null and hang on to the exception to add to the tea-leaves for
				 * when findClass returns null.
				 */
				suppressedExceptions.add(suppressed);
			}
		} else if (file.isDirectory()) {
			// We support directories for looking up resources.
			// This is only useful for running libcore tests.
			elements.add(new Element(file, true, null, null));
		} else {
			System.logW("Unknown file type for: " + file);
		}

		if ((zip != null) || (dex != null)) {
			elements.add(new Element(file, false, zip, dex));
		}
	}

	return elements.toArray(new Element[elements.size()]);
}

前面我们提到过Element，它里面具体包含哪些元素，现在从上面代码我们就可以知道了。

static class Element {
	private final File file;  // 它对应的就是需要加载的apk/dex/jar文件
	private final boolean isDirectory; // 第一个参数file是否为一个目录，一般为false，因为我们传入的是要加载的文件
	private final File zip;  // 如果加载的是一个apk或者jar或者zip文件，该对象对应的就是该apk或者jar或者zip文件
	private final DexFile dexFile; // 它是得到的dex文件
	......
}

上面我们可以看到，它调用的是loadDexFile方法。

// file为需要加载的apk/dex/jar文件
// optimizedDirectorydex的输出路径
private static DexFile loadDexFile(File file, File optimizedDirectory)
		throws IOException {
	if (optimizedDirectory == null) {
		return new DexFile(file);
	} else {
		String optimizedPath = optimizedPathFor(file, optimizedDirectory);
		return DexFile.loadDex(file.getPath(), optimizedPath, 0);
	}
}

如果我们没有指定dex输出目录的话，就直接创建一个DexFile对象，如果我们指定了dex输出目录，我们就需要构造dex输出路径。

optimizedPathFor方法用来得到输出文件dex路径，就是optimizedDirectory/filename.dex，optimizedDirectory是前面指定的输出目录，filename就是加载的文件名，后缀为.dex,最终构造得到一个输出dex文件路径.

下面我们重点看看DexFile.loadDex方法。

static public DexFile loadDex(String sourcePathName, String outputPathName,
	int flags) throws IOException {
	return new DexFile(sourcePathName, outputPathName, flags);
}

下面我们就不往下看了，我们这里可以进行总结。

1、在DexClassLoader我们指定了加载的apk/dex/jar文件和dex输出路径optimizedDirectory，它最终会被解析得到DexFile文件。
2、将DexFile文件对象放在Element对象里面，它对应的就是Element对象的dexFile成员变量。
3、将这个Element对象放在一个Element[]数组中，然后将这个数组返回给DexPathList的dexElements成员变量。
4、DexPathList是BaseDexClassLoader的一个成员变量。

最终得到一个装有dex文件的数组Element[]，每个Element对象里面包含一个DexFile对象成员，它对应的就是dex文件。

这里写图片描述

第二步：调用dexClassLoader的loadClass，得到加载的dex里面的指定的Class.

clazz = dexClassLoader.loadClass("com.example.apkplugin.PluginTest");

下面我们来分析一下loadClass方法。因为DexClassLoader和BaseDexClassLoader都没有实现loadClass方法，所以最终调用的是ClassLoader的loadClass方法。

public Class<?> loadClass(String className) throws ClassNotFoundException {
	return loadClass(className, false);
}

protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
	Class<?> clazz = findLoadedClass(className);

	if (clazz == null) {
		ClassNotFoundException suppressed = null;
		try {
			clazz = parent.loadClass(className, false);
		} catch (ClassNotFoundException e) {
			suppressed = e;
		}

		if (clazz == null) {
			try {
				clazz = findClass(className);
			} catch (ClassNotFoundException e) {
				e.addSuppressed(suppressed);
				throw e;
			}
		}
	}

	return clazz;
}

可以看到它调用的是findClass方法，由于DexClassLoader没有实现这个方法，所以我们看BaseDexClassLoader的findClass

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
	List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
	Class c = pathList.findClass(name, suppressedExceptions);
	if (c == null) {
		ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \\"" + name + "\\" on path: " + pathList);
		for (Throwable t : suppressedExceptions) {
			cnfe.addSuppressed(t);
		}
		throw cnfe;
	}
	return c;
}

pathList就是前面创建的DexPathList对象，从上面我们知道，我们加载的dex文件都存放在它的exElements成员变量上面，dexElements就是Element[]数组，所以可以看到BaseDexClassLoader的findClass方法调用的是pathList的findClass方法，我们具体来看看。

可以看到BaseDexClassLoader的findClass方法调用的是DexPathList的findClass方法。

public Class findClass(String name, List<Throwable> suppressed) {
	for (Element element : dexElements) {
		DexFile dex = element.dexFile;

		if (dex != null) {
			Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
			if (clazz != null) {
				return clazz;
			}
		}
	}
	if (dexElementsSuppressedExceptions != null) {
		suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
	}
	return null;
}

可以看到它就是遍历dexElements数组，从每个Element对象中拿到DexFile类型的dex文件，然后就是从dex去加载所需要的class文件，直到找到为止。

**总结：**一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找类则返回，如果找不到从下一个dex文件继续查找。

三、MultiDex基本原理
当一个app的功能越来越复杂，代码量越来越多，可以遇到下面两种情况：

  1. 生成的apk在2.3以前的机器无法安装，提示INSTALL_FAILED_DEXOPT
  2. 方法数量过多，编译时出错，提示：Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536

原因：

  1. Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M
  2. 一个dex文件最多只支持65536个方法。

解决方案：
1、使用Multidex，将编译好的class文件拆分打包成两个dex，绕过dex方法数量的限制以及安装时的检查，在运行时再动态加载第二个dex文件中。
2、使用插件化，将功能模块分离，减少宿主apk的大小和代码。

插件化我们这里先不讨论，这里主要来说说Multidex的原理。

基本原理：
1、除了第一个dex文件（即正常apk包唯一包含的Dex文件），其它dex文件都以资源的方式放在安装包中。所以我们需要将其他dex文件并在Application的onCreate回调中注入到系统的ClassLoader。并且对于那些在注入之前已经引用到的类（以及它们所在的jar）,必须放入第一个Dex文件中。

2、PathClassLoader作为默认的类加载器，在打开应用程序的时候PathClassLoader就去加载指定的apk(解压成dex，然后在优化成odex)，也就是第一个dex文件是PathClassLoader自动加载的。所以，我们需要做的就是将其他的dex文件注入到这个PathClassLoader中去。

3、因为PathClassLoader和DexClassLoader的原理基本一致，从前面的分析来看，我们知道PathClassLoader里面的dex文件是放在一个Element数组里面，可以包含多个dex文件，每个dex文件是一个Element，所以我们只需要将其他的dex文件放到这个数组中去就可以了。

实现：
1、通过反射获取PathClassLoader中的DexPathList中的Element数组（已加载了第一个dex包，由系统加载）
2、通过反射获取DexClassLoader中的DexPathList中的Element数组（将第二个dex包加载进去）
3、将两个Element数组合并之后，再将其赋值给PathClassLoader的Element数组

谷歌提供的MultiDex支持库就是按照这个思路来实现的，我们可以直接来看看源码。

首先来看看使用：
1、修改Gradle的配置，支持multidex:

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.0"
    defaultConfig {
        ...
        minSdkVersion 14
        targetSdkVersion 21
        ...
        // Enabling multidex support.
        multiDexEnabled true
    }
    ...
}
dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

在manifest文件中，在application标签下添加MultidexApplication Class的引用，如下所示：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.android.multidex.myapplication">
    <application
        ...
        android:name="android.support.multidex.MultiDexApplication">
        ...
    </application>
</manifest>

使用起来很简单，下面我们来看看源码，看是不是按照前面介绍的思路实现的。

首先我们来看看MultiDexApplication类。

public class MultiDexApplication extends Application {
    public MultiDexApplication() {
    }

    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(this);
    }
}

原来要求使用MultiDexApplication的原因就是它重写了Application，主要是为了将其他dex文件注入到系统的ClassLoader。

进入MultiDex.install(this)方法。

public static void install(Context context) {
	if(IS_VM_MULTIDEX_CAPABLE) {
		Log.i("MultiDex", "VM has multidex support, MultiDex support library is disabled.");
	// 可以看到，MultiDex不支持SDK版本小于4的系统
	} else if(VERSION.SDK_INT < 4) {
		throw new RuntimeException("Multi dex installation failed. SDK " + VERSION.SDK_INT + " is unsupported. Min SDK version is " + 4 + ".");
	} else {
		try {
		    // 获取到应用信息
			ApplicationInfo e = getApplicationInfo(context);
			if(e == null) {
				return;
			}

			Set var2 = installedApk;
			synchronized(installedApk) {
				// 得到我们这个应用的apk文件路径
				// 拿到这个apk文件路径之后，后面就可以从中提取出其他的dex文件
				// 并且加载dex放到一个Element数组中
				String apkPath = e.sourceDir;
				if(installedApk.contains(apkPath)) {
					return;
				}
				// 将这个apk文件路径放到一个set中
				installedApk.add(apkPath);
				
				// 得到classLoader，它就是PathClassLoader
				// 后面就可以从这个PathClassLoader中拿到DexPathList中的Element数组
				// 这个数组里面就包括由系统加载第一个dex包
				ClassLoader loader;
				try {
					loader = context.getClassLoader();
				} catch (RuntimeException var9) {
					Log.w("MultiDex", "Failure while trying to obtain Context class loader. Must be running in test mode. Skip patching.", var9);
					return;
				}
				
				// 得到apk解压后得到的dex文件的存放目录，放到应用的data目录下
				File dexDir = new File(e.dataDir, SECONDARY_FOLDER_NAME);
				
				// 这个方法就是从apk中提取dex文件，放到data目录下，就不展开了
				List files = MultiDexExtractor.load(context, e, dexDir, false);
				if(checkValidZipFiles(files)) {
					// 这个方法就是将其他的dex文件注入到系统classloader中的具体操作
					installSecondaryDexes(loader, dexDir, files);
				} else {
					files = MultiDexExtractor.load(context, e, dexDir, true);
					installSecondaryDexes(loader, dexDir, files);
				}
			}
		} catch (Exception var11) {
			Log.e("MultiDex", "Multidex installation failure", var11);
			throw new RuntimeException("Multi dex installation failed (" + var11.getMessage() + ").");
		}
	}
}

下面我们重点看看installSecondaryDexes方法。

// loader对应的就是PathClassLoader
// dexDir是dex的存放目录
// files对应的就是dex文件
private static void installSecondaryDexes(ClassLoader loader, File dexDir, List<File> files) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
	if(!files.isEmpty()) {
		if(VERSION.SDK_INT >= 19) {
			MultiDex.V19.install(loader, files, dexDir);
		} else if(VERSION.SDK_INT >= 14) {
			MultiDex.V14.install(loader, files, dexDir);
		} else {
			MultiDex.V4.install(loader, files);
		}
	}

}

可以看到不同的sdk版本实现是有差别的，因为它里面是使用反射实现的，所以会有不同，我们看看MultiDex.V14.install方法。

private static void install(ClassLoader loader, List<File> additionalClassPathEntries, File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
	// 这个方法就是使用反射来得到loader的pathList字段
	Field pathListField = MultiDex.findField(loader, "pathList");
	// 得到loader的pathList字段后，我们就可以得到这个字段的值，也就是DexPathList对象
	Object dexPathList = pathListField.get(loader);
	// 这个方法就是将其他的dex文件Element数组和第一个dex的Element数组合并
	// makeDexElements方法就是用来得到其他dex的Elements数组
	MultiDex.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList(additionalClassPathEntries), optimizedDirectory));
}

下面来看看合并的过程

// instance对应的就是pathList对象
// fieldName 对应的就是字段名，我们要得到的就是pathList对象里面的dexElements数组
// extraElements对应的就是其他dex对应的Element数组
private static void expandFieldArray(Object instance, String fieldName, Object[] extraElements) throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
	// 得到Element数组字段
	Field jlrField = findField(instance, fieldName);
	// 得到pathList对象里面的dexElements数组
	Object[] original = (Object[])((Object[])jlrField.get(instance));
	// 创建一个新的数组用来存放合并之后的结果
	Object[] combined = (Object[])((Object[])Array.newInstance(original.getClass().getComponentType(), original.length + extraElements.length));
	// 将第一个dex的Elements数组复制到创建的数组中去
	System.arraycopy(original, 0, combined, 0, original.length);
	// 将其他dex的Elements数组复制到创建的数组中去
	System.arraycopy(extraElements, 0, combined, original.length, extraElements.length);
	// 将得到的这个合并的新数组的值设置到pathList对象的Element数组字段上
	jlrField.set(instance, combined);
}

整体思路跟上面说的基本一致，理解思路，结合上面的注释基本还是比较清楚的。

四、热修复的一种实现原理

一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找类则返回，如果找不到从下一个dex文件继续查找。

理论上，如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类，如下图：
这里写图片描述

所以，如果某些类需要修复，我们可以把有问题的类打包到一个dex（patch.dex）中去，然后把这个dex插入到Elements的最前面，如下图：
这里写图片描述

具体的方案可以参看文章：安卓App热补丁动态修复技术介绍

使用该原理的开源方案有：
Nuwa
https://github.com/jasonross/Nuwa

HotFix
https://github.com/dodola/HotFix

DroidFix
https://github.com/bunnyblue/DroidFix

参考文章：
Android中插件开发篇之----类加载器

Android dex分包方案

Android分包原理

欢迎关注微信公众号：DroidMind
精品内容独家发布平台
呈现与博客不一样的技术干货

以上是关于MultiDex与热修复实现原理的主要内容，如果未能解决你的问题，请参考以下文章

android MultiDex multidex原理原理下遇见的N个深坑

android MultiDex multidex原理下超出方法数的限制问题

Android 热修复技术---原理

安卓插件化与热修复的选型（转）

Android 框架学习5：微信热修复框架 Tinker 从使用到 patch 加载生成合成原理分析

Android 热更新的前因后果