升级包生成优化：差分算法与压缩策略
升级包的大小，直接决定了升级耗时、网络流量和用户体验。我见过太多项目，固件功能做得挺好，结果升级包动辄几十兆，用户升级一次要等十几分钟——这谁受得了？
这一章，咱们就聊聊升级包生成阶段的两个核心问题：差分算法怎么选，压缩算法怎么配。说白了，就是怎么让升级包又小又稳。
差分算法：bsdiff vs hdiff
差分算法的本质，是找出新旧固件之间的差异，只传输变化的部分。你想想看，如果每次升级都传整个固件，那跟全量升级有什么区别？
目前主流的选择就两个：bsdiff 和 hdiff。我两个都在产品里用过，各有各的脾气。
| 对比维度 | bsdiff | hdiff |
|---|---|---|
| 算法原理 | 基于后缀排序，逐字节比较 | 基于哈希匹配，按块比较 |
| 差分率（典型值） | 5% ~ 15% | 8% ~ 20% |
| 内存消耗 | 高（约旧固件大小 × 5） | 低（约旧固件大小 × 1.2） |
| 生成速度 | 慢（适合服务器端预生成） | 快（适合本地或CI流水线） |
| 适用场景 | 小改动、大固件、追求极致压缩 | 频繁升级、资源受限环境 |
我的选择原则：
- 如果固件每次改动不大（比如修复几个bug），我首选 bsdiff，差分率能压到 5% 以下。
- 如果升级频繁，或者生成环境内存吃紧，我会用 hdiff，虽然包大一点，但生成速度快了不止一个量级。
一个小技巧： 我在项目中遇到过一种情况——新旧固件差异很大，bsdiff 和 hdiff 的差分率都超过 30%。这时候我干脆放弃差分，直接走全量压缩。你想想看，差分包比全量包还大，那差分还有什么意义？
压缩算法：zlib vs lzma
差分算法搞定的是「差异部分」，压缩算法负责把差异数据再「拧干」一遍。常用的就两个：zlib 和 lzma。
嗯，这里要注意——压缩算法不是越强越好，得看你的解压环境。
| 对比维度 | zlib (deflate) | lzma (xz) |
|---|---|---|
| 压缩率 | 中等（约 40% ~ 60%） | 高（约 30% ~ 50%） |
| 解压速度 | 快（适合MCU等低算力设备） | 慢（需要较多CPU和内存） |
| 内存占用（解压） | 约 32KB ~ 64KB | 约 256KB ~ 1MB |
| 固件体积增加 | 约 2KB ~ 4KB | 约 8KB ~ 16KB |
我曾经踩过的坑： 有一次在 STM32F103 上做升级，为了追求极致压缩率，我选了 lzma。结果解压时内存不够，直接死机。后来换成 zlib，虽然包大了 15%，但解压稳稳的。所以——先看设备资源，再选压缩算法，别为了省几 KB 的包大小，把稳定性搭进去。
增量包大小控制策略
差分算法和压缩算法选好了，接下来就是组合策略。我个人习惯把控制策略分成三个层次：
- 源头控制： 固件编译时去掉调试符号、未使用的函数、冗余数据。这一步做得好，差分率能降 10% ~ 20%。
- 差分控制： 根据改动幅度动态选择 bsdiff 或 hdiff。我建议在 CI 流水线里加一个判断逻辑——如果差分率 > 25%，自动切到全量压缩。
- 压缩控制： 根据目标设备算力选择 zlib 或 lzma。MCU 类设备无脑选 zlib，Linux 类设备可以上 lzma。
一个实用的组合方案：
- MCU 设备（如 STM32、ESP32）： hdiff + zlib，平衡速度与大小。
- Linux 设备（如路由器、摄像头）： bsdiff + lzma，追求极致压缩。
- 混合场景： 先 bsdiff，再判断差分率，如果 > 20% 则改用 hdiff，最后统一用 zlib 压缩。
下面这张图，是我在实际项目中总结的升级包生成流程，你可以参考一下：
我的经验之谈： 升级包优化不是一锤子买卖。我建议在 CI 流水线里加一个「升级包质量门禁」——每次构建都自动计算差分率、压缩率、包大小，如果超过阈值就告警。这样团队就能及时发现异常，而不是等到用户反馈升级太慢才去排查。
避坑指南
- 我曾经遇到过——差分算法在固件版本跨度大时失效。比如从 v1.0 直接升到 v3.0，中间跳过了 v2.0，差分率直接飙到 40% 以上。后来我加了一个策略：如果检测到版本跳跃超过 2 个主版本，自动走全量升级。
- 还有一次——压缩算法选对了，但解压缓冲区设得太小，导致解压失败。嗯，这里要注意：zlib 的默认窗口大小是 32KB，如果你的设备内存紧张，可以调小窗口，但压缩率会下降。
- 最后一点——别迷信「压缩率越高越好」。我见过有人为了把升级包压到极致，用了 lzma 的极限压缩模式，结果生成时间从 10 秒变成 10 分钟。你想想看，如果每次发布都要等 10 分钟，开发效率得有多低？