2、差分升级原理：什么是差分升级？bsdiff/bspatch算法简介
好，咱们进入正题。差分升级，说白了就是——只传变化的部分。
你想想看，一个固件包动不动几十兆，每次升级都全量下载，带宽扛不住，用户流量也心疼。我早年做智能音箱项目时，OTA升级包有32MB，用户用4G网络下载，一个月下来流量费比产品利润还高……后来换了差分升级，包体直接缩到3MB以内，体验瞬间好了。
2.1 什么是差分升级？
差分升级的核心思想很简单：
- 设备上已经有一个旧版本固件（比如 v1.0）
- 云端有一个新版本固件（比如 v2.0）
- 我们不直接下发 v2.0 完整包，而是生成一个「补丁包」
- 设备拿到补丁包后，在本地用旧固件 + 补丁，合成出新固件
这个补丁包，就是「差分」的结果。它只记录了新旧版本之间的差异。
关键点：差分升级不是压缩，而是「只传变化」。压缩是把包变小，差分是只传差异部分。两者可以叠加使用。
我在项目中遇到过一种情况：客户说他们的固件每次只改了几行代码，但全量包却有20MB。用了差分后，补丁包经常只有几百KB。嗯，这就是差分升级的价值所在。
2.2 差分升级的工作流程
整个流程分三步走：
- 生成差分补丁（服务端）：拿旧版本和新版本做对比，生成一个 .patch 文件
- 下发补丁（网络传输）：把 .patch 文件推送到设备端
- 本地合成（设备端）：设备用旧固件 + .patch 文件，通过算法还原出新固件
这里有个容易踩的坑——旧版本必须严格匹配。我曾经遇到过设备上报的版本号是 v1.0，但实际跑的是 v1.0-hotfix，结果差分补丁打上去直接变砖。所以，版本校验一定要做哈希比对，不能只看版本号字符串。
警告：差分升级对版本一致性要求极高。旧固件哪怕有一个字节不同，合成出来的新固件就是坏的。务必在合成前做完整性校验。
2.3 bsdiff/bspatch 算法简介
说到差分算法，绕不开两个名字：bsdiff 和 bspatch。
bsdiff 是 Colin Percival 在2003年提出的算法，专门针对二进制文件做差分。它有几个特点：
- 基于 后缀排序 技术，能高效找到两个文件中的相同片段
- 生成的补丁包非常小，尤其适合固件这种二进制文件
- 时间复杂度 O(n log n)，空间占用较大（约原文件大小的 5-8 倍）
bspatch 是对应的合成算法，负责在设备端把旧固件和补丁包合并成新固件。它的特点是：
- 时间复杂度 O(n)，空间占用约 O(n)
- 对设备内存有一定要求，嵌入式设备上需要谨慎
个人建议：如果你的设备内存只有几百KB，bsdiff 的合成过程可能会撑爆。我一般会建议在设备端做内存预算，确保 bspatch 运行时不会和其他任务抢资源。
2.4 bsdiff 的核心原理（通俗版）
bsdiff 到底是怎么工作的？我尽量用大白话讲清楚：
- 扫描旧文件：把旧文件的所有子串建成一个「字典」（后缀数组）
- 匹配新文件：拿着新文件的每个片段，去字典里找最长的匹配
- 记录差异：匹配上的部分记「从哪里复制」，没匹配上的部分记「新增的字节」
- 输出补丁：把复制指令和新增数据打包成 .patch 文件
说白了，bsdiff 就是在做一件事：找出新旧文件里相同的部分，只记录不同的部分。
举个例子：
旧固件: [A][B][C][D][E][F]
新固件: [A][B][X][D][E][Y]
bsdiff 生成的补丁：
- 复制 0-1 位置（A、B）
- 新增 X（替换 C）
- 复制 3-4 位置（D、E）
- 新增 Y（替换 F）
你看，补丁里只记录了「替换 C 为 X」和「替换 F 为 Y」，其他部分直接复用旧固件。这就是差分升级省流量的秘密。
2.5 bsdiff 的优缺点
| 优点 | 缺点 |
|---|---|
| 补丁包极小，通常只有全量包的 5%-20% | 生成补丁时内存占用大（约 5-8 倍文件大小） |
| 算法成熟，社区广泛使用 | 合成时也需要较多内存（约 1-2 倍文件大小） |
| 支持任意二进制文件 | 对版本跳跃较大的场景效果不佳 |
| 开源免费，移植方便 | 合成速度受限于设备 CPU 性能 |
经验之谈：bsdiff 最适合「小步快跑」的升级场景。如果两个版本之间改动很大（比如重构了底层驱动），差分效果会大打折扣。我一般建议版本跨度不要超过 3 个迭代，否则补丁包大小可能接近全量包。
2.6 嵌入式设备上的注意事项
在嵌入式设备上用 bsdiff/bspatch，有几个坑必须提前知道：
- 内存限制：bspatch 需要把旧固件整个加载到内存里。如果你的设备只有 512KB RAM，但固件有 2MB，那就没法直接跑。解决方案是「分块合成」或「外挂 Flash 缓存」。
- 文件系统支持：合成过程中需要读写临时文件。如果设备用的是 SPI Flash 直存，没有文件系统，那就得自己实现读写接口。
- 掉电保护：合成到一半断电怎么办？我踩过这个坑——设备重启后旧固件被覆盖了一半，直接变砖。后来我加了三段式备份策略：先备份旧固件，再合成新固件，最后校验通过才覆盖。
避坑指南：我曾经在一个低端 MCU 项目上直接移植了 bspatch 的 C 源码，结果发现 malloc 分配内存失败。后来改用静态数组 + 分块处理才搞定。嵌入式移植一定要先做内存评估。
2.7 什么时候该用差分升级？
不是所有场景都适合差分升级。我个人的判断标准是：
- 适合：固件体积大（>1MB）、升级频繁、网络带宽有限、用户流量敏感
- 不适合：固件体积小（<100KB）、升级频率极低、设备内存极度受限
举个例子：智能门锁的固件只有 200KB，全量下载也就几秒钟，用差分反而增加了复杂度。但如果是车载娱乐系统，固件 2GB，差分升级能省下 1.8GB 的流量，那就非常值得。
我的建议：做技术选型时，先算一笔账——差分升级节省的流量成本，是否大于开发和维护差分系统的成本？如果答案是肯定的，那就上。
好了，这一章我们聊了差分升级的基本原理和 bsdiff/bspatch 的核心思路。下一章我会深入讲 bsdiff 的算法细节，包括后缀数组是怎么构建的，以及如何优化嵌入式环境下的内存占用。到时候见。