4、全量升级原理：全量包结构设计、全量升级流程、全量与差分的选型策略
各位同学，今天我们来聊聊全量升级。说实话，这是OTA升级里最基础、也最“笨”的一种方式。但你别小看它，很多场景下，它反而是最稳的选择。
我在早期做智能家居项目时，就吃过“过度设计”的亏。当时一上来就搞差分升级，结果设备端内存不够，解压算法跑不起来，最后灰溜溜地改回全量。嗯，从那以后我明白了一个道理：技术选型，没有最好，只有最合适。
4.1 全量包结构设计
全量包，说白了就是把整个系统镜像打包成一个文件。你想想看，它里面装了什么？
我习惯把全量包分成三个部分：
- 包头（Header）：包含魔数、版本号、包大小、校验和等元信息
- 镜像数据（Image Data）：真正的系统固件，可能是压缩过的
- 尾部签名（Footer）：用于验签，防止被篡改
下面是我在一个IoT网关项目中用过的包结构，你可以参考一下：
// 全量包结构定义
typedef struct {
uint32_t magic; // 魔数: 0xOTA4FULL
uint32_t version; // 版本号
uint32_t image_size; // 镜像大小
uint32_t checksum; // CRC32校验
uint8_t reserved[16]; // 保留字段
} ota_header_t;
typedef struct {
ota_header_t header;
uint8_t image_data[0]; // 变长数组
uint8_t signature[64]; // RSA签名
} ota_package_t;关键点：包头里的checksum一定要做两次。一次是包头自身的校验，一次是整个包的校验。我曾经遇到过传输过程中包头损坏，导致解包时直接崩溃的情况。
4.2 全量升级流程
全量升级的流程，其实就三步：下载、校验、刷写。但每一步都有坑。
我画了一张流程图，帮你理清整个逻辑：
流程看起来简单，但实际落地时，我建议你注意这几点：
- 断点续传：下载过程中网络断了怎么办？我习惯把包切成1MB的块，每块单独校验。这样重传时只传失败的部分。
- 双分区备份：刷写时一定要保留一个可启动的备份分区。我曾经见过设备刷到一半断电，直接变砖的惨案。
- 校验要彻底：除了CRC，还要做签名验证。别问我为什么，有一次客户反馈设备被刷了第三方固件，就是因为没做签名。
避坑指南：我曾经在某个项目中，把校验放在刷写之后做。结果刷完发现校验失败，设备已经起不来了。正确的做法是：先校验，再刷写。顺序不能乱。
4.3 全量与差分的选型策略
很多同学会问：到底什么时候用全量，什么时候用差分？
我的经验是，看三个维度：带宽、存储、稳定性。
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 首次升级 | 全量 | 没有旧版本做差分基准 |
| 小版本迭代 | 差分 | 节省带宽，速度快 |
| 大版本升级 | 全量 | 避免差分算法复杂度过高 |
| 设备存储紧张 | 差分 | 包体小，省空间 |
| 网络不稳定 | 全量 | 差分包依赖旧版本，一旦出错很难恢复 |
| 安全要求高 | 全量 | 全量包更容易做完整性校验 |
我个人习惯的做法是：大版本用全量，小版本用差分。比如从v1.0升到v2.0，改动很大，直接全量。从v2.0升到v2.1，只改了几个bug，差分就够了。
我的小技巧：在设备端同时保留全量和差分两种升级能力。服务器端根据设备当前版本和网络状况，动态选择下发哪种包。这样既灵活又可靠。
你想想看，如果每次升级都用全量，那用户流量费得多高？但如果每次都用差分，万一差分算法出问题，设备可能就起不来了。所以，选型不是非黑即白，而是根据实际情况做权衡。
嗯，关于全量升级，今天就聊到这里。记住一句话：全量是底线，差分是优化。先把全量做稳了，再考虑差分的事。
公众号:蓝海资料掘金营，微信deep3321