一、tinker热修复方案

tinker热修复是一种冷启动的修复，就是需要用户重新启动app，因为这样才能让ClassLoader去重新加载新的类。

二、tinker热修复原理

首先我们要了解class文件是怎么被系统所加载的。这里面有个ClassLoader，具体实现的在它的子类BaseDexClassLoader，通过源码发现，它有个成员变量DexPathList，这个类里面又有个DexElement数组，表示所有Class的封装。所以我们需要反射拿到DexElement这个数组，然后将我们修复好的dex文件插入到这个数组的最前面，因为越靠前的Dex优先被系统使用，后续相同的 Dex文件就不会被加载。

热修复插桩原理.png

我们知道app在安装完成后，系统会复制一份apk的文件到私有目录：data/app/包名/base.apk；那么我们也可以仿照这个流程，将从服务器下载好的更新的dex文件，防止到私有目录当中，然后解析生成DexClassLoader，将修复好的dex和系统的dexElement进行合并，在通过反射，赋值给系统的DexPathList。

实现步骤分析.png

三、Dex为何需要分包？

主要原因是65536的限制。有个错误大家会很熟悉：com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
就是说应用的方法超过了最大数65536.
为了解决65536的限制，从而产生了Dex分包机制，Dex分包方案主要做的是在打包时，将应用代码分成多个Dex，将应用启动时必须用到的类和这些类的直接引用类放到主Dex，其他代码放到次 Dex，当应用启动时先加载主Dex，等到应用启动后再动听的加载次Dex。