常见场景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会解决几乎所有场景

有官方支持后台

下面我们对比一下这些热修复方案

琳琅满目，方案众多

选择建议：

优先选择提供补丁管理，维护，下发的友好后台，会帮助开发者解决诸多小问题

优先选择该项目持续维护，保证出现问题第一时间能够解决