4. bspatch算法详解：合并流程、内存管理与大文件处理
好，咱们接着聊bspatch。上一节我们把bsdiff的差分生成过程讲透了，这一节重点看合并——也就是bspatch怎么把旧文件和补丁包合成为新文件。
说实话，bspatch的代码量比bsdiff小得多，逻辑也更直接。但别小看它，里面有不少细节，处理不好就会翻车。我最早在项目里用bspatch时，就踩过内存分配的坑，差点把设备搞成砖头。
4.1 bspatch的合并流程：三步走
bspatch的核心思路很简单：读取补丁包 → 解析控制块 → 执行三种操作。说白了就是根据补丁里的指令，把旧文件的数据搬过来、把新数据插进去、或者从旧文件里复制一段再修改。
具体流程分三步：
- 读取补丁头部：获取新文件大小、控制块长度、附加数据长度等信息。
- 解析控制块：控制块里存的是三元组 (x, y, z)，分别表示：从旧文件复制x字节、追加y字节的新数据、向前/向后跳转z字节。
- 执行合并：循环处理每个控制块，直到新文件生成完毕。
我画个伪代码，你一看就明白：
// bspatch 核心流程（简化版）
void bspatch(const char* oldFile, const char* newFile, const char* patchFile) {
// 1. 读取补丁头部
uint8_t header[32];
read(patchFile, header, 32);
uint64_t newSize = read_be64(header + 8); // 新文件大小
uint64_t ctrlLen = read_be64(header + 16); // 控制块长度
uint64_t diffLen = read_be64(header + 24); // 附加数据长度
// 2. 定位到控制块、附加数据、额外数据的位置
// 控制块在补丁文件偏移 32 处
// 附加数据在控制块之后
// 额外数据在附加数据之后
// 3. 循环处理每个控制块
uint8_t* newData = malloc(newSize);
uint64_t oldPos = 0, newPos = 0;
while (newPos < newSize) {
// 读取一个控制块三元组
int64_t x = read_be64(ctrl); // 从旧文件复制 x 字节
int64_t y = read_be64(ctrl); // 追加 y 字节新数据
int64_t z = read_be64(ctrl); // 跳转 z 字节
// 操作1：从旧文件复制 x 字节，并与附加数据做差分还原
for (int i = 0; i < x; i++) {
newData[newPos + i] = oldFile[oldPos + i] + diffData[diffPos + i];
}
oldPos += x;
newPos += x;
diffPos += x;
// 操作2：从额外数据中直接复制 y 字节
memcpy(newData + newPos, extraData + extraPos, y);
newPos += y;
extraPos += y;
// 操作3：根据 z 调整旧文件指针
oldPos += z;
}
// 4. 写入新文件
write(newFile, newData, newSize);
free(newData);
}
你看，逻辑其实不复杂。但这里有个关键点：差分还原。bsdiff生成补丁时，不是直接存新数据，而是存「新数据 - 旧数据」的差值。所以合并时要把差值加回去。这个设计很巧妙，能大幅压缩补丁体积。
核心要点：bspatch的三种操作对应三种数据来源：
- 从旧文件复制 + 差分还原：处理相似度高的部分，补丁体积小
- 从附加数据直接复制：处理新增或变化大的部分
- 跳转旧文件指针：处理文件结构变化（如插入/删除）
4.2 内存管理策略：别让嵌入式设备崩溃
嗯，这里要重点说说内存管理。bspatch的原始实现有个「坏习惯」——它会把整个旧文件和新文件都加载到内存里。你想想看，如果旧文件有10MB，新文件有12MB，再加上补丁包，一次就要吃掉30MB以上的RAM。
在PC上这不算什么，但在嵌入式设备上，这就是灾难。我曾经在一个只有64KB RAM的MCU上跑bspatch，结果直接内存溢出，设备重启了。那次教训让我养成了一个习惯：永远不要假设内存够用。
我总结了几种内存管理策略，按资源紧张程度排序：
| 策略 | 适用场景 | 内存占用 | 实现复杂度 |
|---|---|---|---|
| 全量加载 | RAM充足（> 3倍文件大小） | 高 | 低 |
| 分块加载 | RAM有限（1~2倍文件大小） | 中 | 中 |
| 流式处理 | RAM极紧张（< 文件大小） | 低 | 高 |
全量加载：最简单，但最费内存。适合开发板调试阶段。
分块加载：把旧文件分成若干块，每次只加载一块到内存。合并时，如果控制块需要的数据跨块了，就重新加载。我习惯用4KB或8KB作为块大小，这样既能减少IO次数，又不会占用太多RAM。
流式处理：这是最极致的方案。旧文件、补丁包、新文件都通过文件流读写，内存里只保留当前处理的数据。但实现起来很麻烦，因为控制块里的跳转操作可能要求你「回退」到旧文件的某个位置。我一般用环形缓冲区来解决这个问题。
我的建议：如果你的设备RAM在256KB以上，用分块加载就够了。如果只有64KB甚至更少，那必须上流式处理。别问我怎么知道的——我曾在某款国产MCU上折腾了整整两周才搞定流式bspatch。
4.3 大文件处理技巧：别让OTA升级卡死
大文件处理，说白了就是「文件太大，内存装不下，IO又太慢」的问题。嵌入式设备上，大文件通常指几MB到几十MB的固件。对于这类文件，有四个技巧特别实用：
技巧1：使用文件映射（mmap）
如果操作系统支持mmap，那就用。它能把文件直接映射到虚拟地址空间，看起来像内存访问，实际上由内核管理页面调度。这样你就不用手动分块了，代码也干净很多。
// 使用 mmap 加载旧文件
int fd = open(oldFile, O_RDONLY);
uint8_t* oldData = mmap(NULL, oldSize, PROT_READ, MAP_PRIVATE, fd, 0);
// 直接像数组一样访问 oldData
// 处理完后 munmap
但注意，mmap在裸机或RTOS上不一定可用。我一般在Linux嵌入式设备上用这个，效果很好。
技巧2：预读与缓存
分块加载时，IO操作是瓶颈。我习惯用双缓冲：一块用于当前处理，另一块预读下一块数据。这样CPU在处理数据的同时，DMA或后台线程已经在加载下一块了，IO等待时间几乎被消除。
技巧3：控制块预解析
bspatch的控制块是顺序读取的，但每个控制块里的跳转值z可能很大，导致旧文件指针跳来跳去。如果每次都重新定位文件指针，IO开销会很大。我的做法是：预解析一批控制块，计算出旧文件访问的「热点区域」，然后按区域顺序读取，减少随机IO。
技巧4：校验与断点续传
大文件升级最怕中途失败。我建议在补丁包中嵌入校验和（如CRC32或SHA256），每处理完一个块就校验一次。如果校验失败，可以记录当前进度，下次从断点处继续。这个功能在信号不稳定的无线OTA场景下特别有用。
注意：断点续传需要补丁包支持随机访问，且旧文件不能被修改。如果旧文件在升级过程中被意外擦除了，那就只能从头开始。所以，我一般会在升级前把旧文件备份到另一个存储区域。
4.4 实战经验：一个典型的bspatch优化案例
最后分享一个我实际做过的案例。某款智能家居网关，Flash有8MB，RAM只有128KB。固件大小4MB，每次OTA升级都要用bspatch。
原始方案是全量加载，结果RAM直接爆了。我改成了分块加载，块大小设为16KB。但发现一个问题：控制块里的跳转值z经常导致旧文件指针跳回前面，每次跳转都要重新读取文件块，IO效率很低。
后来我加了一个LRU缓存，缓存最近访问的4个块（共64KB）。跳转时先查缓存，命中就直接用，没命中才去读Flash。这样优化后，IO次数减少了70%，升级时间从原来的3分钟缩短到45秒。
你看，有时候不是算法本身的问题，而是实现细节决定了成败。bspatch的合并流程就那么几步，但内存管理和IO优化才是真正考验功力的地方。
下一节我们会讲差分升级的实战部署，包括如何集成到OTA框架、如何做版本兼容性检查。到时候再聊。