1. 项目背景与整体设计思路拆解在嵌入式实时操作系统里做数据压缩跟在通用操作系统上完全是两码事。VxWorks 这类 RTOS 跑在资源受限的板子上内存可能只有几兆甚至几百 KBCPU 主频不高还背着硬实时约束——你不能因为压缩一个数据块就把任务调度延迟拉高。所以当我第一次接到“在 VxWorks 上实现 deflate 压缩与 inflate 解压缩”这个需求时脑子里第一反应不是“找个 zlib 编进去”而是先想清楚这套东西到底跑在什么场景、内存预算多少、实时性容忍度如何。deflate 和 inflate 是 zlib 里最核心的一对算法deflate 负责把原始数据压成 DEFLATE 格式的比特流inflate 负责还原。DEFLATE 本身是 LZ77 加 Huffman 编码的组合先用滑动窗口找重复字符串做长度-距离匹配再对字面量和匹配长度做 Huffman 编码。它不像 LZMA 那样吃内存也不像纯 Huffman 那样压缩率有限属于“压缩率与资源消耗平衡得比较好”的选择这也是它在嵌入式场景里被广泛采用的根本原因。这个项目要解决的问题很具体设备在运行过程中会产生日志、配置快照、传感器采样数据这些数据要么需要落盘存储要么需要通过串口或网络回传。原始数据体积大存储介质容量有限传输带宽也紧张所以需要在设备端做压缩。同时设备偶尔要接收上位机下发的压缩包需要能解压还原。适合参考这套方案的人应该是对 VxWorks 有一定了解、熟悉 C 语言、正在做嵌入式数据存储或通信模块的开发者哪怕你之前没碰过压缩算法跟着思路走也能落地。整体设计上我做了几个关键取舍。第一不引入完整的 zlib 库而是裁剪出 deflate/inflate 的核心源码去掉 gzip 文件头处理、去掉不必要的高层封装只保留 raw deflate 和 raw inflate 接口。原因是完整 zlib 带了不少我们用不到的文件操作和校验逻辑代码体积和内存占用都偏大。第二内存分配不走标准 malloc而是用 VxWorks 的 memPart 内存池提前划一块固定大小的分区给压缩模块专用避免运行时碎片化。第三压缩级别不追求最高选 6 级默认级别作为平衡点实测下来压缩率和速度都比较稳。注意裁剪 zlib 源码时一定要保留 crc32 校验相关代码虽然 raw deflate 本身不带校验但实际业务里数据完整性校验几乎绕不开后面我会讲怎么在应用层补上。为什么这么设计因为嵌入式场景里“能跑”和“跑得稳”是两回事。完整 zlib 在 PC 上跑没问题但在 VxWorks 上它的默认内存分配策略可能触发不可预期的延迟抖动。用固定内存池的好处是每次压缩/解压的内存开销可预测最坏情况下的执行时间也能估算出来这对实时系统至关重要。另外裁剪源码还能减少 Flash 占用很多嵌入式板子的代码空间也是紧巴巴的。2. 核心细节解析与实操要点2.1 deflate 压缩流程的关键环节deflate 的压缩过程可以拆成三步滑动窗口匹配、Huffman 树构建、比特流输出。滑动窗口默认 32KB这个大小直接决定了能找到多远的重复串。窗口越大压缩率越高但内存占用也越大。在 VxWorks 上如果内存紧张可以把窗口降到 16KB 甚至 8KB代价是压缩率下降几个百分点。我实测过一组日志数据32KB 窗口压缩率约 3.2:116KB 窗口约 2.9:1差距不算太离谱内存实在紧的时候可以降。Huffman 树构建分动态和静态两种模式。动态 Huffman 会根据当前数据块的实际频率分布生成最优编码表压缩率好但需要额外存储编码表静态 Huffman 用预定义的固定编码表省去建表开销但压缩率略差。zlib 默认会根据数据特征自动选择这个逻辑不用我们改但要知道它存在——如果你发现某类数据压缩率异常低可能是动态/静态切换策略不适合你的数据分布。实操中最容易踩坑的是deflateInit2的参数配置。这个函数比deflateInit多几个参数其中windowBits设为负数表示输出 raw deflate 流不带 zlib 头这对嵌入式场景很关键因为 zlib 头那 2 个字节在频繁小包压缩时也是浪费。memLevel控制内部状态的内存用量取值 1 到 9默认 8。我一般设成 7 或 6能省一些内存压缩率损失很小。下面是一段初始化代码示例z_stream strm; strm.zalloc my_alloc; strm.zfree my_free; strm.opaque NULL; int ret deflateInit2(strm, 6, Z_DEFLATED, -15, 7, Z_DEFAULT_STRATEGY); if (ret ! Z_OK) { /* 初始化失败记录错误码 */ }这里的-15就是 windowBits 取负表示 raw deflate6是压缩级别7是 memLevel。my_alloc和my_free是我自己封装的基于 memPart 的分配函数保证所有内存都从专用池里出。2.2 inflate 解压流程的注意事项inflate 相对 deflate 简单一些但坑也不少。最典型的问题是输入数据不完整或损坏时inflate 可能返回Z_BUF_ERROR或Z_DATA_ERROR如果代码里没做区分处理很容易把正常的分段输入误判成数据损坏。Z_BUF_ERROR通常表示当前输入缓冲区里的数据还不够解出一个完整块需要继续喂数据Z_DATA_ERROR才是真的格式错误。这两个必须分开处理否则解压大文件分段读取时会频繁误报。另一个要点是输出缓冲区的大小估算。inflate 不像 deflate 那样能提前知道压缩后大小解压时输出大小是未知的。常见做法是给一个初始缓冲区解压过程中如果返回Z_BUF_ERROR且avail_out为 0就扩大缓冲区继续。但在嵌入式环境里不能无限制扩我一般会根据业务场景设一个上限比如单次解压不超过 1MB超过就报错防止恶意或损坏数据把内存撑爆。strm.next_in compressed_data; strm.avail_in compressed_len; strm.next_out out_buf; strm.avail_out out_buf_size; ret inflateInit2(strm, -15); while (ret Z_OK || ret Z_BUF_ERROR) { ret inflate(strm, Z_NO_FLUSH); if (ret Z_BUF_ERROR strm.avail_out 0) { /* 输出缓冲区满扩容或分段处理 */ break; } if (ret Z_STREAM_END) break; } inflateEnd(strm);提示inflateInit2的 windowBits 同样要传-15跟压缩端保持一致。如果压缩端用了 raw deflate 而解压端按 zlib 格式解析会直接报头错误。2.3 内存池的划分与参数计算内存池大小怎么定这得算。deflate 的内部状态大约需要(1 (windowBits2)) (1 (memLevel9))字节再加上输入输出缓冲区。以 windowBits15、memLevel7 为例内部状态约 128KB 64KB 192KB 左右。inflate 的状态小一些约 32KB 到 40KB。如果压缩和解压不同时进行可以共用一个池如果可能并发得分别划。我当时的做法是划一个 512KB 的专用分区压缩和解压各占一半输入输出缓冲区从调用者的栈或临时缓冲区出不占池子。这样最坏情况下内存占用可控不会因为某次大文件压缩把系统内存吃光。实际跑下来压缩 100KB 日志数据峰值内存约 260KB解压约 80KB池子够用且有富余。参数取值说明windowBits15压缩/ -15raw窗口 32KBraw 模式省头memLevel7内部状态内存适中压缩级别6压缩率与速度平衡内存池大小512KB压缩解压各半留富余单次解压上限1MB防止异常数据撑爆内存2.4 数据完整性校验的补位方案raw deflate 不带校验数据在存储或传输过程中出错inflate 可能解出一堆乱码而不报错。所以应用层必须补校验。我的做法是在压缩数据前面加一个自定义头4 字节魔数 4 字节原始长度 4 字节 CRC32。解压前先校验魔数和 CRC对不上直接丢弃。CRC32 用 zlib 自带的crc32函数算代码不用自己写但要注意它算的是原始数据不是压缩后数据。这个头结构是我自己定的你也可以换成别的关键是压缩端和解压端约定一致。加头之后每块数据多 12 字节开销对于几百字节以上的数据块可以忽略对于几十字节的小包就不太划算——那种场景建议攒批压缩或者干脆不压。3. 实操过程与核心环节实现3.1 源码裁剪与工程集成第一步是把 zlib 源码里需要的文件挑出来。核心文件是deflate.c、inflate.c、inftrees.c、inffast.c、trees.c、zutil.c、crc32.c、adler32.c头文件需要zlib.h、zconf.h、deflate.h、inflate.h、inftrees.h、inffast.h、trees.h、zutil.h。gzread.c、gzwrite.c这些文件操作相关的全部不要compress.c、uncompress.c这种高层封装也可以去掉我们直接用底层接口。集成到 VxWorks 工程时把这些文件加到工程里编译即可。需要注意的是zconf.h里有一些平台相关的宏比如Z_HAVE_UNISTD_HVxWorks 环境下可能没有 unistd.h要把相关宏注释掉或改成条件编译。另外zutil.c里的z_errmsg数组如果不用错误信息字符串可以裁掉省空间但调试阶段建议留着排查问题时能直接打印错误描述。编译选项上我开了-O2优化关掉了-g调试信息发布版本并且定义了NO_GZCOMPRESS和NO_GZIP宏进一步减少代码体积。裁剪完编译出来代码段约 40KB比完整 zlib 小了一半多。3.2 压缩接口的封装与调用封装一个app_deflate函数入参是原始数据指针、长度、输出缓冲区指针和容量出参是压缩后长度。内部流程初始化 z_stream、设置内存分配回调、调用deflate直到Z_STREAM_END、deflateEnd清理。关键点是deflate的调用循环要处理输出缓冲区不够的情况。int app_deflate(const unsigned char *src, int src_len, unsigned char *dst, int dst_cap, int *out_len) { z_stream strm {0}; strm.zalloc pool_alloc; strm.zfree pool_free; strm.next_in (Bytef *)src; strm.avail_in src_len; strm.next_out dst; strm.avail_out dst_cap; if (deflateInit2(strm, 6, Z_DEFLATED, -15, 7, Z_DEFAULT_STRATEGY) ! Z_OK) return -1; int ret deflate(strm, Z_FINISH); if (ret ! Z_STREAM_END) { deflateEnd(strm); return -2; } *out_len dst_cap - strm.avail_out; deflateEnd(strm); return 0; }这里用Z_FINISH一次性压完适合数据量不大的场景。如果数据很大比如几 MB一次性压可能输出缓冲区不够那就得改成Z_NO_FLUSH分段循环每次压一部分输出一部分。我实测 100KB 以内的数据一次性压没问题输出缓冲区按输入长度的 1.1 倍给就够压缩率最差也就 1:1 略多一点点。注意deflateEnd一定要在返回前调用哪怕出错也要调否则内存池里的状态不释放跑几次就泄漏光了。我早期就犯过这个错压了几十次之后内存池耗尽系统直接卡死。3.3 解压接口的实现与边界处理解压接口app_inflate的入参是压缩数据指针、长度、输出缓冲区指针和容量。跟压缩不同解压时输出长度未知所以调用者要么给足缓冲区要么接口内部支持动态扩容。我选择前者——调用者给一个足够大的缓冲区接口返回实际解压长度缓冲区不够就返回错误码由调用者决定是否重试。int app_inflate(const unsigned char *src, int src_len, unsigned char *dst, int dst_cap, int *out_len) { z_stream strm {0}; strm.zalloc pool_alloc; strm.zfree pool_free; strm.next_in (Bytef *)src; strm.avail_in src_len; strm.next_out dst; strm.avail_out dst_cap; if (inflateInit2(strm, -15) ! Z_OK) return -1; int ret inflate(strm, Z_FINISH); if (ret ! Z_STREAM_END) { inflateEnd(strm); return (ret Z_BUF_ERROR) ? -3 : -2; } *out_len dst_cap - strm.avail_out; inflateEnd(strm); return 0; }返回-3表示输出缓冲区不够调用者可以扩大缓冲区重试。这里有个细节inflate用Z_FINISH时如果输出缓冲区不够会返回Z_BUF_ERROR但此时strm的状态已经推进了一部分不能直接拿原数据重新调inflate必须重新inflateInit2从头来。所以重试逻辑是“扩大缓冲区 重新初始化 重新解压”不是接着上次的进度继续。3.4 实测数据与性能记录拿一组实际日志数据做测试原始大小 100KB重复内容较多日志格式固定时间戳和少量字段变化。压缩级别 6、windowBits 15、memLevel 7 的配置下压缩后约 31KB压缩率 3.2:1压缩耗时约 18ms主频 800MHz 的嵌入式 CPU。解压耗时约 6ms解压后数据 CRC 校验通过。换一组传感器采样数据数值波动大、重复少压缩率只有 1.4:1压缩耗时 22ms。这说明 deflate 对数据重复度敏感如果你的业务数据本身熵很高比如已经加密或随机性强的数据压缩收益有限得评估是否值得压。数据类型原始大小压缩后压缩率压缩耗时解压耗时日志数据100KB31KB3.2:118ms6ms传感器数据100KB71KB1.4:122ms7ms配置文件20KB5KB4.0:14ms2ms配置文件压缩率最高因为格式固定、重复串多。这组数据也印证了前面的判断deflate 适合结构化、重复度高的数据对高熵数据效果一般。4. 常见问题与排查技巧实录4.1 压缩解压典型故障速查实际跑下来遇到的问题不少我整理成一张速查表方便对照排查。现象可能原因排查方法解决方式解压返回 Z_DATA_ERROR压缩解压 windowBits 不一致检查两端是否都传 -15统一为 raw 模式解压返回 Z_BUF_ERROR 且 avail_out0输入数据不完整检查压缩数据是否被截断补全数据或分段喂入压缩后数据比原始还大数据熵高或太小对比压缩前后长度小数据不压攒批处理内存池耗尽deflateEnd/inflateEnd 未调用检查所有返回路径确保清理函数必调解压出乱码但无报错缺少完整性校验加 CRC32 校验应用层补校验头压缩耗时抖动大内存池碎片或竞争检查池使用和并发专用池 加锁保护4.2 内存泄漏的隐蔽坑前面提过deflateEnd漏调的问题这里展开说。zlib 的deflateInit2内部会分配状态结构这个结构不小前面算过约 192KB如果某条错误返回路径上忘了调deflateEnd这块内存就泄漏了。嵌入式系统跑几天几夜泄漏累积起来很致命。我的做法是把deflateEnd放在统一的清理标签里所有返回路径都goto cleanup保证必调。int ret_code -1; z_stream strm {0}; if (deflateInit2(...) ! Z_OK) goto cleanup; if (deflate(...) ! Z_STREAM_END) { ret_code -2; goto cleanup; } ret_code 0; cleanup: deflateEnd(strm); return ret_code;这种写法看着土但实测最稳。另外建议在内存池的 alloc/free 回调里加计数跑压力测试时观察计数是否归零能提前发现泄漏。4.3 分段压缩的边界问题数据量大需要分段压缩时有个容易忽略的点deflate用Z_NO_FLUSH分段调用最后必须用Z_FINISH收尾否则输出的比特流不完整解压端会报错。我见过有人分段压完直接结束结果解压时最后一段数据丢失。正确做法是循环里用Z_NO_FLUSH最后一次调用改成Z_FINISH并且循环条件要判断Z_STREAM_END。分段解压同理inflate循环喂数据直到返回Z_STREAM_END才算完。中间返回Z_OK或Z_BUF_ERROR都继续喂但Z_BUF_ERROR要区分是输入不够还是输出不够前者继续喂输入后者扩输出缓冲区。4.4 压缩级别选择的经验压缩级别 1 到 9级别越高压缩率越好但越慢。我实测过同一组日志数据级别 1 压缩率 2.6:1 耗时 8ms级别 6 压缩率 3.2:1 耗时 18ms级别 9 压缩率 3.3:1 耗时 45ms。级别 6 到 9 压缩率提升很小但耗时翻倍多不划算。级别 1 到 6 压缩率提升明显耗时增加可接受。所以 6 级是甜点除非你对压缩率有极致要求且能容忍延迟否则别上 9 级。提示如果业务对延迟极敏感比如中断上下文里压缩可以用级别 1 甚至级别 0不压缩只打包把压缩放到低优先级任务里做。4.5 并发调用的保护如果多个任务同时调压缩接口共用内存池会有竞争问题。zlib 的 z_stream 是每个调用独立的但内存池的 alloc/free 回调如果没加锁多任务并发时会踩内存。我的做法是给内存池操作加互斥信号量或者干脆每个任务用独立的池。前者省内存但可能引入优先级反转后者简单粗暴但吃内存。嵌入式里任务数不多的话独立池更省心。另外 zlib 的crc32函数是线程安全的无全局状态可以放心并发调。但deflateInit2和inflateInit2内部会调 alloc所以锁要加在 alloc 回调里不是加在 init 外面。5. 工程化收尾与扩展思路这套东西在板子上跑了小半年日志压缩存储和配置快照回传两个场景都稳。回过头看最值得强调的经验是嵌入式里做压缩算法本身不是难点难点在内存管理和边界处理。zlib 的代码质量很高接口也成熟真正花时间的是把它塞进受限环境、保证不泄漏、不出界、不误报。后续如果要扩展有两个方向可以考虑。一是把压缩做成流式接口支持边收数据边压适合网络传输场景不用等整包收完再压。二是加一个自适应逻辑根据数据特征自动选压缩级别——比如先采样一小段估算熵熵高就用低级别快速过熵低就用高级别多压点。这个逻辑不难写但需要实际数据调阈值我还没在正式项目里用属于待验证的想法。最后分享一个小技巧调试压缩问题时把压缩后的数据 dump 成文件用 PC 上的工具解一下能快速判断是压缩端的问题还是解压端的问题。比在板子上盲猜高效得多。 
长河君 · 2026/10/29 21:38:43 · 阅读 1.2k VxWorks嵌入式deflate压缩实战：内存池与实时性优化
1. 项目背景与整体设计思路拆解在嵌入式实时操作系统里做数据压缩跟在通用操作系统上完全是两码事。VxWorks 这类 RTOS 跑在资源受限的板子上内存可能只有几兆甚至几百 KBCPU 主频不高还背着硬实时约束——你不能因为压缩一个数据块就把任务调度延迟拉高。所以当我第一次接到“在 VxWorks 上实现 deflate 压缩与 inflate 解压缩”这个需求时脑子里第一反应不是“找个 zlib 编进去”而是先想清楚这套东西到底跑在什么场景、内存预算多少、实时性容忍度如何。deflate 和 inflate 是 zlib 里最核心的一对算法deflate 负责把原始数据压成 DEFLATE 格式的比特流inflate 负责还原。DEFLATE 本身是 LZ77 加 Huffman 编码的组合先用滑动窗口找重复字符串做长度-距离匹配再对字面量和匹配长度做 Huffman 编码。它不像 LZMA 那样吃内存也不像纯 Huffman 那样压缩率有限属于“压缩率与资源消耗平衡得比较好”的选择这也是它在嵌入式场景里被广泛采用的根本原因。这个项目要解决的问题很具体设备在运行过程中会产生日志、配置快照、传感器采样数据这些数据要么需要落盘存储要么需要通过串口或网络回传。原始数据体积大存储介质容量有限传输带宽也紧张所以需要在设备端做压缩。同时设备偶尔要接收上位机下发的压缩包需要能解压还原。适合参考这套方案的人应该是对 VxWorks 有一定了解、熟悉 C 语言、正在做嵌入式数据存储或通信模块的开发者哪怕你之前没碰过压缩算法跟着思路走也能落地。整体设计上我做了几个关键取舍。第一不引入完整的 zlib 库而是裁剪出 deflate/inflate 的核心源码去掉 gzip 文件头处理、去掉不必要的高层封装只保留 raw deflate 和 raw inflate 接口。原因是完整 zlib 带了不少我们用不到的文件操作和校验逻辑代码体积和内存占用都偏大。第二内存分配不走标准 malloc而是用 VxWorks 的 memPart 内存池提前划一块固定大小的分区给压缩模块专用避免运行时碎片化。第三压缩级别不追求最高选 6 级默认级别作为平衡点实测下来压缩率和速度都比较稳。注意裁剪 zlib 源码时一定要保留 crc32 校验相关代码虽然 raw deflate 本身不带校验但实际业务里数据完整性校验几乎绕不开后面我会讲怎么在应用层补上。为什么这么设计因为嵌入式场景里“能跑”和“跑得稳”是两回事。完整 zlib 在 PC 上跑没问题但在 VxWorks 上它的默认内存分配策略可能触发不可预期的延迟抖动。用固定内存池的好处是每次压缩/解压的内存开销可预测最坏情况下的执行时间也能估算出来这对实时系统至关重要。另外裁剪源码还能减少 Flash 占用很多嵌入式板子的代码空间也是紧巴巴的。2. 核心细节解析与实操要点2.1 deflate 压缩流程的关键环节deflate 的压缩过程可以拆成三步滑动窗口匹配、Huffman 树构建、比特流输出。滑动窗口默认 32KB这个大小直接决定了能找到多远的重复串。窗口越大压缩率越高但内存占用也越大。在 VxWorks 上如果内存紧张可以把窗口降到 16KB 甚至 8KB代价是压缩率下降几个百分点。我实测过一组日志数据32KB 窗口压缩率约 3.2:116KB 窗口约 2.9:1差距不算太离谱内存实在紧的时候可以降。Huffman 树构建分动态和静态两种模式。动态 Huffman 会根据当前数据块的实际频率分布生成最优编码表压缩率好但需要额外存储编码表静态 Huffman 用预定义的固定编码表省去建表开销但压缩率略差。zlib 默认会根据数据特征自动选择这个逻辑不用我们改但要知道它存在——如果你发现某类数据压缩率异常低可能是动态/静态切换策略不适合你的数据分布。实操中最容易踩坑的是deflateInit2的参数配置。这个函数比deflateInit多几个参数其中windowBits设为负数表示输出 raw deflate 流不带 zlib 头这对嵌入式场景很关键因为 zlib 头那 2 个字节在频繁小包压缩时也是浪费。memLevel控制内部状态的内存用量取值 1 到 9默认 8。我一般设成 7 或 6能省一些内存压缩率损失很小。下面是一段初始化代码示例z_stream strm; strm.zalloc my_alloc; strm.zfree my_free; strm.opaque NULL; int ret deflateInit2(strm, 6, Z_DEFLATED, -15, 7, Z_DEFAULT_STRATEGY); if (ret ! Z_OK) { /* 初始化失败记录错误码 */ }这里的-15就是 windowBits 取负表示 raw deflate6是压缩级别7是 memLevel。my_alloc和my_free是我自己封装的基于 memPart 的分配函数保证所有内存都从专用池里出。2.2 inflate 解压流程的注意事项inflate 相对 deflate 简单一些但坑也不少。最典型的问题是输入数据不完整或损坏时inflate 可能返回Z_BUF_ERROR或Z_DATA_ERROR如果代码里没做区分处理很容易把正常的分段输入误判成数据损坏。Z_BUF_ERROR通常表示当前输入缓冲区里的数据还不够解出一个完整块需要继续喂数据Z_DATA_ERROR才是真的格式错误。这两个必须分开处理否则解压大文件分段读取时会频繁误报。另一个要点是输出缓冲区的大小估算。inflate 不像 deflate 那样能提前知道压缩后大小解压时输出大小是未知的。常见做法是给一个初始缓冲区解压过程中如果返回Z_BUF_ERROR且avail_out为 0就扩大缓冲区继续。但在嵌入式环境里不能无限制扩我一般会根据业务场景设一个上限比如单次解压不超过 1MB超过就报错防止恶意或损坏数据把内存撑爆。strm.next_in compressed_data; strm.avail_in compressed_len; strm.next_out out_buf; strm.avail_out out_buf_size; ret inflateInit2(strm, -15); while (ret Z_OK || ret Z_BUF_ERROR) { ret inflate(strm, Z_NO_FLUSH); if (ret Z_BUF_ERROR strm.avail_out 0) { /* 输出缓冲区满扩容或分段处理 */ break; } if (ret Z_STREAM_END) break; } inflateEnd(strm);提示inflateInit2的 windowBits 同样要传-15跟压缩端保持一致。如果压缩端用了 raw deflate 而解压端按 zlib 格式解析会直接报头错误。2.3 内存池的划分与参数计算内存池大小怎么定这得算。deflate 的内部状态大约需要(1 (windowBits2)) (1 (memLevel9))字节再加上输入输出缓冲区。以 windowBits15、memLevel7 为例内部状态约 128KB 64KB 192KB 左右。inflate 的状态小一些约 32KB 到 40KB。如果压缩和解压不同时进行可以共用一个池如果可能并发得分别划。我当时的做法是划一个 512KB 的专用分区压缩和解压各占一半输入输出缓冲区从调用者的栈或临时缓冲区出不占池子。这样最坏情况下内存占用可控不会因为某次大文件压缩把系统内存吃光。实际跑下来压缩 100KB 日志数据峰值内存约 260KB解压约 80KB池子够用且有富余。参数取值说明windowBits15压缩/ -15raw窗口 32KBraw 模式省头memLevel7内部状态内存适中压缩级别6压缩率与速度平衡内存池大小512KB压缩解压各半留富余单次解压上限1MB防止异常数据撑爆内存2.4 数据完整性校验的补位方案raw deflate 不带校验数据在存储或传输过程中出错inflate 可能解出一堆乱码而不报错。所以应用层必须补校验。我的做法是在压缩数据前面加一个自定义头4 字节魔数 4 字节原始长度 4 字节 CRC32。解压前先校验魔数和 CRC对不上直接丢弃。CRC32 用 zlib 自带的crc32函数算代码不用自己写但要注意它算的是原始数据不是压缩后数据。这个头结构是我自己定的你也可以换成别的关键是压缩端和解压端约定一致。加头之后每块数据多 12 字节开销对于几百字节以上的数据块可以忽略对于几十字节的小包就不太划算——那种场景建议攒批压缩或者干脆不压。3. 实操过程与核心环节实现3.1 源码裁剪与工程集成第一步是把 zlib 源码里需要的文件挑出来。核心文件是deflate.c、inflate.c、inftrees.c、inffast.c、trees.c、zutil.c、crc32.c、adler32.c头文件需要zlib.h、zconf.h、deflate.h、inflate.h、inftrees.h、inffast.h、trees.h、zutil.h。gzread.c、gzwrite.c这些文件操作相关的全部不要compress.c、uncompress.c这种高层封装也可以去掉我们直接用底层接口。集成到 VxWorks 工程时把这些文件加到工程里编译即可。需要注意的是zconf.h里有一些平台相关的宏比如Z_HAVE_UNISTD_HVxWorks 环境下可能没有 unistd.h要把相关宏注释掉或改成条件编译。另外zutil.c里的z_errmsg数组如果不用错误信息字符串可以裁掉省空间但调试阶段建议留着排查问题时能直接打印错误描述。编译选项上我开了-O2优化关掉了-g调试信息发布版本并且定义了NO_GZCOMPRESS和NO_GZIP宏进一步减少代码体积。裁剪完编译出来代码段约 40KB比完整 zlib 小了一半多。3.2 压缩接口的封装与调用封装一个app_deflate函数入参是原始数据指针、长度、输出缓冲区指针和容量出参是压缩后长度。内部流程初始化 z_stream、设置内存分配回调、调用deflate直到Z_STREAM_END、deflateEnd清理。关键点是deflate的调用循环要处理输出缓冲区不够的情况。int app_deflate(const unsigned char *src, int src_len, unsigned char *dst, int dst_cap, int *out_len) { z_stream strm {0}; strm.zalloc pool_alloc; strm.zfree pool_free; strm.next_in (Bytef *)src; strm.avail_in src_len; strm.next_out dst; strm.avail_out dst_cap; if (deflateInit2(strm, 6, Z_DEFLATED, -15, 7, Z_DEFAULT_STRATEGY) ! Z_OK) return -1; int ret deflate(strm, Z_FINISH); if (ret ! Z_STREAM_END) { deflateEnd(strm); return -2; } *out_len dst_cap - strm.avail_out; deflateEnd(strm); return 0; }这里用Z_FINISH一次性压完适合数据量不大的场景。如果数据很大比如几 MB一次性压可能输出缓冲区不够那就得改成Z_NO_FLUSH分段循环每次压一部分输出一部分。我实测 100KB 以内的数据一次性压没问题输出缓冲区按输入长度的 1.1 倍给就够压缩率最差也就 1:1 略多一点点。注意deflateEnd一定要在返回前调用哪怕出错也要调否则内存池里的状态不释放跑几次就泄漏光了。我早期就犯过这个错压了几十次之后内存池耗尽系统直接卡死。3.3 解压接口的实现与边界处理解压接口app_inflate的入参是压缩数据指针、长度、输出缓冲区指针和容量。跟压缩不同解压时输出长度未知所以调用者要么给足缓冲区要么接口内部支持动态扩容。我选择前者——调用者给一个足够大的缓冲区接口返回实际解压长度缓冲区不够就返回错误码由调用者决定是否重试。int app_inflate(const unsigned char *src, int src_len, unsigned char *dst, int dst_cap, int *out_len) { z_stream strm {0}; strm.zalloc pool_alloc; strm.zfree pool_free; strm.next_in (Bytef *)src; strm.avail_in src_len; strm.next_out dst; strm.avail_out dst_cap; if (inflateInit2(strm, -15) ! Z_OK) return -1; int ret inflate(strm, Z_FINISH); if (ret ! Z_STREAM_END) { inflateEnd(strm); return (ret Z_BUF_ERROR) ? -3 : -2; } *out_len dst_cap - strm.avail_out; inflateEnd(strm); return 0; }返回-3表示输出缓冲区不够调用者可以扩大缓冲区重试。这里有个细节inflate用Z_FINISH时如果输出缓冲区不够会返回Z_BUF_ERROR但此时strm的状态已经推进了一部分不能直接拿原数据重新调inflate必须重新inflateInit2从头来。所以重试逻辑是“扩大缓冲区 重新初始化 重新解压”不是接着上次的进度继续。3.4 实测数据与性能记录拿一组实际日志数据做测试原始大小 100KB重复内容较多日志格式固定时间戳和少量字段变化。压缩级别 6、windowBits 15、memLevel 7 的配置下压缩后约 31KB压缩率 3.2:1压缩耗时约 18ms主频 800MHz 的嵌入式 CPU。解压耗时约 6ms解压后数据 CRC 校验通过。换一组传感器采样数据数值波动大、重复少压缩率只有 1.4:1压缩耗时 22ms。这说明 deflate 对数据重复度敏感如果你的业务数据本身熵很高比如已经加密或随机性强的数据压缩收益有限得评估是否值得压。数据类型原始大小压缩后压缩率压缩耗时解压耗时日志数据100KB31KB3.2:118ms6ms传感器数据100KB71KB1.4:122ms7ms配置文件20KB5KB4.0:14ms2ms配置文件压缩率最高因为格式固定、重复串多。这组数据也印证了前面的判断deflate 适合结构化、重复度高的数据对高熵数据效果一般。4. 常见问题与排查技巧实录4.1 压缩解压典型故障速查实际跑下来遇到的问题不少我整理成一张速查表方便对照排查。现象可能原因排查方法解决方式解压返回 Z_DATA_ERROR压缩解压 windowBits 不一致检查两端是否都传 -15统一为 raw 模式解压返回 Z_BUF_ERROR 且 avail_out0输入数据不完整检查压缩数据是否被截断补全数据或分段喂入压缩后数据比原始还大数据熵高或太小对比压缩前后长度小数据不压攒批处理内存池耗尽deflateEnd/inflateEnd 未调用检查所有返回路径确保清理函数必调解压出乱码但无报错缺少完整性校验加 CRC32 校验应用层补校验头压缩耗时抖动大内存池碎片或竞争检查池使用和并发专用池 加锁保护4.2 内存泄漏的隐蔽坑前面提过deflateEnd漏调的问题这里展开说。zlib 的deflateInit2内部会分配状态结构这个结构不小前面算过约 192KB如果某条错误返回路径上忘了调deflateEnd这块内存就泄漏了。嵌入式系统跑几天几夜泄漏累积起来很致命。我的做法是把deflateEnd放在统一的清理标签里所有返回路径都goto cleanup保证必调。int ret_code -1; z_stream strm {0}; if (deflateInit2(...) ! Z_OK) goto cleanup; if (deflate(...) ! Z_STREAM_END) { ret_code -2; goto cleanup; } ret_code 0; cleanup: deflateEnd(strm); return ret_code;这种写法看着土但实测最稳。另外建议在内存池的 alloc/free 回调里加计数跑压力测试时观察计数是否归零能提前发现泄漏。4.3 分段压缩的边界问题数据量大需要分段压缩时有个容易忽略的点deflate用Z_NO_FLUSH分段调用最后必须用Z_FINISH收尾否则输出的比特流不完整解压端会报错。我见过有人分段压完直接结束结果解压时最后一段数据丢失。正确做法是循环里用Z_NO_FLUSH最后一次调用改成Z_FINISH并且循环条件要判断Z_STREAM_END。分段解压同理inflate循环喂数据直到返回Z_STREAM_END才算完。中间返回Z_OK或Z_BUF_ERROR都继续喂但Z_BUF_ERROR要区分是输入不够还是输出不够前者继续喂输入后者扩输出缓冲区。4.4 压缩级别选择的经验压缩级别 1 到 9级别越高压缩率越好但越慢。我实测过同一组日志数据级别 1 压缩率 2.6:1 耗时 8ms级别 6 压缩率 3.2:1 耗时 18ms级别 9 压缩率 3.3:1 耗时 45ms。级别 6 到 9 压缩率提升很小但耗时翻倍多不划算。级别 1 到 6 压缩率提升明显耗时增加可接受。所以 6 级是甜点除非你对压缩率有极致要求且能容忍延迟否则别上 9 级。提示如果业务对延迟极敏感比如中断上下文里压缩可以用级别 1 甚至级别 0不压缩只打包把压缩放到低优先级任务里做。4.5 并发调用的保护如果多个任务同时调压缩接口共用内存池会有竞争问题。zlib 的 z_stream 是每个调用独立的但内存池的 alloc/free 回调如果没加锁多任务并发时会踩内存。我的做法是给内存池操作加互斥信号量或者干脆每个任务用独立的池。前者省内存但可能引入优先级反转后者简单粗暴但吃内存。嵌入式里任务数不多的话独立池更省心。另外 zlib 的crc32函数是线程安全的无全局状态可以放心并发调。但deflateInit2和inflateInit2内部会调 alloc所以锁要加在 alloc 回调里不是加在 init 外面。5. 工程化收尾与扩展思路这套东西在板子上跑了小半年日志压缩存储和配置快照回传两个场景都稳。回过头看最值得强调的经验是嵌入式里做压缩算法本身不是难点难点在内存管理和边界处理。zlib 的代码质量很高接口也成熟真正花时间的是把它塞进受限环境、保证不泄漏、不出界、不误报。后续如果要扩展有两个方向可以考虑。一是把压缩做成流式接口支持边收数据边压适合网络传输场景不用等整包收完再压。二是加一个自适应逻辑根据数据特征自动选压缩级别——比如先采样一小段估算熵熵高就用低级别快速过熵低就用高级别多压点。这个逻辑不难写但需要实际数据调阈值我还没在正式项目里用属于待验证的想法。最后分享一个小技巧调试压缩问题时把压缩后的数据 dump 成文件用 PC 上的工具解一下能快速判断是压缩端的问题还是解压端的问题。比在板子上盲猜高效得多。