常见场景App打包发出后
1.忘了关掉Log输出了
2.存在一个业务逻辑触发必崩溃
3.某个本地图标忘了替换成新的
遇到这些问题，若是Web站点，Mobile站点问题都不大，因为这些具有“持续发布”的特长，但是App的特点是“版本发布”，每个版本需要打包，上传到应用市场，经过审核后，发布。这一些过程，3-7天不等。另外更新频率过快，用户体验也不好。另外若没有实现增量更新，App的包又比较大，还有一点，需要紧急修复的一般也没有多少功能，所以用户会比较反感。
那么如何有效解决这些问题呢？热修复
热修复几个属性如下
价值：线上问题第一时间能够被修复
特点：App无需发版，用户无感知，体积小，灵活
本质：打补丁
可以看到两个痛点都被解决了1.无需发版2.用户无感知
看到后有点小激动了，来看热修复示意图：
从示意图可以看到，重点有三个问题
1.服务器端需要下发和管理补丁，并提供安全传输部署工作
2.客户端App下载补丁，并处理
3.补丁的编写
后面说如何针对这三个问题解决
热修复目前iOS与Android平台均支持
iOS主流推荐：
JPatch官方提供支持后台，但要嵌入SDK
若使用GitHub上开源实现，需要自己处理及维护后台
补丁主要技术：使用JavaScript调用任何Objective-C的原生接口，替换任意Objective-C原生方法
2.阿里百川
http://baichuan.taobao.com/?spm=a3c0d.7629140.1998907816.1.G9itXC官方文档
官方提供支持后台，同样需要嵌入SDK
补丁主要技术：1.JavaScript
3.lua脚本支持多目录多文件
Android主流推荐
Native，代表有阿里的Dexposed、HotFix、AndFix与腾讯的内部方案KKFix；
Java,代表有Qzone的超级补丁、大众点评的nuwa、百度金融的rocooFix,饿了么的amigo以及美团的robust,微信Tinker
1.支付宝AndFixhttps://github.com/alibaba/AndFixGithub
不提供支持后台，需要嵌入SDK
技术核心：底层采用native hook的方式，这套方案直接使用dalvik_replaceMethod替换class中方法的实现
特点：无需重启应用，直接生效
缺点：只支持原有方法上修改，不能增加方法，成员变量等等
2.QZone超级补丁
核心技术：通过classLoader替换项目中的类
缺点：补丁包很大，运行性能受到影响，启动变慢
不提供支持后台
3.微信Tinker
方案来源gradle编译的instant run与buck编译的exopackage
核心技术：dex替换
优点：解决几乎所有场景
需要考虑的缺点：
1.7.6内核之后Tinker不再支持加固的动态更新 。另外 小问题 2. 补丁通过轮询方式获取,需要自己集成Push 达到下发补丁功能 ：通知客户端，客户端调用Tinker主动获取补丁方法 3. 无法达到，不重启APP的情况下的热修复
提供后台 tinkerpatch.com
4.美团Robust
原理：Robust是为每个函数都插入了一段逻辑，为每个class插入了ChangeQuickRedirect的字段
缺点：复杂，增加包体积
不提供支持后台
5阿里百川HotFix
官方文档
http://baichuan.taobao.com/?spm=a3c0d.7629140.1998907816.1.G9itXC特点：目前1.4最新版，预计17年2月之前发版2.0
1.4采用Java方式替换方法，解决业务场景较少。2.0会解决几乎所有场景
有官方支持后台
下面我们对比一下这些热修复方案
琳琅满目，方案众多
选择建议：
优先选择提供补丁管理，维护，下发的友好后台，会帮助开发者解决诸多小问题
优先选择该项目持续维护，保证出现问题第一时间能够解决
