4. 增量升级分区策略：差分分区设计、增量包存储策略、版本链管理

好，咱们进入第四章。增量升级，说白了就是「只传变化的部分」。你想想看，一个固件 10MB，每次只改了几百 KB 的代码，却要全量重传，这在量产阶段简直是灾难。我在早期做智能家居项目时，就吃过这个亏——设备通过 2G 网络升级，全量包传一次要半小时，用户早把电源拔了。

所以这一章，我们重点聊三个东西：差分分区怎么设计、增量包怎么存、版本链怎么管。嗯，都是实战里绕不开的坑。

4.1 差分分区设计：给「变化」留好位置

差分升级的核心思路，是让系统能快速定位「旧版本」和「新版本」的差异，然后只更新差异部分。这要求分区表在设计之初，就为差分操作预留好空间。

我个人习惯把差分分区分为三类：

• 基础分区（Base Slot）：存放当前运行的完整固件。这是差分计算的基准。
• 差分暂存区（Delta Scratch）：存放下载下来的增量包。这个分区不需要太大，但必须保证写入可靠。
• 目标分区（Target Slot）：存放重组后的新固件。差分升级完成后，这里就是新的运行区。

来看一个典型的差分分区布局：

// 差分分区表示例（基于 MCU 平台）
// 假设 Flash 总大小 2MB

| 分区名称          | 起始地址   | 大小     | 用途                     |
|-------------------|------------|----------|--------------------------|
| bootloader        | 0x000000   | 64KB     | 引导加载程序             |
| base_slot_a       | 0x010000   | 768KB    | 基础固件 A 槽            |
| base_slot_b       | 0x0D0000   | 768KB    | 基础固件 B 槽（备用）    |
| delta_scratch     | 0x190000   | 256KB    | 差分暂存区               |
| version_chain     | 0x1D0000   | 64KB     | 版本链存储区             |
| config            | 0x1E0000   | 128KB    | 配置参数区               |

这里我用了 A/B 双槽 + 差分暂存区的组合。为什么这么设计？因为差分升级最怕「升级到一半断电」。有了双槽，你可以在后台重组新固件，重组完成后再切换启动。嗯，这就是所谓的「安全差分升级」。

4.2 增量包存储策略：怎么存、存哪里、存多久

增量包本身是个二进制差分文件，通常由工具（如 bsdiff、xdelta）生成。但存到设备上时，有几个问题必须想清楚：

1. 存哪里？——差分暂存区还是外部存储？
2. 存多久？——升级完成后要不要保留？
3. 怎么校验？——下载过程中损坏了怎么办？

我建议的存储策略是这样的：

• 优先存到内部差分暂存区。速度快，不受外部存储故障影响。但如果增量包太大（比如超过 512KB），可以考虑存到外部 SPI Flash 或 SD 卡。
• 升级完成后立即删除增量包。除非你需要支持「回滚到上一个版本」，否则留着只会浪费空间。
• 边下载边校验。每收到一个数据块，就计算 CRC32 或 SHA256，跟包头的校验值比对。我曾经遇到过一个项目，下载完才校验，结果 99% 时网络断了，整个包作废——用户得重新下载。

增量包的典型结构：

// 增量包头部结构（示例）
typedef struct {
    uint32_t magic;             // 魔数，用于识别
    uint32_t header_crc;        // 头部校验
    uint32_t payload_crc;       // 数据体校验
    uint32_t source_version;    // 源版本号
    uint32_t target_version;    // 目标版本号
    uint8_t  source_hash[32];   // 源固件 SHA256
    uint8_t  target_hash[32];   // 目标固件 SHA256
    uint32_t payload_size;      // 差分数据大小
    uint32_t patch_type;        // 差分算法类型
} delta_header_t;

4.3 版本链管理：别让设备「失忆」

版本链，说白了就是记录设备「从哪个版本升到了哪个版本」。这玩意儿平时看着没用，但一旦出问题，它就是救命稻草。

我在一个工业网关项目里遇到过这种情况：设备连续升级了三次，第四次升级失败，需要回滚。但因为没有版本链，根本不知道之前装的是哪个版本——最后只能全量重刷，现场工程师跑了一整天。

从那以后，我设计的每个系统都强制包含版本链管理。核心要素就三个：

• 版本号：建议用主版本.次版本.修订号，比如 2.1.3。
• 升级记录：每次升级成功后，追加一条记录，包含源版本、目标版本、时间戳、校验值。
• 回滚指针：指向可回滚的上一版本。如果支持多级回滚，可以用链表结构。

版本链的存储结构：

// 版本链记录（存储在 version_chain 分区）
typedef struct {
    uint32_t record_count;              // 总记录数
    version_record_t records[16];       // 最多保留 16 条历史
    uint32_t rollback_index;            // 当前回滚目标索引
} version_chain_t;

typedef struct {
    uint32_t source_version;
    uint32_t target_version;
    uint32_t timestamp;
    uint8_t  firmware_hash[32];         // 升级后固件的哈希
    uint8_t  status;                    // 0=成功, 1=失败, 2=回滚
} version_record_t;

4.4 差分升级的核心流程

把上面三个部分串起来，就是完整的差分升级流程。我画了一张图，帮你理清逻辑：

这个流程里，最容易被忽略的是「验证新固件完整性」这一步。很多人觉得增量包校验过了，重组出来的固件肯定没问题。其实不然——重组过程中，如果内存有比特翻转，或者差分算法有边界 bug，重组出来的固件可能跟预期不一样。所以，重组完成后，一定要用版本链里记录的哈希值做一次全量校验。

4.5 避坑指南：我踩过的几个雷

最后，分享几个实战中遇到的坑，希望能帮你少走弯路：

• 差分算法选择不当：bsdiff 适合二进制差异，xdelta 适合文件级差异。我曾在 RTOS 上用 bsdiff 处理 512KB 的固件，结果差分包比全量包还大——因为固件里地址重定位导致大量伪差异。后来改用按段差分，才解决问题。
• 暂存区写满不处理：增量包下载到 99% 时，暂存区满了。如果不做「边下载边重组」，就只能报错。我建议在下载到 80% 时就开始后台重组，这样能有效利用空间。
• 版本链不防写穿：版本链分区写满后，如果没有循环覆盖机制，后续升级会直接失败。记得在驱动层做「写前检查」，满了就擦除最旧的记录。
• 回滚时忘记校验：回滚操作本质上是「反向差分升级」。回滚前一定要校验目标版本的完整性，否则可能回滚到一个损坏的固件。