应用场景
-
刚发布的版本出现了严重的Bug，这就需要去解决Bug、测试并打包在各个应用市场上重新发布，
这会耗费大量的人力和物力，代价会比较大。
-
版本升级率不高，并且需要很长时间来完成版本覆盖，此前版本的Bug就会一直影响不升级版本的用户。
热修复可以在不重装的情况下，替换某些模块
代码修复
类加载（重启App）
基于 Dex 分包方案，其中一个环节就是调用DexPathList的findClass的方法
Element内部封装了DexFile，DexFile用于加载dex文件，因此每个dex文件对应一个Element。
多个Element组成了有序的Element数组dexElements。
把需要替换的Element封装类放到前面，提前被搜索到即可
底层替换
与类加载方案不同的是，底层替换方案不会再次加载新类，而是直接在Native层修改原有类，底层替换方案和反射的原理有些关联
通过执行入口就可以跳过去执行show方法。替换ArtMethod结构体中的字段或者替换整个ArtMethod结构体，这就是底层替换方案
Instant Run
Instant Run在第一次构建APK时，使用ASM在每一个方法中注入了一段代码，（未完待续）
资源修复
Instant Run
一种运行机制，只构建和部署更改的部分，Instant Run部署有三种方式，
Hot swap：代码的增量改变不需要重启App，甚至不需要重启当前的Activity。修改一个现有方法中的代码时会采用Hot Swap。
Warm Swap：App不需重启，但是Activity需要重启。修改或删除一个现有的资源文件时会采用Warm Swap。
Cold Swap：App需要重启，但是不需要重新安装。比如添加、删除或修改一个字段和方法、添加一个类等。
（1）创建新的AssetManager，通过反射调用addAssetPath方法加载外部的资源，这样新创建的AssetManager就含有了外部资源。
（2）将AssetManager类型的mAssets字段的引用全部替换为新创建的AssetManager。
动态链接库修复（SO）
Android平台的动态链接库主要指的是so库。
热修复框架的so的修复的主要是更新so，换句话说就是重新加载so，因此so的修复的基础原理就是加载so。
加载so主要用到了System类的load和loadLibarary方法
（1）将so补丁插入到NativeLibraryElement数组的前部，让so补丁的路径先被返回和加载。
（2）调用System的load方法来接管so的加载入口。