热修复就是动态下发代码，它可以使开发者在不发布新版本的情况下，修复 BUG 和发布功能， 避免长时间的审核等待以及多次被拒造成的成本，达到及时解决问题和发布功能的目的。
一. 实现方案
目前热修复的实现套路基本上离不开以下两种：
二. 方案对比分析
以下是Tinker、QZone超级补丁、AndFix、Robust对比图。
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方案目前是bugly热修复方案，这样子作为一个初创企业，只需要集成bugly sdk即可拥有强有力的热修复能力以及版本发布能力，同时兼具客户端bug收集等基本功能，极大的减少了企业的人力成本。
参考文档：
-
bugly文档中心：
-
buglyDemo地址：
-
tinker地址：
-
AndFix地址：
-
Robust地址：
-
QZone超级补丁：
网友评论