写在前面的话
对于hotfix的思考与使用场景参考Tinker官方文档，对于hotfix的技术与使用场景都是值得我们深入思考的，热修复只能用来做线上的bug修复吗？热修复的应用场景有哪些？热修复有什么局限性？
这些问题在我们接入热修复框架的时候是否真的认真思考过。基于谷歌的MultiDex与InstantRun方案拉开了国内热修复，插件化的序幕，在碎片化严重的Android国内市场，我们想方设法与厂商对抗，与google对抗来实现上线之后应用的灵活性与掌控性，但是这样无异于带着手铐与脚链跳舞，起舞的同时舞姿却并不优美。
hotfix的局限与应用场景
继插件化后，热补丁技术在2015年开始爆发，目前已经是非常热门的Android开发技术。其中比较著名的有淘宝的Dexposed、支付宝的AndFix、QZone的超级热补丁以及Wechat的Tinker热修复方案。
这些热修复框架分为Framework层的hook与native层结构体的替换两个派别。认真看过源码你可以发现，不管是那种方式，当中都充斥着多分支的版本适配，每个热补丁的发布都会自身应用版本的限制与手机版本的限制。
可以看出，热补丁现在仍然存在比较大的局限性，包括下面几个：
1. 补丁只能针对单一客户端版本，随着版本差异变大补丁体积也会增大[应用版本差异]
2. 补丁不能支持所有的修改，例如AndroidManifest[android安装流程不可逆]
3. 补丁无论对代码还是资源的更新成功率都无法达到100%[手机厂商源码修改限制]
既然补丁技术无法完全代替升级，那它适合使用在哪些场景呢？
轻量而快速的升级
热补丁技术也可以理解为一个动态修改代码与资源的通道，它适合于修改量较少的情况。根据android用户的升级习惯，我们发布一个新版本需要较长的周期才能实现较大面积的线上覆盖，热补丁适用于发布较小改动的代码版本，快速实现的线上覆盖率。
正因如此，补丁技术非常适合使用在灰度阶段。在过去，我们需要在正式发布前保证所有严重的问题都已经得到修复，这通常需要我们多次的灰度过程，而且无法快速的验证这些问题在同一批用户的修复效果。利用热补丁技术，我们可以快速对同一批用户验证修复效果，这大大缩短了我们的发布流程。
若发布版本出现问题或紧急漏洞，传统方式需要单独灰度验证修改，然后重新发布新的版本。利用补丁技术，我们只需要先上线小部分用户验证修改的效果，最后再全量上线即可。
发布补丁等同于发布版本，它也应该严格执行完整的测试与上线流程。
热修复技术可以为我们提供便利，但是不应该被滥用，在开发阶段我们还是要做好我们的应用质量把关，就像上面说的，热修复是有局限性的，并不能保证百分之百的成功补丁率。接入热修复框架之后我们也应该有一套完整的补丁发布流程与分支管理流程用于保证现有开发的源码版本与线上的版本对齐。
总的来说，补丁技术可以降低开发成本，缩短开发周期，实现轻量而快速的升级。
远端调试与代码下发
利用补丁技术，我们避免了骚扰用户而默默的为用户解决问题。
可以这么理解这个功能，我们可以通过内置一些辅助行的功能代码然后通过热补丁来触发。当然这也需要非常严格的权限管理，以防恶意或随意使用。
这属于动态下发代码的范畴，不仅是触发应用开关，甚至可以做成一个动态配置下发系统，但是不应该被滥用，是需要被严格管控的做法。
数据统计与AB测试
数据统计在微信中也占据着非常重要的位置，我们也非常希望将热补丁与数据统计结合的更好。事实上，热补丁无论在普通的数据统计还是ABTest都有着非常大的优势。
例如若我想对同一批用户做两种test, 传统方式无法让这批用户去安装两个版本。使用补丁技术，我们可以方便的对同一批用户不停的更换补丁。
hotfix发布系统
一个完善的热补丁系统需要包括以下几个方面：
1. 网络通道：这里要解决的问题是决定补丁以何种方式推送给哪部分的用户；
2.上线与后台管理平台：这里主要包括热补丁的上线管理，历史管理以及上报分析，报警监控等；
网络通道负责的将补丁包交付给用户，这个包括特定用户与全量用户两种情况。
全版本的pull通道：在登陆/24小时等时机，通过pull方式查询后台是否有对应的补丁包更新，这也是我们最常用的方式；
指定版本的push通道：针对版本的通道，在紧急情况下，我们可以在一个小时内向所有用户下发补丁包更新。
指定特定用户的push通道：对特定用户或用户组做远程调试。
推荐链接：
各大热补丁方案分析和比较：http://blog.zhaiyifan.cn/2015/11/20/HotPatchCompare/