09.源码阅读（从Android源码角度入手自己实现热修复）

首先我们要知道Activity是如何启动的，在文章https://www.jianshu.com/p/bd5208574430中我们已经看了Activity启动的源码，https://www.jianshu.com/p/40f436881390 ClassLoader加载类的源码，这里再简单回顾一下

Activity加载流程.png

看了Activity的启动流程和ClassLoader加载类的方式之后，我们知道，当一个Activity要启动的时候，最终其实是通过从BaseDexClassLoader中的一个DexPathList类中的dexElements数组中取出来，反射得到对象返回的

那么当开发中出现了问题，比如一个Activity中发生了bug，我们要紧急修复这个问题，同时又不需要应用重启，该怎么做呢，热修复的解决方案有几个可选的阿里 AndFix（不再维护了，并且不支持8.0及以上，不建议使用），腾讯Tinker(需要重启才能生效)。不过今天我们不使用第三方的实现，只从源码方面找答案

关键点就在于dexElements这个数组，经过我们的分析，我们已经知道，所有的类的dexFile文件在应用启动时就已经被保存的这个数组中了，包括发生了错误的文件类，当类被加载的时候，会从前往后遍历这个数组，找到对应的class然后反射得到对象，那么我们的解决办法是，能否将正确的文件类插入到这个数组中，当这个类启动的时候，先加载到我们修复的正确的dexFile文件，从而达到修复的目的，要使用的技术就是反射

实现原理借鉴了腾讯的Tinker，不过Tinker核心思想是利用DexDiff算法对比差异生成Patch补丁包，将生成的差异dex文件插入dexElements，而我们做的却少了生成差分包的过程，是将整个dex文件插入替换，Tinker原理图如下：

20170630144819943.png

我们当前要实现的思路就是现上有一个发生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，可以考虑分包的方案解决这个问题，减少体积。