第四节：数据校验策略优化
数据校验，说白了就是确保你写进去的东西和源文件一模一样。我见过不少工程师，一上来就全量校验，结果刷个固件等半天。其实这里头有很多优化空间。
4.1 校验算法的性能对比
先说说常见的校验算法。CRC32、SHA256、MD5，这三个是Bootloader里最常用的。我直接给结论：
| 算法 | 计算速度（典型值） | 安全性 | 资源占用 | 适用场景 |
|---|---|---|---|---|
| CRC32 | ~500 MB/s | 低（防随机错误） | 极低（4字节表） | OTA升级、量产刷写 |
| MD5 | ~200 MB/s | 中（已不推荐） | 低 | 兼容旧系统 |
| SHA256 | ~80 MB/s | 高（防篡改） | 中（需64字节上下文） | 安全启动、签名验证 |
你看这个表就明白了。CRC32快得离谱，但安全性不够。SHA256慢，但防篡改能力强。我个人习惯是：量产刷写用CRC32，安全启动用SHA256。
核心观点：不要盲目追求高安全性算法。如果你的场景只是防传输错误，CRC32完全够用。我见过有人用SHA256做OTA校验，结果刷写速度直接砍半，用户投诉不断。
4.2 校验粒度优化：分块校验
全量校验最大的问题是什么？阻塞。你想想看，一个128MB的固件，全量校验要等好几秒。这段时间用户只能干瞪眼。
我的做法是：分块校验。把固件切成小块，每块单独计算校验值。这样有几个好处：
- 边接收边校验，不用等全部数据到齐
- 发现错误可以立即重传，不用重传整个文件
- 校验粒度可调，平衡速度和安全性
举个例子，我做过一个项目，固件大小64MB，分块大小设为4KB。这样每块校验只需要计算4KB的CRC32，耗时不到0.1ms。整个校验过程几乎感觉不到延迟。
// 分块校验示例
#define BLOCK_SIZE 4096 // 4KB块
#define TOTAL_BLOCKS (FIRMWARE_SIZE / BLOCK_SIZE)
uint32_t block_crc[TOTAL_BLOCKS];
void verify_firmware_block(uint32_t block_idx, uint8_t *data) {
uint32_t expected_crc = block_crc[block_idx];
uint32_t actual_crc = crc32_calculate(data, BLOCK_SIZE);
if (expected_crc != actual_crc) {
// 只重传这一个块
request_retransmit(block_idx);
}
}我的经验：分块大小选4KB到16KB比较合适。太小了校验表太大，太大了又失去分块意义。我曾经试过1KB的块，结果校验表占了2MB内存，嵌入式设备扛不住。
4.3 流水线校验：让校验和刷写并行
分块校验解决了阻塞问题，但还不够。你想想，如果校验和刷写能同时进行，那效率不就翻倍了吗？
这就是流水线校验的思路。我常用的模式是：
- 接收第N块数据
- 同时计算第N-1块的校验值
- 同时擦写第N-2块到Flash
这样三级流水线，理论上能把刷写时间压缩到原来的三分之一。当然，实际项目中要考虑资源冲突，比如DMA和CPU争抢总线。
// 流水线校验伪代码
void pipeline_verify_and_write() {
uint8_t *buffer[3]; // 三个缓冲区轮转
int state = 0;
while (more_data) {
// 阶段1：接收数据
receive_block(buffer[state % 3]);
// 阶段2：校验上一块
if (state > 0) {
uint32_t crc = crc32_calculate(buffer[(state-1) % 3], BLOCK_SIZE);
if (crc != expected_crc[(state-1)]) {
handle_error();
}
}
// 阶段3：写入上上块
if (state > 1) {
flash_write(buffer[(state-2) % 3], BLOCK_SIZE);
}
state++;
}
}注意：流水线校验对内存要求较高。我曾在只有64KB RAM的MCU上尝试，结果缓冲区不够用。后来改成双缓冲才勉强跑起来。建议至少128KB RAM再考虑流水线方案。
4.4 避坑指南：我曾经踩过的坑
做校验优化这么多年，我总结了几条血泪教训：
- 不要用软件CRC32：很多MCU有硬件CRC模块，速度能快10倍。我一开始不知道，用软件算CRC，结果成了瓶颈。
- 校验表要放在RAM里：分块校验的校验表如果放在Flash，每次读取都要等Flash访问时间。我建议在初始化时一次性加载到RAM。
- 注意校验顺序：我曾经犯过一个错误，先校验再写入。结果写入失败后，校验通过了，数据却是错的。正确的顺序是：先写入，再校验。
总结一下：校验优化的核心就是「别让校验成为瓶颈」。用CRC32代替SHA256，用分块代替全量，用流水线代替串行。这三板斧下去，刷写速度至少提升50%。
嗯，这里还要提醒一句：优化要适度。我见过有人为了追求极致速度，把校验粒度改成256字节，结果校验表占了整个RAM的一半。得不偿失。找到平衡点，才是工程师该做的事。