今年非常有幸地入选为Google summer of code 2022活动的贡献者。我参与的项目是将一个RPC库移植到开源RTOS Zephyr上。这个库依赖Zlib来压缩和解压RPC消息，但是Zlib的实现对于嵌入式平台来说太重了，因此我需要找到一个替代的轻量级库。
Zlib产生的压缩格式是遵从RFC-1950 ZLIB或者RFC-1951 DEFLATE标准的（RFC-1950比RFC-1951格式多一层封装），所以只要是能压缩和解压DEFLATE标准数据的库都可以用——我一开始是这么想的。但DEFLATE这个格式另有玄机：它支持流式操作，也就是说用于通信的时，发送方可以边压缩边发送，接收方可以边接受边解压，而不必等到一帧数据全部压缩完两边再开始通信。虽然Github上支持DEFLATE压缩和解压的库已经有很多了，但支持流式操作的却很少，并且各自都使用的是不同的API。
因为是移植工作，我希望尽量不要改变上游库的原有代码，同时这个库还需要流式操作的支持，我就对Github上原有的两个DEFLATE压缩和解压库进行封装和改写，从而暴露出和Zlib部分兼容的API。我想在移植其他的库或者程序到嵌入式平台的时候，Zlib也是一个很常见的依赖，而这个库允许开发者在几乎不改动原库的前提下把Zlib替换成一个轻量实现，因此应该还会有更多人用到，故为它建立了开源仓库：
https://github.com/SdtElectronics/muzic
最近编辑记录 SdtElectronics (2022-07-19 18:40:58)
离线
相比zlib，程序体积，压缩率，性能 这块主要差异是啥？
体积和内存占用对比数据已经更新到了GitHub仓库的readme上。在最小的示例程序上二进制体积节省1倍，峰值内存占用节省6倍以上。
性能和压缩率还没有测试。这个测起来会比较复杂，和压缩数据的特性、Zlib采用的压缩比率都会有关系；不同压缩比率下的内存占用又肯定不一样了。以后有时间补上尽量完善的对比吧。
离线