热更新方案探索：如何有效技术选型

热更新是一种App的更新方式。简单来说，就是在用户下载安装App之后，打开App时对代码和图片等资源进行的即时更新。热更新是App代码逻辑自控发起，无需用户进行手动下载，可以做到用户无感。另外热更新可以做到增量更新，仅需下载更新有修改的代码和资源，可以有效减少更新的时间和数据流量消耗。此外热更新也很灵活，可以随时发起，适合App功能快速迭代。

热更新的技术价值

站在 App 开发者角度的“热”是指在不发版的情况来实现更新，修复 BUG 和发布功能，让开发者得以绕开应用商店的审核机制，避免长时间的审核等待以及多次被拒造成的成本。

在热更新出现之前，通过反射注解、反射调用和反射注入等方式已经可以实现类的动态加载了。热更新的实质就是替换，需要替换运行时新的类和资源文件的加载，就可以认为是热操作了。

热更新的技术选型

其实各家互联网巨头都有自己的热更新技术，目前比较有代表性的技术可以分为两类：类加载、底层替换。

1、类加载

只需要把 Bug 修复涉及到的类文件插入到数组的最前面去，就可以达到热修复的效果。

类加载方案的时效性差，需要重新冷启动才能见效，但修复范国广，限制少。代表的有Qzone 超级补丁、微信 Tinker

2、底层替换

底层替换是一种native方案，其操作是在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的。

底层替换方案限制颇多，可以不用重启生效，加载经快，立即见效。代表的有阿里系的 AndFix 、Sophix

如果进一步对各个热更新方案进行对比，可以用这张图进行总结：

对比角度	Andfix	阿里 Hattix	Sophix	Tinke
方法替换	支持	支持	支持	--
方法增滅	不支持	不支持	冷启动支持	--
反射调用	支持静态方案	支持静态方案	冷启动支持	--
修复方式	即时生效	即时生效	自动判断	冷启动
安全机制	无	加密传输及签名校验	加密传输及签名校验	加密传输及签名校验
性能损耗	几乎无损耗	几乎无损耗	冷启劲有低损耗	较高
补丁大小	小	小	小	小

热更新就是一种热操作，它是一种改变app运行行为的技术，其本质就是利用hook操作进行替换，在代码上是一种侵入性的操作。由于在安全性的考虑，Google 和苹果是不支持热更新的，在中国特殊国情下才出现了这种黑科技。

是否存在更加简洁靠谱的热更新机制呢？

答案是有的。

一种轻量的热更新机制

也是因为国内互联网企业和开发者的持续内卷，小程序形态的业务承载方式兴起，至从2017年微信上线开放小程序以来，支付宝、百度、字节等头部厂商都投入到小程序的研发体系中，目前小程序已经受到市场的普遍认可，优质的操作体验也改变了用户原有第一时间下载App使用商家服务的习惯。

但是大家有想过吗，小程序也是一种热更新机制，对于微信、支付宝等平台来讲，可以通过管理后台上下架的形式对小程序承载的业务进行管理，并且这种方式对于代码是完全没有入侵的。相对于以上集中热更新方式来讲优势也比较明显，但是这种方式也是有门槛的。

不是每家公司都有像微信、支付宝等大厂商研发技术和成本让自己的 App 具备小程序的运行能力，背后需要掌握复杂的编译及渲染技术。

目前市场上有一些比较成熟的小程序容器技术是可以帮助任一App实现这种功能，例如 FinClip 是通过 SDK 集成的方式让自有的 App 具备小程序运行能力。说的更浅显易懂的话，这就是一种「Native + 小程序」的混合开发模式，借助这种开发模式可以让小程序运行在自有 App 中，将臃肿的 App 功能打散，功能模块互相解耦实现模块化开发，各业务模块间互不影响，通过管理后台即能实现实时动态更新与发布。