3、差分升级原理：差分算法、差分包生成与还原流程
好，咱们进入差分升级的核心环节。
说实话，差分升级是整个OTA系统里技术含量最高的部分之一。我最早接触这个是在2018年，当时一个客户抱怨说每次升级包都200多MB，车机网络又慢，用户等得直骂娘。嗯，那时候我就意识到，差分包不是「锦上添花」，而是「雪中送炭」。
3.1 什么是差分升级？
说白了，差分升级就是「只传变化的部分」。
你想想看，一个ECU的固件从v1.0升级到v1.1，可能只改了3%的代码。如果每次都传整个镜像，那剩下的97%都是浪费。差分升级就是通过算法对比新旧版本，生成一个很小的补丁包，设备端再把这个补丁应用到旧版本上，还原出新版本。
核心思想： 传输增量，而非全量。差分包大小通常只有全量包的5%~30%。
3.2 主流差分算法：bsdiff 与 hdiffpatch
目前业界用得最多的两个算法，一个是bsdiff，一个是hdiffpatch。我两个都用过，各有千秋。
3.2.1 bsdiff
bsdiff 是 Colin Percival 在2003年提出的，基于后缀排序（suffix sorting）的思想。它的核心逻辑是：
- 将旧文件和新文件都切成小块
- 找到旧文件中与新文件匹配的最长公共子串
- 只记录「新增」「删除」「修改」的部分
bsdiff 的压缩率非常优秀，尤其适合二进制文件。我在项目中遇到过用bsdiff把200MB的固件压缩到12MB的差分包，压缩率只有6%。
我的经验： bsdiff 对内存的消耗比较大。如果ECU的RAM只有256KB，跑bsdiff还原可能会撑爆。我曾经在一个资源受限的MCU上踩过这个坑，后来改用hdiffpatch才解决。
3.2.2 hdiffpatch
hdiffpatch 是 bsdiff 的改进版，由 J. van den Bos 等人开发。它最大的改进是：
- 使用了更高效的匹配算法，速度更快
- 内存占用更低，适合嵌入式环境
- 支持流式处理，不需要一次性加载整个文件
我个人的习惯是：如果目标设备是高性能的Linux车机（比如高通8155），我会用bsdiff，因为压缩率更好。如果是低端的MCU（比如Infineon TC3xx），我会用hdiffpatch，因为内存友好。
| 对比项 | bsdiff | hdiffpatch |
|---|---|---|
| 压缩率 | 更优（通常小5%~10%） | 良好 |
| 内存占用 | 高（需要加载整个文件） | 低（支持流式处理） |
| 执行速度 | 较慢 | 较快 |
| 适用场景 | 高性能设备 | 资源受限设备 |
3.3 差分包生成流程
差分包是在云端或者开发机上生成的。流程大致如下：
- 获取新旧版本镜像：旧版本是当前设备上跑的固件，新版本是要升级的目标固件。
- 对齐处理：有些算法要求文件按特定字节对齐，否则匹配率会下降。我一般会先做一次对齐预处理。
- 运行差分算法：调用bsdiff或hdiffpatch，生成差分包文件（通常后缀是.patch或.diff）。
- 压缩与签名：对差分包做gzip压缩，然后加上数字签名，防止篡改。
- 打包成OTA升级包：将差分包、元数据（版本号、校验值等）打包成一个完整的升级包。
这里有一个我踩过的坑：旧版本必须和设备上实际运行的版本完全一致。有一次客户说升级失败了，查了半天发现是设备上的固件被售后刷了一个小补丁，和云端记录的旧版本哈希对不上。差分包应用时直接崩溃。
警告： 差分升级对版本一致性要求极高。新旧版本的二进制必须精确匹配，哪怕一个字节的差异都会导致还原失败。建议在设备端做严格的版本校验。
3.4 差分包还原流程
还原流程是在设备端执行的。嗯，这里要注意，设备端的资源通常很有限，所以还原算法必须高效。
- 接收差分包：通过OTA下载通道获取差分包，先做完整性校验（CRC或哈希）。
- 解压与验签：解压gzip，验证数字签名，确保包没有被篡改。
- 加载旧版本镜像：从Flash中读取当前运行的固件，加载到内存中。
- 应用差分补丁：运行还原算法（bspatch或hpatch），将差分包应用到旧版本上，生成新版本镜像。
- 校验新版本：计算新版本镜像的哈希值，与云端记录的哈希对比。一致则通过。
- 写入Flash：将新版本镜像写入到备份分区或覆盖旧分区。
- 切换启动：更新启动引导参数，下次启动时加载新版本。
我曾经在一个项目里遇到过还原到第5步时校验失败的情况。排查下来发现是Flash读取时发生了ECC错误，导致旧版本数据有比特翻转。从那以后，我要求所有设备在读取旧版本时必须做ECC校验。
避坑指南： 还原过程中如果断电怎么办？我建议采用「双分区」策略：一个分区跑旧版本，另一个分区写入新版本。写入完成后才切换启动。这样即使断电，设备也能回滚到旧版本，不会变砖。
3.5 代码示例：bsdiff 生成与还原
下面是一个简单的bsdiff使用示例，在Linux环境下操作：
# 生成差分包
bsdiff old_firmware.bin new_firmware.bin update.patch
# 还原差分包
bspatch old_firmware.bin restored_firmware.bin update.patch
# 校验还原结果
sha256sum new_firmware.bin restored_firmware.bin
# 两个哈希值应该完全一致对于hdiffpatch，命令类似：
# 生成差分包
hdiffz old_firmware.bin new_firmware.bin update.hdiff
# 还原差分包
hpatchz old_firmware.bin update.hdiff restored_firmware.bin3.6 性能优化建议
最后，分享几个我在实际项目中总结的优化点：
- 分块差分：如果固件很大（比如超过100MB），建议分块处理。每块独立生成差分包，设备端可以并行还原，速度提升明显。
- 增量压缩：差分包本身还可以做增量压缩。我试过在bsdiff之后再加一层zstd压缩，包大小又减少了15%。
- 缓存旧版本特征：如果设备经常升级，可以在本地缓存旧版本的特征值（比如分块哈希），下次差分时直接复用，减少计算量。
- 回滚预案：差分升级失败时，一定要有回滚到全量升级的机制。我见过太多设备因为差分失败又没有回滚方案，最后只能返厂刷机。
好了，差分升级的原理就讲到这里。下一章我们会聊差分升级在实际部署中的坑，比如版本管理、兼容性测试、以及如何做灰度发布。到时候我会分享一个我亲身经历的「差点让十万台车趴窝」的故事。