1. OTA镜像压缩概述：为什么需要压缩？
大家好，我是你们的老朋友。今天开始聊OTA性能优化，第一个绕不开的话题就是——镜像压缩。
你想想看，一个嵌入式设备要远程升级，最怕什么？怕升级失败、怕流量超标、怕用户等得不耐烦。我做了这么多年OTA，踩过的坑比吃过的盐还多。今天咱们就掰开揉碎，聊聊压缩这件事到底有多重要。
1.1 OTA升级的痛点与挑战
先说说现实情况。OTA升级不是把新固件扔过去就完事了，它面临几个硬骨头：
- 带宽瓶颈：很多物联网设备用的是2G/3G/NB-IoT，带宽低得可怜。一个10MB的镜像，在NB-IoT上可能要传半小时。
- 流量成本：蜂窝网络按流量收费。设备多了，流量费能吃掉项目利润。我见过一个项目，一年流量费比硬件成本还高。
- 存储限制：MCU的Flash通常就256KB~2MB，OTA要留双备份区，留给镜像的空间更紧张。
- 升级时间：用户可没耐心等。车机升级要是超过10分钟，投诉电话就来了。
- 传输可靠性：无线环境不稳定，丢包重传会进一步拖慢速度。
核心矛盾：镜像体积越大，升级成功率越低，用户体验越差。压缩不是可选项，是必选项。
为什么会这样？我举个例子。去年有个智能电表项目，原始固件8MB，客户说直接差分升级就行。结果差分后还有3.2MB，用GPRS传了40分钟，中途断连3次，升级成功率不到70%。后来加了压缩，镜像缩到1.1MB，升级时间降到12分钟，成功率提到95%以上。你看，压缩直接决定了项目成败。
1.2 压缩的核心目标
压缩到底要解决什么问题？说白了就三个：
| 目标 | 说明 | 我见过的实际收益 |
|---|---|---|
| 减小体积 | 让镜像在设备端占更少Flash | 有个项目从4MB压到800KB，双备份区直接省出3.2MB |
| 节省带宽 | 减少传输数据量，降低流量费 | 10万台设备，每台省2MB流量，一年省几十万 |
| 缩短时间 | 减少下载和写入耗时 | 压缩后升级时间平均缩短60%~80% |
这三个目标其实是环环相扣的。体积小了，带宽自然省了，时间也就短了。但要注意，压缩不是越狠越好——压缩率越高，解压时消耗的CPU和内存就越多。嗯，这里要平衡。
我的经验：对于MCU类设备，压缩率控制在40%~60%比较合适。太高的压缩率会让解压时间反超传输节省的时间，得不偿失。
1.3 压缩在OTA流程中的位置
压缩不是孤立的一步，它嵌在整个OTA链路里。我画了张图，你看一眼就明白了：
从图上你能看到，压缩发生在云端生成镜像之后、签名打包之前。设备端下载后先解压，再做差分还原。这个顺序不能乱——先压缩再签名，解压后还要校验签名完整性。
注意：千万不要在压缩后再做差分！压缩会改变数据分布，差分算法对压缩后的数据几乎无效。正确的做法是：先差分，再压缩。我曾经见过有人搞反顺序，结果差分比原始镜像还大，闹了笑话。
1.4 压缩的代价与权衡
压缩不是免费的午餐。它要付出代价：
- CPU开销：解压需要算力。对于主频几十MHz的MCU，解压几百KB的数据可能要几秒钟。
- 内存占用：解压需要缓冲区。有些算法需要几十KB的RAM，对小内存设备是挑战。
- 实时性影响：解压期间不能响应其他任务，可能影响系统实时性。
- 代码复杂度：集成解压库会增加固件体积和维护成本。
我个人习惯的做法是：先评估设备资源，再选压缩算法。如果Flash有富余、CPU够强，就用高压缩率的算法（比如LZMA）。如果资源紧张，就用轻量级的（比如LZSS或gzip）。
避坑指南：我曾经在一个STM32F103项目上用了LZMA，解压时内存爆了。后来换成LZSS，压缩率只差了8%，但内存占用从32KB降到4KB，稳稳的。选算法前，一定先看设备的手册，算清楚剩余RAM。
1.5 本章小结
好了，这一章咱们把压缩的必要性讲透了。总结几个要点：
- OTA升级的痛点集中在带宽、成本、时间、存储四个方面，压缩是解决这些问题的核心手段。
- 压缩的三个目标——减小体积、节省带宽、缩短时间——相互关联，但需要根据设备资源做权衡。
- 压缩在OTA流程中位于差分之后、签名之前，这个顺序不能搞错。
- 压缩有代价，选算法要量力而行，别为了极致压缩率把设备搞崩了。