4、升级包制作与差分升级：全量升级包与差分升级包原理、bsdiff/HDiffPatch等工具的使用与对比
在物联网终端OTA体系中，升级包的制作是整个链路中承上启下的关键环节。它直接决定了升级传输的流量成本、终端侧的资源消耗以及升级成功率。本章将深入剖析全量升级包与差分升级包的本质区别，重点讲解bsdiff与HDiffPatch两款主流差分工具的算法原理、适用场景与实战选型，帮助你在不同硬件约束下做出合理的技术决策。
4.1 全量升级包与差分升级包的核心原理
全量升级包是指将整个新版本固件镜像完整打包，终端收到后直接擦除旧版本分区并写入新镜像。其优点是逻辑简单、不依赖旧版本状态，适合首次烧录、跨大版本升级或旧版本碎片化严重的场景。但缺点是包体大，在NB-IoT、2G/3G等低带宽网络中传输时间长，且对终端存储空间要求高。
差分升级包则只包含新旧版本之间的差异数据。终端在本地已有旧版本固件的基础上，通过差分算法将旧版本“修补”为新版本。差分包体积通常只有全量包的10%~30%，能显著降低传输流量和升级耗时。但差分升级要求终端必须持有与生成差分包时完全一致的旧版本，否则无法正确合并。
4.2 bsdiff与HDiffPatch工具深度对比
bsdiff是经典的二进制差分工具，由Colin Percival于2003年提出，基于后缀排序算法（suffix sorting）和贪心匹配策略。它能够找到新旧文件之间最长的公共子串，生成高效的补丁文件。bsdiff在生成补丁时内存占用较高，约为旧文件大小的17倍，但在终端合并补丁时内存占用相对较低（约旧文件大小的8倍）。
HDiffPatch是近年来兴起的开源差分工具，采用哈希索引与滚动哈希匹配算法，显著降低了内存占用。生成补丁时内存约为旧文件的2~3倍，合并时内存约为旧文件的1.5倍。虽然压缩率略低于bsdiff，但在资源受限的嵌入式设备上表现更优。
| 对比维度 | bsdiff | HDiffPatch |
|---|---|---|
| 算法基础 | 后缀排序 + 贪心匹配 | 哈希索引 + 滚动匹配 |
| 生成补丁内存 | 约旧文件17倍 | 约旧文件2~3倍 |
| 合并补丁内存 | 约旧文件8倍 | 约旧文件1.5倍 |
| 压缩率 | 较高（尤其代码/文本） | 略低（约差5%~10%） |
| 适用平台 | PC/服务器/内存充足设备 | MCU/嵌入式/内存受限设备 |
| 跨平台支持 | Linux/Windows/macOS | Linux/Windows/RTOS/裸机 |
| 大文件支持 | 一般（超过2GB需特殊处理） | 优秀（支持GB级文件） |
4.3 差分升级包制作流程与实战操作
差分升级包的制作流程通常包含以下步骤：
- 版本基线管理：在云端维护每个终端当前运行的固件版本号，确保差分包基于正确的旧版本生成。
- 生成差分补丁：使用bsdiff或HDiffPatch工具，以旧版本固件为基准，生成新版本固件的补丁文件。
- 补丁压缩与加密：对补丁文件进行二次压缩（如gzip、lzma），并添加数字签名，防止篡改。
- 打包与元数据写入：将补丁文件、目标版本号、源版本号、校验值等信息封装为升级包。
- 下发与终端合并：终端下载升级包后，使用对应的合并工具将补丁应用到本地旧版本固件上。
# 使用bsdiff生成差分补丁（在PC端执行）
bsdiff old_firmware_v1.0.bin new_firmware_v2.0.bin patch_v1_to_v2.bsdiff
# 使用HDiffPatch生成差分补丁
hdiffpatch old_firmware_v1.0.bin new_firmware_v2.0.bin patch_v1_to_v2.hdiff
# 终端侧合并补丁（在设备端执行）
bspatch old_firmware_v1.0.bin new_firmware_v2.0.bin patch_v1_to_v2.bsdiff
hdiffpatch old_firmware_v1.0.bin new_firmware_v2.0.bin patch_v1_to_v2.hdiff4.4 案例拆解：某智能水表NB-IoT差分升级实战
背景与约束：某智能水表采用NB-IoT通信模组（BC26），Flash容量为1MB，其中固件分区为512KB。当前运行版本V1.0，需升级至V2.0（新增漏损检测算法）。NB-IoT网络下行速率约20kbps，单次传输超过200KB的数据包容易导致连接超时。
初始现象与目标：若采用全量升级包（V2.0固件约480KB），预计传输耗时超过3分钟，且终端Flash剩余空间不足（仅剩约100KB），无法暂存全量包。目标是将升级包控制在100KB以内，并确保升级成功率不低于95%。
关键输入数据：V1.0固件大小460KB，V2.0固件大小480KB，两者差异主要集中在新增的算法模块和配置参数调整。
分析判断过程：对比bsdiff与HDiffPatch在ARM Cortex-M4平台上的表现。bsdiff生成补丁约85KB，但合并时需要约3.7MB内存（460KB×8），超出BC26模组可用RAM（约256KB）。HDiffPatch生成补丁约95KB，合并时仅需约700KB内存（460KB×1.5），可通过分块合并方式在256KB RAM内完成。
实际操作步骤：
- 在云端使用HDiffPatch生成V1.0→V2.0的差分补丁，体积为95KB。
- 对补丁进行LZMA二次压缩，压缩后体积降至72KB。
- 添加SHA-256校验值和RSA签名，最终升级包体积为73KB。
- 终端下载升级包后，采用分块合并策略（每块32KB），边下载边合并，最终成功生成V2.0固件。
结果对比：升级包从480KB降至73KB，传输耗时从约3分钟缩短至约30秒，升级成功率从全量方案的91%提升至98.5%。
风险与代价：差分升级要求终端必须保留旧版本固件直到合并完成，若合并过程中断电可能导致固件损坏。为此增加了双备份机制（A/B分区），代价是Flash占用增加一倍。
复盘经验：在资源受限设备上，差分算法的内存占用比压缩率更重要。HDiffPatch虽然补丁略大，但能在低内存设备上稳定运行，是MCU类终端的首选。
4.5 常见误区与总结复盘
误区一：认为差分升级一定比全量升级好。实际上，当新旧版本差异较大（如跨多个大版本）时，差分补丁可能接近甚至超过全量包体积，此时全量升级更划算。
误区二：忽略终端合并时的内存峰值。bsdiff虽然补丁小，但合并时内存需求高，在低端MCU上可能直接导致系统崩溃。选型时必须同时评估生成端和合并端的资源消耗。
误区三：不进行补丁的二次压缩。差分补丁本身可能包含大量重复模式，使用LZMA或zstd二次压缩通常能再减小20%~40%的体积。
误区四：缺乏版本回退机制。差分升级失败后，终端可能处于不可用状态。必须设计回退策略，例如保留旧版本分区或提供紧急全量恢复通道。