4、固件与镜像管理：版本号、文件格式与升级策略
好，咱们进入第四个章节。固件与镜像管理，这名字听起来挺唬人，说白了就是你怎么管好你手里的那堆二进制文件。我刚开始做OTA的时候，觉得这玩意儿有啥好管的？不就是个文件嘛。后来吃过亏才明白，版本号写错一个字符，镜像格式搞错一个字节，都能让你在产线上哭都哭不出来。
4.1 固件版本号管理：别让版本号成为你的噩梦
版本号这东西，看着简单，坑却不少。我个人习惯用三段式版本号：主版本号.次版本号.修订号。比如 V2.1.3。
- 主版本号：大功能变更，不兼容旧版时加1。比如从V1跳到V2。
- 次版本号：新增功能，但向后兼容。比如V2.0到V2.1。
- 修订号：Bug修复、小优化。比如V2.1.0到V2.1.3。
我在项目中遇到过一个问题：测试组拿到的固件版本号是 V2.1.3-beta，结果生产环境里有个设备死活不认这个版本号，因为它只认纯数字。嗯，这里要注意：版本号里尽量不要带字母或特殊符号，除非你的解析逻辑能兜住。
避坑指南：我曾经在版本号里加了个下划线，结果OTA服务器解析失败，整批设备都卡在升级界面。从那以后，我强制团队用 V{major}.{minor}.{patch} 这种纯数字格式，最多加个构建号 _build{num}。
你想想看，如果版本号管理混乱，你怎么知道设备当前跑的是哪个版本？差分升级时又该拿哪个版本做基准？所以，版本号是OTA的基石，别马虎。
4.2 镜像文件格式：你手里的文件到底是什么？
镜像文件，就是固件的“打包形态”。常见的格式有这几种：
| 格式 | 说明 | 典型场景 |
|---|---|---|
.bin |
纯二进制，无头信息，直接烧录 | MCU、低端芯片 |
.hex |
Intel HEX格式，带地址信息 | 单片机、Bootloader |
.img |
Android/嵌入式系统镜像 | 系统分区、Recovery |
.tar.gz |
压缩包，包含多个文件 | Linux系统、应用层升级 |
.swu |
SWUpdate专用格式 | 嵌入式Linux OTA |
我个人最常用的是 .bin 和 .swu。为什么？.bin 简单直接，适合小设备；.swu 自带校验和描述信息，适合复杂系统。
举个例子，一个典型的 .swu 文件结构是这样的：
my_firmware.swu
├── sw-description # 描述文件（XML/JSON）
├── rootfs.ext4.gz # 根文件系统压缩包
├── kernel.itb # 内核镜像
└── boot.scr # 启动脚本这里要注意：描述文件里必须包含版本号、校验和、目标设备ID。我曾经见过一个团队，描述文件里忘了写设备ID，结果A设备的固件刷到了B设备上，直接变砖。
我的小技巧：在镜像文件头部加一个自定义的魔数（Magic Number），比如 0xOTA2024。这样设备在接收镜像时，先检查魔数，不对就直接拒绝，省得后面解析出错。
4.3 差分升级原理：只传变化的部分
全量升级是把整个固件包传过去，差分升级只传“变化的部分”。说白了，就是拿旧版本和新版本做对比，生成一个补丁文件。设备收到补丁后，自己打上，就变成新版本了。
为什么会这样？因为全量升级太费流量了。一个固件包可能50MB，差分补丁可能只有5MB。对于物联网设备来说，流量就是钱啊。
差分升级的核心算法是 bsdiff 和 bspatch。流程如下：
- 生成差分补丁：在服务器端，用
bsdiff old_firmware.bin new_firmware.bin patch.bin生成补丁。 - 传输补丁：设备下载
patch.bin。 - 应用补丁：设备上运行
bspatch old_firmware.bin new_firmware.bin patch.bin，生成新固件。 - 校验并升级：校验新固件的完整性，然后写入Flash。
我在项目中遇到过一个问题：差分补丁应用失败。排查了半天，发现是设备上的旧固件和服务器上生成补丁时用的旧固件不一致——哪怕差一个字节，补丁都打不上。嗯，这里要注意：差分升级对版本一致性要求极高。
警告：差分升级不是万能的。如果新旧版本差异太大（比如换了文件系统），补丁文件可能比全量包还大。这时候就别用差分了，直接全量吧。
4.4 全量升级与增量升级：什么时候用哪个？
全量升级和增量升级，其实就是差分升级的两种应用场景。
| 特性 | 全量升级 | 增量升级（差分） |
|---|---|---|
| 传输数据量 | 大（整个固件包） | 小（仅补丁） |
| 升级成功率 | 高（独立性强） | 中等（依赖旧版本） |
| 适用场景 | 首次升级、跨大版本 | 小版本迭代、Bug修复 |
| 设备资源消耗 | 低（直接写入） | 高（需要计算和临时存储） |
我个人习惯这样选：
- 首次升级或跨大版本：用全量。因为旧版本可能太老，差分补丁根本打不上。
- 小版本迭代：用增量。比如从V2.1.0到V2.1.1，改了几个Bug，差分补丁可能只有几百KB。
- 关键安全更新：用全量。确保设备能完整替换，不留隐患。
你想想看，如果一个设备从V1.0直接升级到V2.0，中间隔了十几个版本，你总不能让它一个一个打补丁吧？那得打到猴年马月去。所以，全量升级是兜底方案，增量升级是效率方案。
避坑指南：我曾经在增量升级时，忘了考虑设备掉电的情况。结果补丁打到一半断电了，设备既不是旧版本也不是新版本，直接变砖。从那以后，我强制要求：增量升级必须做双备份，一个分区跑旧固件，一个分区打补丁，打完了再切换。
好了，这一章的内容就这些。版本号管理、镜像格式、差分原理、全量与增量选择，这些都是OTA的硬功夫。下一章咱们聊聊升级策略和回滚机制，那才是真正考验设计能力的地方。