第3章压缩算法选型

3、压缩算法选型：gzip、zstd、lz4在OTA场景下的对比与选择

说到OTA升级，压缩算法这块儿，我估计不少朋友第一反应就是「用gzip呗，稳」。嗯，确实稳。但稳不代表最优。我在几个车联网项目里踩过坑之后，才真正意识到——选压缩算法，本质上是在跟时间、空间、算力这三个「冤家」做博弈。

今天咱们就掰开揉碎，聊聊gzip、zstd、lz4这三兄弟，在OTA场景下到底该怎么选。

先简单过一遍它们各自的特点。你心里有个底，后面才好对号入座。

算法	压缩比（典型值）	压缩速度	解压速度	内存占用
gzip（-6）	2.5~3.0	中等（~50 MB/s）	中等（~100 MB/s）	~256 KB
zstd（-3）	2.8~3.2	快（~300 MB/s）	快（~500 MB/s）	~1 MB
lz4（默认）	2.0~2.2	极快（~500 MB/s）	极快（~1 GB/s）	~16 KB

你看，gzip像个老黄牛，干活稳但慢。lz4像个短跑运动员，快得离谱但压缩率一般。zstd呢？它像个全能选手，各方面都拿得出手。

但光看表格不够。咱们得结合OTA场景，一个个说。

gzip是Linux世界的标配。几乎每个嵌入式Linux系统里都自带。我最早做OTA时，想都没想就用了它。为什么？省心啊，不用额外移植库，系统自带，拿来就用。

但后来我发现一个问题——压缩时间太长。

有一次，一个固件包大概200MB，用gzip -6压缩，在服务器上花了将近4秒。你想想看，如果同时有几千台设备请求升级，服务器CPU直接被打满。更麻烦的是，有些低端MCU解压gzip时，内存和CPU都吃紧，解压一个包能卡死整个系统。

注意：gzip的压缩和解压都需要较大的内存缓冲区。在资源受限的MCU上，解压gzip可能导致堆栈溢出。我曾经在一个只有64KB RAM的芯片上吃过这个亏，解压到一半直接复位了。

所以我的建议是：如果你的设备是Linux服务器端，且对压缩时间不敏感，gzip仍然可用。但如果是MCU端或者高并发场景，我建议你慎重。

lz4是我个人比较偏爱的算法。为什么？因为它快得让人上瘾。

我记得有一次做车载T-Box的OTA升级。那个MCU主频只有120MHz，RAM 256KB。用gzip解压，一个10MB的差分包要解压将近30秒。换成lz4之后，同样的包，解压时间直接降到3秒以内。用户体验提升了一大截。

但lz4有个硬伤——压缩率低。同样一份固件，gzip能压到30MB，lz4可能只能压到45MB。这意味着什么呢？意味着下载时间变长了。如果你的设备走的是2G/3G网络，或者流量很贵，那lz4就不太合适。

    适用场景总结：
    MCU端、资源受限设备：lz4解压快，内存占用低，首选
高并发服务器：lz4压缩快，CPU开销小，适合大规模推送
网络带宽充足但设备性能差：lz4能显著缩短升级时间

zstd是Facebook开源的算法。说实话，我第一次接触它时，心里是有点抵触的——又来个新算法，生态行不行啊？但用完之后，我服了。

zstd最大的优势是可调节的压缩级别。从-1到-22，你可以在压缩速度和压缩比之间自由选择。我习惯在服务器端用zstd -3，压缩速度比gzip快5倍以上，压缩比还略高一点。在设备端，解压速度也比gzip快3~4倍。

举个例子。一个50MB的固件包：

你看，zstd在压缩比上赢了gzip，在速度上虽然不如lz4，但差距不大。说白了，它是个「我全都要」的选手。

我的个人习惯：在服务器端，我会用zstd -3做压缩。在设备端，如果RAM足够（>512KB），我会用zstd解压。如果RAM紧张，我会退回到lz4。这样既保证了压缩率，又兼顾了设备性能。

说了这么多，到底怎么选？我整理了一个简单的决策流程，你照着走一遍基本不会错。

    一句话总结：
    资源受限、追求速度 → lz4
带宽紧张、追求压缩率 → zstd（推荐）或 gzip
既要又要还要 → zstd，它是最平衡的选择

最后分享几个我踩过的坑，你遇到了能少走弯路。

我曾经...在一个项目里，为了追求极致压缩比，用了zstd -22。结果压缩一个100MB的包花了将近1分钟，服务器CPU直接飙到100%。后来我才意识到，OTA场景下，压缩是在服务器端做的，但服务器资源也是成本。别为了省几MB流量，把服务器搞崩了。

还有一点要注意：压缩算法的兼容性。有些老旧的Linux内核（比如2.6.x）不支持zstd。如果你要兼容这些系统，老老实实用gzip。别问我怎么知道的——有一次升级一个2012年的设备，发现内核里没有zstd模块，临时改方案，折腾了两天。

嗯，关于压缩算法选型，今天就聊到这儿。下一章咱们聊聊差分算法，那又是另一个有意思的话题了。