首先我们要知道Activity是如何启动的，在文章https://www.jianshu.com/p/bd5208574430中我们已经看了Activity启动的源码，https://www.jianshu.com/p/40f436881390 ClassLoader加载类的源码，这里再简单回顾一下
看了Activity的启动流程和ClassLoader加载类的方式之后，我们知道，当一个Activity要启动的时候，最终其实是通过从BaseDexClassLoader中的一个DexPathList类中的dexElements数组中取出来，反射得到对象返回的
那么当开发中出现了问题，比如一个Activity中发生了bug，我们要紧急修复这个问题，同时又不需要应用重启，该怎么做呢，热修复的解决方案有几个可选的阿里 AndFix（不再维护了，并且不支持8.0及以上，不建议使用），腾讯Tinker(需要重启才能生效)。不过今天我们不使用第三方的实现，只从源码方面找答案
关键点就在于dexElements这个数组，经过我们的分析，我们已经知道，所有的类的dexFile文件在应用启动时就已经被保存的这个数组中了，包括发生了错误的文件类，当类被加载的时候，会从前往后遍历这个数组，找到对应的class然后反射得到对象，那么我们的解决办法是，能否将正确的文件类插入到这个数组中，当这个类启动的时候，先加载到我们修复的正确的dexFile文件，从而达到修复的目的，要使用的技术就是反射
实现原理借鉴了腾讯的Tinker，不过Tinker核心思想是利用DexDiff算法对比差异生成Patch补丁包，将生成的差异dex文件插入dexElements，而我们做的却少了生成差分包的过程，是将整个dex文件插入替换，Tinker原理图如下：
我们当前要实现的思路就是现上有一个发生bug的app有待修复，我们在线下生成一个修复后的apk，将其后缀改为.zip，然后解压打开，得到里边的classes.dex文件，客户端下载这个修复的dex到本地，然后将这个dex插入本地apk的dex数组中实现修复bug的功能。
构造方法执行，初始化dex文件的存储位置
public FixDexManager(Context context) {
this.mContext = context;
//获取系统能够访问的dex目录
this.mDexDir = context.getDir("odex",Context.MODE_PRIVATE);
}
遍历所有dex文件，存入集合中，这样做也是仿照了AndFix的处理方式，目录下可能存在多个dex文件，所以我们需要将他们都放入集合中，然后开始修复
public void loadFixDex() throws Exception{
File[] dexFiles = mDexDir.listFiles();
List<File> fixDexFiles = new ArrayList<>();
for (File dexFile : dexFiles) {
if (dexFile.getName().endsWith(".dex")){
fixDexFiles.add(dexFile);
}
}
fixDexFiles(fixDexFiles);
}
进入fixDexFiles方法
加载到程序已经运行的dexElements数组，这个数组包括存在问题的类，然后通过BaseDexClassLoader加载得到我们修复后的dex文件中的dexElements数组，最终将这个正确的dexElements数组插入到程序已经运行的dexElements中，从而当程序要启动一个类的时候，会从数组中获取到正确的类，达到修复bug的目的
private void fixDexFiles(List<File> fixDexFiles) throws Exception{
//1.先获取已经运行的dexElement
ClassLoader applicationClassLoader = mContext.getClassLoader();
//Element数组对象
Object applicationDexElements = getDexElementByClassLoader(applicationClassLoader);
File optimizedDirectory = new File(mDexDir,"odex");
if (!optimizedDirectory.exists()){
optimizedDirectory.mkdirs();
}
//修复
for (File fixDexFile : fixDexFiles) {
//参数：
// String dexPath, dex路径
// File optimizedDirectory,
// String librarySearchPath, so文件位置
// ClassLoader parent 父classloader
ClassLoader fixDexClassLoader = new BaseDexClassLoader(
fixDexFile.getAbsolutePath(),//dex路径,必须要在应用目录下的odex文件中
optimizedDirectory,
null,
applicationClassLoader
);
Object fixDexElements = getDexElementByClassLoader(fixDexClassLoader);
//3.将下载的dex插入到已经运行的dexElement的最前边,合并
//applicationClassLoader 数组合并fixDexElements数组
applicationDexElements = combineArray(fixDexElements, applicationDexElements);
//把合并的数组注入到原来的类中 applicationClassLoader
injectDexElements(applicationClassLoader, applicationDexElements);
}
}
通过反射再次获取到dexElements这个数组的Field,和它所在DexPathList的对象，注入即可
//把dexElements注入到classLoader中
private void injectDexElements(ClassLoader classLoader, Object dexElements) throws Exception{
//先获取pathList
Field pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
pathListField.setAccessible(true);
Object pathList = pathListField.get(classLoader);
//获取pathList中的dexElements
Field dexElementsField = pathList.getClass().getDeclaredField("dexElements");
dexElementsField.setAccessible(true);
//利用反射进行注入
dexElementsField.set(pathList,dexElements);
}
使用方法：
在Application启动的时候初始化并调用修复方法，这种实现方式有很大的问题，因为是将修复后的dex插入原来的dex数组，以保证加载类的时候可以加载到正确的类，那么这种情况下，如果当前bug页面已经加载出来，这时候再通过这种方式注入dex是不会起作用的，必须在启动bug类之前将dex注入，否则如果不重启，不会有效果。所以这种方式实现的热修复必须要重启生效。
FixDexManager manager = new FixDexManager(this);
//加载所有修复的dex包，第一次的时候会从服务器上下载到修复的dex包并放在我们制定的目录下，
//第二次进入的时候，直接读取保存的文件进行修复
try {
manager.loadFixDex();
File file = new File(Environment.getExternalStorageDirectory().getAbsolutePath(),"fix.apatch");
if (file.exists()){
try {
manager.fixDex(file.getAbsolutePath());
Toast.makeText(getApplicationContext(),"修复bug成功",Toast.LENGTH_SHORT).show();
} catch (Exception e) {
Toast.makeText(getApplicationContext(),"修复bug失败",Toast.LENGTH_SHORT).show();
e.printStackTrace();
}
}
} catch (Exception e) {
e.printStackTrace();
}
总结一下：
通过这种方式实现热修复，需要重启app，它的缺点也很明显，由于是将整个dex文件注入到原来dex数组中，会使app内存占用增大一倍左右，我这边亲测，原本占空间10.8M的app，注入新的dex后，内存占用变成了19.8M，可以考虑分包的方案解决这个问题，减少体积。
