热更新技术探讨,该如何选型

发布于:2022-11-09 ⋅ 阅读:(9) ⋅ 点赞:(0) ⋅ 评论:(0)

为了照顾萌新童鞋,最开始还是对热更新的概念做一个通俗易懂的介绍。

热更新用通俗的讲就是软件不通过应用商店的软件版本更新审核,直接通过应用自行下载的软件数据更新的行为。在用户下载安装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 功能打散,功能模块互相解耦实现模块化开发,各业务模块间互不影响,通过管理后台即能实现实时动态更新与发布。

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

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

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

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