差分升级原理：差分算法介绍

差分升级，说白了就是只传输新旧版本之间的差异部分。你想想看，一个固件包可能几十兆，但每次升级可能只改了几行代码。全量升级就像每次搬家都把所有家当搬一遍，而差分升级只搬那些变化的东西。

我最早接触差分升级是在一个智能家居项目里。设备通过2G网络升级，带宽窄得可怜。全量升级动不动就超时，用户投诉不断。后来换成差分方案，升级包从15MB压缩到几百KB，体验瞬间就上来了。

差分算法介绍

目前主流的差分算法有两个：bsdiff 和 hdiffpatch。它们各有各的脾气，我分别说说。

bsdiff

bsdiff 是 Colin Percival 在2003年提出的算法。它的核心思路是：利用后缀排序找到新旧文件的最长公共子串。说白了，就是找出哪些字节没变，哪些字节变了，变了的部分怎么从旧数据里拼接出来。

bsdiff 的压缩率非常优秀。我在一个嵌入式Linux项目里测试过，固件从v1.0升级到v1.1，全量包12MB，bsdiff生成的差分包只有800KB。压缩比达到15:1。

但 bsdiff 有个明显的短板——内存消耗大。它需要同时加载新旧两个文件到内存，还要构建后缀数组。对于256KB Flash的MCU来说，这基本不可能跑起来。

hdiffpatch

hdiffpatch 是 Google 推出的差分算法，专门为嵌入式场景优化。它的设计哲学是：用更少的内存，做更高效的差分。

hdiffpatch 采用分块匹配的策略。它把新旧文件切成固定大小的块，然后逐块比较。这样做的好处是内存占用可控，坏处是压缩率略低于 bsdiff。

我记得有一次，一个客户要求差分包必须能在 64KB RAM 的 MCU 上合成。bsdiff 直接出局，hdiffpatch 成了唯一选择。最终差分包大小比 bsdiff 大了约20%，但能在目标硬件上跑起来，这才是关键。

差分包的生成与合成

差分升级分为两个阶段：生成差分包（在服务器端完成）和 合成新固件（在设备端完成）。

生成差分包

生成差分包的命令很简单。以 bsdiff 为例：

# bsdiff 旧固件 新固件 差分包
bsdiff firmware_v1.0.bin firmware_v1.1.bin update.patch

hdiffpatch 的命令也类似：

# hdiffpatch 旧固件 新固件 差分包
hdiffpatch firmware_v1.0.bin firmware_v1.1.bin update.patch

这里有个坑，我踩过。差分包的生成必须在完全相同的编译环境下进行。有一次，我同事在Windows上编译了旧固件，在Linux上编译了新固件。结果两个版本明明代码只改了一行，差分包却大得离谱。原因就是编译器版本不同，导致二进制布局差异巨大。

合成新固件

设备端收到差分包后，需要和本地旧固件合成新固件。合成过程是生成过程的逆操作：

# bspatch 旧固件 差分包 新固件
bspatch firmware_v1.0.bin update.patch firmware_v1.1.bin

合成时要注意：设备必须有足够的临时存储空间。合成过程中，旧固件、差分包、新固件会同时存在。如果Flash空间不够，合成就会失败。

我习惯的做法是：先检查剩余空间是否大于「旧固件大小 + 差分包大小 + 新固件大小」的总和。如果不够，就提示用户清理空间，或者改用全量升级。

差分升级的优势与局限

差分升级不是万能的。它有明显的优势，也有硬伤。

优势

• 节省带宽：差分包通常只有全量包的5%-30%。对于NB-IoT、2G等窄带网络，这是质的飞跃。
• 降低流量成本：如果设备使用蜂窝网络，流量是按MB计费的。差分升级能直接省钱。
• 升级更快：数据量小了，传输时间自然缩短。用户等待时间从几分钟降到几十秒。
• 失败率降低：传输时间短，网络波动导致的中断概率也小。

局限

• 依赖旧版本：差分包只能从特定旧版本升级。如果设备跳版本升级（比如从v1.0直接升到v3.0），差分方案就失效了。
• 内存开销大：合成过程需要同时操作新旧两个固件。对于资源受限的MCU，这可能是个挑战。
• 编译环境敏感：前面说过，编译器版本、编译选项的微小变化都会导致差分包膨胀。
• 安全性风险：差分包被篡改后，合成出的新固件可能无法启动。需要配合签名校验使用。

嗯，差分升级的原理就这些。说白了，它就是个「找不同」的游戏。服务器端找出新旧固件的差异，设备端根据差异拼出新固件。选对算法、控制好环境、留足空间，这套方案就能跑得很稳。