我目前正在开发一个 OTA/FOTA 更新系统，该系统必须在具有 ARM CORTEX M0+ 的嵌入式设备中运行。 我的主要问题是FLASH空间不足以及网络带宽较低，所以增量补丁应该越小越好。
为了得到这个结果，我做了一些研究，发现了一些二进制差异算法和工具，例如 bsdiff、xdelta 或 courgette。 我的问题是它们的大小，因为我需要一个非常小的编译应用程序来运行它，所以我得到了一个 bsdiff 独立版本(实际上它们是 2 个版本:bsdiff 独立版本和 minibsdiff):
https://github.com/Cheedoong/bsdiff
https://github.com/thoughtpolice/minibsdiff
第一个仍然使用 bzip2，但它是独立的并且最适合嵌入式系统，但我想测试 2 件事:
未压缩增量的大小是多少。所以我尝试删除所有 bzip2 逻辑，明白了。当我注意到增量的大小与完整原始文件的大小相似时，我感到非常惊讶，所以我跳到了第二个源，minibsdiff。
minibsdiff 是 bsdiff，但根本没有任何压缩，让您可以使用任何您想要的压缩。它还帮助我检查我是否没有错，以及生成的未压缩增量补丁与我想要修补的原始文件的大小相同(或者更大一些，因为我认为是 header 和其他文件)。
所以...这里发生了什么？我在谷歌上搜索了一下，非常相似的文件会生成更大的补丁，但是......在测试期间，我使用了 8 KB 大小的文件，获取 8 KB 未压缩的补丁不是一个解决方案，因为那样也许只压缩文件并替换旧的会更好一件接一件新的..我觉得我错过了一些东西。
任何想法将不胜感激。
谢谢大家。
最诚挚的问候，
伊万。
最佳答案
通过阅读有关 bsdiff 及其如何对后缀进行排序的更多信息，我得出了一些结论。它似乎在位置之间添加了零，这就是为什么它似乎增加了补丁大小，但零很容易被压缩，这就是 bsdiff 高效的原因。因此，如果我想在可用内存很少的系统中实现这一点，建议使用另一种压缩算法，例如lzw，并修改修补程序以便按 block 修补(写入闪存固件)，如我正在解压缩 block ，因为我无法在 ARM CORTEX M0+ 中处理大文件(用于压缩补丁的 32KB RAM 和 8 或 16KB ROM)。
最诚挚的问候，如果我得到任何有趣的结果，我会发布更多内容。
谢谢大家。
伊万。
关于c - 未经压缩的 bsdiff 会生成大增量补丁文件，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38762711/