4. 差分升级算法：bsdiff/bspatch 原理与实战选型
差分升级，说白了就是只传变化的部分。你想想看，一个固件 20MB，每次只改了几百 KB 的代码，却要整包下载，这在物联网设备上简直是灾难。我最早做智能电表 OTA 时，就吃过这个亏——2G 网络下，20MB 的包要传半小时，用户早把电闸拉了。
所以这一章，我们重点聊 bsdiff/bspatch。这是目前嵌入式领域最主流的差分算法，没有之一。
4.1 bsdiff/bspatch 核心原理
bsdiff 的思路其实很朴素：它把新旧两个二进制文件做对比，找出「相同块」和「差异块」。相同块直接引用旧文件的位置，差异块则用压缩算法存起来。最终生成的增量包，通常只有原包大小的 5%~15%。
具体来说，bsdiff 做了三件事：
- 后缀排序：对新旧文件做后缀数组排序，快速定位最长公共子串。
- 差异编码：对不匹配的字节，用 bzip2 压缩差异数据。
- 控制块生成：记录「从哪里复制、从哪里插入」的指令序列。
我习惯把增量包的结构画成下面这张图，方便团队理解：
关键指标：bsdiff 生成的增量包大小，通常只有全量包的 5%~15%。对于 20MB 的固件，增量包可能只有 1~3MB。这意味着下载时间从 30 分钟缩短到 3 分钟。
4.2 bspatch 还原过程
bspatch 是设备端负责还原的算法。它读取增量包中的控制块，按指令从旧固件复制数据，再插入差异数据，最终拼出新固件。整个过程不需要解压整个旧固件，只需要按顺序流式处理。
伪代码大概长这样：
// bspatch 核心逻辑（简化版）
while (控制块未读完) {
// 1. 从旧固件复制 len 字节到新固件
memcpy(new_pos, old_pos, ctrl_len);
new_pos += ctrl_len;
old_pos += ctrl_len;
// 2. 从差异数据插入 len 字节
memcpy(new_pos, diff_data, diff_len);
new_pos += diff_len;
// 3. 跳过旧固件中的额外数据
old_pos += extra_len;
}嗯，这里要注意：bspatch 的内存开销主要来自两个缓冲区——一个放旧固件，一个放新固件。对于资源受限的 MCU，这可能是致命的。
避坑指南：我曾经在一个 STM32F4 项目上直接移植 bspatch，结果发现 RAM 不够。标准 bspatch 需要同时加载旧固件和新固件，对于 1MB 的固件，至少需要 2MB RAM。后来我改用流式 bspatch，每次只处理 4KB 的窗口，才把内存压到 8KB 以内。
4.3 内存与带宽优化策略
在实际项目中，内存和带宽往往是矛盾的。你省了带宽，就得花内存；你省了内存，带宽就上去了。我一般按这个优先级做取舍：
| 优化方向 | 方法 | 效果 | 适用场景 |
|---|---|---|---|
| 带宽优先 | bsdiff 全量差分 + bzip2 压缩 | 增量包最小，带宽节省 90% | NB-IoT、卫星通信等窄带场景 |
| 内存优先 | 滑动窗口差分 + 流式还原 | RAM 占用 < 16KB | MCU、RTOS 设备 |
| 平衡方案 | 分块差分 + 块级缓存 | 增量包中等，RAM 可控 | Linux 网关、边缘计算节点 |
我个人的经验是：先看设备 RAM 上限，再选差分策略。如果 RAM 只有 64KB，就别想跑标准 bspatch 了，老老实实用分块方案。
实用技巧：对于 Flash 资源紧张但 RAM 相对充裕的设备（比如 ESP32），可以把旧固件放在外部 SPI Flash 中，通过 XIP（就地执行）方式直接读取，这样就不需要把整个旧固件加载到 RAM 了。我在一个智能音箱项目上用过这招，效果很好。
4.4 实际项目中的选型经验
选型这件事，没有银弹。我列几个真实场景，你对照着看：
- 场景一：NB-IoT 水表——带宽极窄，每次传输成本高。选 bsdiff + 强压缩，增量包控制在 50KB 以内。代价是设备端需要 128KB RAM 做还原缓冲区。
- 场景二：蓝牙 Mesh 灯控——RAM 只有 16KB，Flash 256KB。用不了标准 bspatch，我改用了 hdiffpatch（Google 的差分库），支持流式还原，RAM 占用降到 4KB。
- 场景三：Linux 工业网关——资源充裕，直接上 bsdiff。但要注意，bsdiff 生成增量包时内存消耗很大（旧固件 10 倍以上），所以生成端要在服务器上跑，不能在设备端。
说到选型，我踩过一个坑：有一次在车载 T-Box 项目上，我直接用了 bsdiff 的默认参数，结果增量包生成时间长达 15 分钟。后来发现是旧固件和新固件差异太大（换了文件系统），差分算法几乎在逐字节对比。解决方案是：先做二进制对齐，再做差分。把新旧固件按 4KB 对齐，差异区域大幅减少，生成时间降到 30 秒。
选型决策树：
- 设备 RAM > 2× 固件大小 → 标准 bsdiff/bspatch
- 设备 RAM < 2× 固件大小但 > 64KB → 分块差分 + 流式还原
- 设备 RAM < 64KB → hdiffpatch 或自定义轻量差分
- 带宽极度受限 → bsdiff + 二次压缩（如 lzma）
4.5 差分升级的局限性
最后说点实在的。差分升级不是万能的，它有几个硬伤：
- 版本跳跃：如果设备从 v1.0 直接升到 v3.0，中间跨了多个版本，差分算法会失效。因为 v1.0 和 v3.0 的差异太大，增量包可能比全量包还大。
- 安全校验：差分包本身是二进制补丁，容易被篡改。我习惯在差分包外层再加一层签名和哈希校验，确保补丁的完整性。
- 回滚问题：如果升级失败，设备需要回滚到旧版本。差分升级的回滚逻辑比全量升级复杂得多，因为旧固件可能已经被覆盖了。
我的建议是：差分升级只做相邻版本的小幅更新。跨版本升级时，老老实实用全量包。别为了省那点带宽，把系统稳定性搭进去。