android 热补丁 增量更新 区别,APP技术之热补丁与增量更新

热补丁与增量更新技术在 APP 中是比较常见的，作为移动端产品的产品经理，应该对这些技术有一些大致的了解。

热补丁技术

定义

热补丁修复技术可以做到线上推送一段修补 BUG 的代码，终端无需更新版本直接运行，可以做到在用户无感知的情况下，修复问题。

该技术避免了当 App 发布之后，突然发现 bug 需要进行紧急修复时需要完成的重新打包 App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装等一系列复杂的操作。

原理

Android

热补丁修复技术基于的是 android dex 分包方案。我们都知道 andriod 的安装文件是 APK 文件，APK 文件中包含了软件的信息(版本号等)、dex 文件(就是程序员的代码)、res 文件夹(设计师的文件，包括切图、动效等)。

那么为什么 dex 分包呢？当一个 APP 的功能越来越复杂，代码量越来越多时程序的编译会出现错误，会出现 APK 文件无法安装的情况。出现这些问题主要是因为一个 dex 文件最多只支持 65536 个方法，如果一个复杂的 APP 全部写在一个 dex 文件中，肯定会超载。所以要对 dex 进行分包，dex 文件就是代码的集合。

热补丁原理，简单的概括一下，就是把多个 dex 文件塞入到 APP 的 Classloader(通过这个类来实现 dex 的分包，大家都知道什么叫类吧 ~)之中。每个 dex 文件是一个对象，多个 dex 文件排列成一个有序的数组，当程序执行的时候，会按顺序遍历 dex 文件，然后从当前遍历的 dex 文件中找相应功能的类，如果找则返回，如果找不到从下一个 dex 文件继续查找。

那么这样的话，可以在这个数组中的第一个元素放置格式为 .jar 的文件，里面包含修复过功能的类，这样的话，当程序遍历的时候，修复过功能的类就会被率先查找到，从而替代有 bug 的类。

原理如下图：

iOS

iOS 主要是使用 JSPatch 来实现热补丁修复，在项目中引入 JSPathc，然后在发现 bug 时下发 JS 脚本补丁，替换原生方法，以此实现无需更新 APP 即时修复 bug。

主要实现流程：当客户端出现 bug 时，iOS 开发人员需要开发一段 JS 脚本用于修复 bug，脚本开发完成后，服务端开发人员根据 iOS 开发人员提供的 JS 脚本部进行一定的安全策略部署服务端脚本，iOS 客户端通过脚本版本检测接口，判断是否需要下载 JS 脚本，下载脚本成功后，进行加载，运行，进而修复 APP 的 bug。

APP 端流程如下：

其中，客户端与服务端在获取 JS 脚本时会进行安全校验，防止过程中被攻击替换代码，安全校验的简单流程：a. 服务端对 JS 脚本文件生成一个 MD5(文件的唯一标识)值并加密—— b. 将加密的 MD5 值与 JS 脚本传给客户端—— c. 客户端对拿到的脚本文件计算 MD5 值，且对加密的 MD5 值进行解密—— d. 客户端对比计算出的 MD5 值与解密后的 MD5 值—— e. 两个 MD5 数值相等则通过校验。

热补丁技术不仅可以用来修复 bug 打补丁，还可以在线更新代码添加新需求哦！

增量更新技术

定义

增量更新是指在进行更新操作时，只更新需要改变的地方，不需要更新或者已经更新过的地方则不会重复更新。也就是，只将 App 中有发生改变的部分发送给用户，而不是每次都重新下载一个完整的安装包。

原理

生成差异包。将 App 的最新安装包 ( V2 ) 与历史发布版本的安装包 ( V1 ) 进行差分对比，得到一个差异包 ( V2-V1 ) 。

下发差异包。当某个老版本 ( V1 ) 的 App 开始检查更新的时候，需要将自己当前的版本信息发送给服务端，然后服务端判断后，选择对应的差异包 ( V2-V1 ) 下发。

合成新包。

校验完整性。校验当前历史包的 Hash 值以及差异包的 Hash(哈希值是一段数据唯一的数值表示形式)值，合成新包后，也要校验新包的 Hash 值，只有这三个 Hash 值都与预期匹配，才可以确认新包是完整的。

增量更新的注意点：

增量更新是以两个应用版本之间的差异来生成补丁的，无法保证用户每次及时升级到最新，所以必须对所发布的每一个版本都和最新的版本作差分，以使所有版本的用户都可以差分升级，这样操作较为繁琐，不过可以通过脚本批量生成。

增量更新成功的前提是，用户手机端必须有能够被拷贝出来且与服务器用于差分的版本一致的 APK 文件，这样就会造成一些情况，例如，系统内置的 APK 无法获取到，则无法进行增量更新。

以上，就是对热补丁修复技术与增量更新技术的小总结，希望对大家能有所帮助。

作者：流年，互联网产品设计师，4 年互联网产品设计经验。

本文由 @流年 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 unsplash，基于 CC0 协议