很早之前就想深入的研究和学习一下热修复，由于时间的原因一直拖着，现在才执笔弄起来。
Android而更新系列：
Android热更新一：JAVA的类加载机制
Android热更新二：理解Java反射
Android热更新三：Android类加载机制
Android热更新四：热修复机制
Android热更新五：四大热修复方案分析
Android热更新六：Qzone热更新原理
Android热更新七：Tinker热更新原理
Android热更新八：AndFix热更新原理
Android热更新九：Robust热更新原理
Android热更新十：自己写一个Android热修复
一. 实现套路
总所周知，目前热修复的实现套路基本上离不开以下两种：
| 实现套路 | 描述 | 代表 |
|---|---|---|
| 底层替换方案 | 底层替换方案限制颇多，但时效性最好，加载轻快，立即见效 | 阿里系的AndFix、Sophix |
| 类加载方案 | 类加载方案时效性差，需要重新冷启动才能见效，但修复范围广，限制少 | QZone超级补丁、微信Tinker |
二. 方案对比分析
虽然热修复的主要套路有两种，但是，由这两种套路延伸出来的各种不同的帮派有很多，其中闻名天下的有四大门派
QZone超级补丁
微信Tinker
阿里AndFix
美团Robust
综合他们的优劣进行对比如下。
| 支撑 \ 方案 | Tinker | QZone | AndFix | Robust |
|---|---|---|---|---|
| 类替换 | yes | yes | no | no |
| So替换 | yes | no | no | no |
| 资源替换 | yes | yes | no | no |
| 全平台支持 | yes | yes | yes | yes |
| 即时生效 | no | no | yes | yes |
| 性能损耗 | 较小 | 较大 | 较小 | 较小 |
| 补丁包大小 | 较小 | 较大 | 一般 | 一般 |
| 开发透明 | yes | yes | no | no |
| 复杂度 | 较低 | 较低 | 复杂 | 复杂 |
| gradle支持 | yes | no | no | no |
| Rom体积 | 较大 | 较小 | 较小 | 较小 |
| 成功率 | 较高 | 较高 | 一般 | 最高 |
总的来说:
AndFix作为native解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的；
Robust兼容性与成功率较高，但是它与AndFix一样，无法新增变量与类只能用做的bugFix方案；
Qzone方案可以做到发布产品功能，但是它主要问题是插桩带来Dalvik的性能问题，以及为了解决Art下内存地址问题而导致补丁包急速增大的。
特别是在Android N之后，由于混合编译的inline策略修改，对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换，它还是2.X－8.X(1.9.0以上支持8.X)的全平台支持。利用Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？
