1. 压缩概述：为什么需要压缩、压缩的收益与成本、压缩的分类
各位同学，咱们今天聊聊压缩。说实话，我在做接口优化之前，对压缩的理解也就停留在「把文件变小」这个层面。直到有一次线上事故，让我彻底改观了。
那是一个视频流接口，高峰期带宽被打满，用户端卡得不行。我查了半天，发现原始数据根本没做任何压缩，一个 4K 帧直接裸传。嗯，从那以后，压缩就成了我接口设计里的必选项。
1.1 为什么需要压缩
你想想看，显示接口传输的是什么？是像素、是帧、是海量的颜色数据。一个 1920×1080 的 RGBA 帧，不压缩的话有多大？
1920 × 1080 × 4 字节 = 8,294,400 字节 ≈ 7.9 MB如果每秒 60 帧，那就是 474 MB/s 的带宽需求。这还只是一个通道。真实场景下，多路视频、高分辨率、高帧率并存，带宽压力可想而知。
我个人习惯把压缩的必要性归纳为三点：
- 带宽瓶颈：物理链路总有上限，压缩是绕过瓶颈最直接的手段
- 存储成本：原始数据存起来太贵，压缩能省下真金白银
- 响应速度：数据量小了，传输时间自然缩短，用户体验提升
核心观点：压缩不是锦上添花，而是接口设计中必须考虑的基础能力。不做压缩的接口，就像没装刹车的车——能跑，但不敢跑快。
1.2 压缩的收益与成本
收益大家都懂，但成本往往被忽略。我在项目中遇到过几次「为了压缩而压缩」的案例，最后得不偿失。咱们用一张表说清楚：
| 维度 | 收益 | 成本 |
|---|---|---|
| 带宽 | 传输数据量减少 50%~90% | 压缩/解压占用额外带宽（可忽略） |
| 存储 | 磁盘/内存占用大幅降低 | 压缩算法需要额外存储空间（临时缓冲区） |
| 延迟 | 网络传输时间缩短 | 压缩/解压增加计算延迟 |
| CPU | 减少 I/O 等待，CPU 利用率更均衡 | 压缩/解压消耗 CPU 周期 |
| 功耗 | 传输功耗降低 | 计算功耗增加（移动端尤其敏感） |
避坑指南：我曾经在一个低功耗嵌入式项目里用了高压缩比的算法，结果解压功耗比传输功耗还高，电池续航直接砍半。后来换成了轻量级压缩，才平衡过来。压缩不是越狠越好，得看场景。
说白了，压缩的本质是用计算换空间。计算资源便宜、带宽贵的时候，压缩就划算；反过来，如果 CPU 是瓶颈，那就要慎重。
1.3 压缩的分类：有损 vs 无损
这是压缩领域最基础的分水岭。我习惯用一个问题来区分：解压后的数据，和原始数据一模一样吗？
- 一模一样 → 无损压缩
- 不一样但人眼/系统可接受 → 有损压缩
无损压缩
无损压缩的特点是：解压后数据完全恢复，不丢任何信息。常见的算法有：
- Run-Length Encoding (RLE)：适合连续重复数据，比如大面积纯色背景
- LZ77 / LZ78：字典类压缩，PNG、ZIP 都在用
- Huffman 编码：根据字符频率分配变长编码
- 算术编码：比 Huffman 压缩率更高，但计算更复杂
在显示接口里，无损压缩常用于屏幕共享、远程桌面、医疗影像这些场景——丢一个像素都可能出问题。
有损压缩
有损压缩允许丢失一些人眼不敏感的信息，换来更高的压缩比。常见算法：
- JPEG：基于 DCT 变换，丢弃高频细节
- WebP：Google 出品，支持有损/无损双模式
- AVIF：基于 AV1，压缩率比 JPEG 高 50%
- 视频编码 (H.264/H.265/AV1)：帧内+帧间预测，压缩比极高
有损压缩在视频流、图片传输、游戏串流里是主流。用户更在意流畅度，而不是每个像素的精确值。
我的经验：做接口设计时，我通常先问业务方「数据能不能丢？」。如果能接受有损，压缩比直接拉满；如果不能，就选无损里最快的算法。别上来就套用通用压缩库，先搞清楚约束条件。
1.4 压缩知识体系总览
下面这张图，是我自己梳理的压缩技术全景。你可以把它当作整个课程的地图：
这张图把压缩技术分成了六个层次。咱们这章站在最顶层，先建立全局认知。后面每一章都会深入其中一个节点，从算法原理到工程实现，一步步拆解。
1.5 小结
这一章咱们聊了三件事：
- 为什么需要压缩——带宽、存储、速度，三个硬约束
- 压缩的收益与成本——用计算换空间，但要注意平衡点
- 有损 vs 无损——核心区别在于数据能否完全恢复
我个人觉得，理解压缩的关键不在于记住多少算法名字，而在于建立「成本意识」。每次做压缩选型时，多问自己一句：这个场景下，我到底在优化什么？带宽？延迟？还是功耗？
想清楚这个，后面的技术细节才有落脚点。