热修复常见的热修复框架简介

常见的几个热修复框架的对比

热修复框架的种类繁多，按照公司团队划分主要有以下几种：

类别	成员
阿里系	AndFix、Dexposed、阿里百川、Sophix
腾讯系	微信的Tinker、QQ空间的超级补丁、手机QQ的QFix
知名公司	美团的Robust、饿了么的Amigo、美丽说蘑菇街的Aceso
其他	RocooFix、Nuwa、AnoleFix

虽然热修复框架很多，但热修复框架的核心技术主要有三类，分别是代码修复、资源修复和动态链接库修复，其中每个核心技术又有很多不同的技术方案，每个技术方案又有不同的实现，另外这些热修复框架仍在不断的更新迭代中，可见热修复框架的技术实现是繁多可变的。

部分热修复框架的对比如下表所示：

特性	AndFix	Tinker/Amigo	QQ空间	Robust/Aceso
即时生效	是	否	否	是
方法替换	是	是	是	是
类替换	否	是	是	否
类结构修改	否	是	否	否
资源替换	否	是	是	否
so替换	否	是	否	否
支持gradle	否	是	否	否
支持ART	是	是	是	是
支持Android7.0	是	是	是	是

我们可以根据上表和具体业务来选择合适的热修复框架，当然上表的信息很难做到完全准确，因为部分的热修复框架还在不断更新迭代。

从表中也可以发现Tinker和Amigo拥有的特性最多，是不是就选它们呢？也不尽然，拥有的特性多也意味着框架的代码量庞大，我们需要根据业务来选择最合适的，假设我们只是要用到方法替换，那么使用Tinker和Amigo显然是大材小用了。另外如果项目需要即时生效，那么使用Tinker和Amigo是无法满足需求的。

Tinker、AndFix 等框架的比较

Tinker的功能非常强大，基本除了AndroidManifest.xml文件和tinker本身少数几个类之外，其他内容都能替换，包括布局、资源

但是接入麻烦，上手难度较AndFix高很多。

和Tinker不同， AndFix上手非常容易，只需寥寥数行代码即可，但没有Tinker功能多。

由于AndFix实现原理是底层通过c++直接操作指针实现，它可以做到加载补丁后实时生效，但它目前只支持替换方法实现内容，不能增加类也不能增加、修改字段。

	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体积	较大	较小	较小	较小
成功率	较高	较高	一般	最高

阿里各个版本热修复的差别

参考

虽然有着一些使用限制，但一旦满足使用条件，这种热修复方式是十分出众的，它补丁小，加载迅速，能够实时生效无需重新启动app，并且具有着完美的设备兼容性。对于较小程度的修复再适合不过了。

本修复方案将最先在阿里Hotfix最新版本(Sophix)上应用，由手机淘宝技术团队与阿里云联合发布。

Sophix提供了一套更加完美的客户端服务端一体的热更新方案。针对小修改可以采用本文这种即时生效的热修复，并且可以结合资源修复，做到资源和代码的即时生效。

而如果触及了本文提到的热替换使用限制，对于比较大的代码改动以及被修复方法反射调用情况，Sophix也提供了另一种完整代码修复机制，不过是需要app重新冷启动，来发挥其更加完善的修复及更新功能。从而可以做到无感知的应用更新。

并且Sophix做到了图形界面一键打包、加密传输、签名校验和服务端控制发布与灰度功能，让你用最少的时间实现最强大可靠的全方位热更新。

一张表格来说明一下各个版本热修复的差别：

方案对比	Andfix开源版本	阿里Hotfix 1.X	阿里Hotfix最新版(Sophix)
方法替换	支持，除部分情况^[0]	支持，除部分情况	全部支持
方法增加减少	不支持	不支持	以冷启动方式支持^[1]
方法反射调用	只支持静态方法	只支持静态方法	以冷启动方式支持
即时生效	支持	支持	视情况支持^[2]
多DEX	不支持	支持	支持
资源更新	不支持	不支持	支持
so库更新	不支持	不支持	支持
Android版本	支持2.3~7.0	支持2.3~6.0	全部支持包含7.0以上
已有机型	大部分支持^[3]	大部分支持	全部支持
安全机制	无	加密传输及签名校验	加密传输及签名校验
性能损耗	低，几乎无损耗	低，几乎无损耗	低，仅冷启动情况下有些损耗
生成补丁	繁琐，命令行操作	繁琐，命令行操作	便捷，图形化界面
补丁大小	不大，仅变动的类	小，仅变动的方法	不大，仅变动的资源和代码^[4]
服务端支持	无	支持服务端控制^[5]	支持服务端控制

说明：

[0] 部分情况指的是构造方法、参数数目大于8或者参数包括long,double,float基本类型的方法。
[1] 冷启动方式，指的是需要重启app在下次启动时才能生效。
[2] 对于Andfix及Hotfix 1.X能够支持的代码变动情况，都能做到即时生效。而对于Andfix及Hotfix 1.X不支持的代码变动情况，会走冷启动方式，此时就无法做到即时生效。
[3] Hotfix 1.X已经支持绝大部分主流手机，只是在X86设备以及修改了虚拟机底层结构的ROM上不支持。
[4] 由于支持了资源和库，如果有这些方面的更新，就会导致补丁变大一些，这个是很正常的。并且由于只包含差异的部分，所以补丁已经是最大程度的小了。
[5] 提供服务端的补丁发布和停发、版本控制和灰度功能，存储开发者上传的补丁包。

从现在起，让你的APP实现随心所欲的热更新吧！请猛戳这里>_<

注意事项

在本地动态执行远端下发的代码是极度危险的行为，利用此方法执行非法代码等或用于绕过 Google Play 等市场的审查是违反相关协议的，也是对用户极度不负责任的行为。
在一些访问非常密集的地方使用热更新可能会对效率产生相对比较大的影响，应该避免使用。
我们可以对 Java 的 ScriptEngine 进行一些封装成为一个 HotPatch 类使得它更适合做热更新的工作。
检查热更新补丁的管道一定要建立在 https 上，因为下发代码是极其危险的，如果被劫持，后果是无法想象的。
请求时最好自动带上 Android 版本、手机型号、地区、版本号等信息，以方便更精确地下发，千万不能下发错。
Java在运行时加载对应的类是通过ClassLoader来实现的，ClassLoader本身是一个抽象来，Android中使用PathClassLoader类作为Android的默认的类加载器。
我们如果想做hotpatch，一定要保证我们的hotpacth dex文件出现在dexElements列表的前面。