移动开发热更新技术选型盘点

热更新用通俗的讲就是软件不通过应用商店的软件版本更新审核，直接通过应用自行下载的软件数据更新的行为。在用户下载安装 App 之后，打开 App 时遇到的即时更新，是一种各大手游等众多 App 常用的更新方式。

大家熟知的王者荣耀，经常就会采用热更新的方式让用户直接在 App 内下载数据包得到更新，避免了用户耗费时间和流量下载应用。

热更新的技术价值

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

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

热更新的技术选型

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

1、类加载

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

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

2、底层替换

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

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

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

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

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

答案是有的。

一种轻量的热更新机制

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

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

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

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

推测大家现在想到的一个点：H5 也能实现，为啥还要去用小程序容器。

很简单，H5 白屏卡顿等问题频发，对用户体验造成极大影响，对于追求用户体验的 App 来讲这点就很排斥。实话现在使用各家银行 App 内嵌的 H5 页面我是真的很烦，加载慢还各种卡。

小程序类似原生的使用体验、各种权限的获取、保存缓存等正好能够解决之前 H5 遗留的这些问题。

热更新还有很多值得讨论的，你的看法和观点是什么？