11. 媒体数据缓冲与缓存：BufferQueue、Cache策略、预加载与流媒体缓冲
各位同学，今天我们来聊聊多媒体框架里一个特别“接地气”的话题——数据缓冲与缓存。
说实话，做多媒体开发这么多年，我见过太多“卡成幻灯片”的惨案。很多时候，问题就出在数据没管好。你想想看，视频数据一秒钟几十帧，音频数据一秒钟几万个采样点，如果系统不搞一套高效的缓冲机制，那播放器早就崩了。
Stagefright 在这块做得相当扎实。它把数据流动的每个环节都安排得明明白白。我个人习惯把这一章的内容分成三个层面来看：数据怎么传、数据怎么存、数据怎么提前拿。咱们一个一个说。
11.1 BufferQueue：数据流动的“高速公路”
先说 BufferQueue。这东西是 Android 多媒体里最核心的数据传输通道。说白了，它就是一个生产者-消费者模型。
生产者（比如 Camera、解码器）把数据填进 Buffer，消费者（比如显示系统、编码器）从 Buffer 里取数据。两边各干各的，互不阻塞。
我记得在 Android 4.4 时代，BufferQueue 还比较简单。后来为了支持更复杂的场景，Google 给它加了很多特性，比如异步模式、丢弃策略、帧时间戳等等。
来看一个典型的 BufferQueue 工作流程：
// 生产者端（例如 MediaCodec 输出）
sp<IGraphicBufferProducer> producer = surface->getIGraphicBufferProducer();
BufferItem item;
status_t err = producer->dequeueBuffer(&buf, &fence);
// 填充数据...
producer->queueBuffer(buf, ...);
// 消费者端（例如 SurfaceFlinger）
sp<IGraphicBufferConsumer> consumer = ...;
BufferItem item;
status_t err = consumer->acquireBuffer(&item, ...);
// 处理数据...
consumer->releaseBuffer(item.mBuf, ...);
这里有个关键点：Buffer 是复用的。生产者用完一个 Buffer，消费者消费完，它又回到池子里。这样避免了频繁的内存分配和释放。
核心要点：BufferQueue 的深度（即最多允许多少个 Buffer 在队列中）直接影响延迟和吞吐量。深度越大，吞吐量越高，但延迟也越大。一般视频播放用 3-4 个 Buffer，游戏场景可能用 2 个。
我曾经在一个项目中遇到过 BufferQueue 被撑爆的情况。当时是 4K 视频录制，生产者（Camera）输出太快，消费者（编码器）处理不过来，结果 BufferQueue 满了，生产者直接丢帧。后来我调整了 Buffer 数量和消费者线程优先级，问题才解决。
11.2 Cache 策略：谁该被留下，谁该被淘汰
BufferQueue 解决的是“数据怎么流动”，而 Cache 解决的是“数据怎么存”。
Stagefright 里没有统一的全局缓存管理器，但各个组件都有自己的缓存策略。比如 NuPlayer 的 Decoder 会缓存解码后的帧，DataSource 会缓存网络读取的数据块。
常见的缓存策略有这么几种：
- LRU（最近最少使用）：淘汰最久没被访问的数据。适合大多数场景。
- FIFO（先进先出）：按时间顺序淘汰。适合流媒体这种顺序访问的场景。
- LFU（最不经常使用）：淘汰访问次数最少的数据。适合有热点数据的场景。
在流媒体播放中，我建议使用 LRU + 预加载窗口 的组合策略。什么意思呢？就是缓存最近解码的几帧，同时根据网络状况提前加载后续数据。
避坑指南：我曾经在低端设备上遇到过缓存命中率极低的问题。后来发现是缓存大小设置不合理——太小了，数据刚放进去就被挤出去。建议根据设备内存和视频分辨率动态调整缓存大小。
11.3 预加载：让数据“跑”在播放前面
预加载是流媒体播放的“杀手锏”。没有预加载，用户看视频就会频繁卡顿。
Stagefright 的 NuPlayer 里有一个 Prepared 状态，其实就是预加载阶段。在这个阶段，播放器会尽可能多地读取数据，直到达到某个阈值（比如 10 秒的数据量），然后才开始播放。
预加载的核心参数有两个：
| 参数 | 说明 | 典型值 |
|---|---|---|
| 预加载时长 | 开始播放前需要缓冲的数据量（以时间计） | 5-15 秒 |
| 低水位线 | 当缓冲数据低于此值时，触发重新缓冲 | 2-5 秒 |
| 高水位线 | 当缓冲数据达到此值时，停止预加载 | 30-60 秒 |
嗯，这里要注意：预加载不是越多越好。你想想看，如果用户只看了 10 秒就退出，你预加载了 60 秒的数据，那 50 秒的流量就白费了。所以要根据用户行为动态调整。
11.4 流媒体缓冲：应对网络波动的“减震器”
流媒体缓冲和本地播放的缓冲不太一样。本地播放的缓冲主要是为了平滑解码和显示之间的速度差异，而流媒体缓冲还要应对网络波动。
Stagefright 的流媒体缓冲机制大致是这样的：
- 网络读取线程：从服务器拉取数据，放入缓冲区。
- 解码线程：从缓冲区取出数据，进行解码。
- 缓冲状态监控：实时监控缓冲区水位，决定是否暂停播放或降低码率。
我参与过一个项目，用户反馈在弱网环境下播放总是卡顿。排查后发现是缓冲策略太“死板”——不管网络好坏，都按固定大小缓冲。后来我们改成了自适应缓冲：网络好时少缓冲，网络差时多缓冲。效果立竿见影。
警告：不要在主线程中执行缓冲操作！我曾经见过有人直接在 UI 线程里调用 read()，结果网络一慢，整个界面都卡死了。缓冲操作一定要放在独立线程中。
11.5 整体架构图
下面这张图展示了 Stagefright 中数据缓冲与缓存的整体架构。你可以看到数据从网络/文件读取，经过 BufferQueue 传递，再到解码器、渲染器的完整路径。
从这张图你可以看到，数据从源头到显示，中间经过了多层缓冲和缓存。每一层都有自己的职责，也都有自己的“坑”。
11.6 总结与建议
好了，这一章的内容就到这里。我最后给你几个实战建议：
- BufferQueue 深度不要设死：根据分辨率和帧率动态调整。4K 视频建议 4-5 个 Buffer，1080p 可以 3 个。
- 缓存策略要区分场景：直播用 FIFO，点播用 LRU，短视频用 LFU。
- 预加载要“看人下菜碟”：WiFi 环境下多预加载，移动网络下少预加载。
- 监控水位线是必须的：没有监控的缓冲就是“盲人摸象”。
做多媒体开发，说白了就是跟数据流打交道。你把缓冲和缓存搞明白了，一半的问题就解决了。剩下的，就是跟编解码器、渲染器这些“硬骨头”死磕了。
一句话总结：BufferQueue 管传输，Cache 管存储，预加载管时机，流媒体缓冲管网络。四者配合好了，你的播放器才能“丝般顺滑”。
公众号:蓝海资料掘金营，微信deep3321