什么是热修复？
定义： 在我们应用上线后出现bug需要及时修复时，不用再发新的安装包，只需要发布补丁包，在客户 无感知下 修复掉bug 。
怎么进行热修复？
服务端：补丁包管理
用户端：执行热修复
开发端：生成补丁包
热修复需要解决的问题
补丁包是什么？
如何生成补丁包？
开启混淆后呢？
对 比改动自动生成补丁包 (gradle) ？
什么时候执行热修复？
怎么执行热修复 ( 使用补丁包 ) ？
Android 版本兼容问题？
热补丁方案有很多，其中比较出名的有腾讯Tinker、阿里的AndFix、美团的Robust以及QZone的超级补丁方案。
Tinker的核心原理还是利用到了ClassLoader，一个类只会被加载一次，让补丁包优先被加载，后面相同的bug类就会被修复
关于dex包被加载成Element 在插件化的文章中已经介绍过了，这里不多说。注意的是每个android版本源码不同需要进行版本适配。
Android N混合编译
混合编译运行主要指AOT编译，解释执行与JIT编译，它主要解决的问题有以下几个：
-
应用安装时间过长；在N之前，应用在安装时需要对所有ClassN.dex做AOT机器码编译，类似微信这种比较大型的APP可能会耗时数分钟。但是往往我们只会使用一个应用20%的功能，剩下的80%我们付出了时间成本，却没带来太大的收益。 -
降低占ROM空间；同样全量编译AOT机器码，12M的dex编译结果往往可以达到50M之多。只编译用户用到或常用的20%功能，这对于存储空间不足的设备尤其重要。 -
提升系统与应用性能；减少了全量编译，降低了系统的耗电。在boot.art的基础上，每个应用增加了base.art(这块后面会详细解析), 通过预加载与缓存提升应用性能。 -
快速的系统升级；以往厂商ota时，需要对安装的所有应用做全量的AOT编译，这耗时非常久。事实上，同样只有20%的应用是我们经常使用的，给不常用的应用，不常用的功能付出的这些成本是不值得的。
Android N为了解决这些问题，通过管理解释，AOT与JIT三种模式，以达到一种运行效率、内存与耗电的折中。简单来说，在应用运行时分析运行过的代码以及“热代码”，并将配置存储至Profile文件。在设备空闲与充电时，ART仅仅编译这份配置中的“热代码”。使用Aop(ALL-of-the-time compilation：全时段编译)编译生成称为app_image的base.art(类对象映像)文件，这个art文件会在apk启动时自动加载（相关与缓存）。根据类加载原则，类被加载了无法被替换，即无法修复。
混合编译热修复解决方案
运行时替换PathClassLoader方案
app image中class是插入到PatgClassLoader中的classTable中。假设我们完全废弃到PathClassloader,而采用一个新建Classlader来加载后续的所有类，即可达到将cache无用化的效果。
LoadedApk 加载apk的核心类
Resources加载资源的核心类
DrawableInflater 加载drawable的核心类
替换操作
Class_ISPREVERIFIED问题
java.lang.IllegalAccessError:class red in pre-verified class resolved to unexpected implementation
如果MainActivity 类只引用了：Utils类。当打包dex时，MainActivity与Utils都在classes.dex 中，则加载MainAcitivity类被标记未Class_ISPREVERIFIED
如果使用补丁包中的Utils类取代了出现bug的Utils,则会导致MainActivity与其引用的Utils不在同一个dex，但是MainAcitivity已经被打赏标记，此时出现冲突，导致校验失败。
阻止标记
防止类被打上Class_ISPREVERIFIED标记
AntilazyLoad类会被打包成单独的hack.dex,这样当安装apk的时候，classes.dex内部的类都会引用一个在不相同dex中的AntilazyLoad类，防止类被打赏Class_ISPREVERIFIED的标志了，只要没被打上这个标志的类都可以紧张打补丁操作
字节码插桩：在java字节码Class中某些位置插入或修改一些代码
Android 打包流程：
插桩的方式：
第三方框架：
ASM,Javassist
操作java字节码的框架，按照class文件的格式，解析，修改，生成class,可以动态生成类或者增强现有类的功能。如下图，后面我在单独出一篇文章来介绍插桩相关内容。
