11、低延迟解码：低延迟模式配置、减少Buffer堆积、首帧快速显示、直播场景优化
低延迟解码，说白了就是让视频画面更快地出现在屏幕上。
我刚开始做直播SDK时，遇到过用户吐槽：“画面比声音慢半拍，像看译制片。” 嗯，那种体验确实糟糕。今天咱们就聊聊怎么把延迟压到最低。
11.1 低延迟模式配置
Android的MediaCodec从API 21开始支持低延迟模式。但说实话，很多开发者压根没开这个开关。
核心配置代码：
MediaFormat format = MediaFormat.createVideoFormat(MIME_TYPE, width, height);
// 开启低延迟模式
format.setInteger(MediaFormat.KEY_LOW_LATENCY, 1);
// 配置解码器
mCodec = MediaCodec.createDecoderByType(MIME_TYPE);
mCodec.configure(format, surface, null, 0);
mCodec.start();这里有个坑——不是所有芯片都支持这个标志。我在项目中遇到过，某款中端机型上设置了这个参数后，解码器直接罢工。
避坑指南：我曾经在联发科平台上踩过这个雷。建议在初始化后检查一下实际配置是否生效：
// 检查低延迟模式是否生效
MediaFormat outputFormat = mCodec.getOutputFormat();
int lowLatency = outputFormat.getInteger(MediaFormat.KEY_LOW_LATENCY, 0);
if (lowLatency != 1) {
// 降级处理：手动控制Buffer
Log.w(TAG, "低延迟模式未生效，采用手动控制方案");
}11.2 减少Buffer堆积
Buffer堆积是延迟的元凶。你想想看，解码器里塞了十几帧数据，新来的帧只能排队等着，延迟自然就上去了。
我个人习惯用动态Buffer控制策略：
- 输入侧控制：不要一股脑把数据全塞进去
- 输出侧及时取走：解码完一帧就立刻送显
- 监控队列深度：超过阈值就丢帧
// 动态Buffer控制示例
private static final int MAX_INPUT_QUEUE_SIZE = 3; // 最多保留3帧
public void onInputBufferAvailable(MediaCodec codec, int index) {
if (mInputQueue.size() > MAX_INPUT_QUEUE_SIZE) {
// 队列满了，丢弃旧帧
mInputQueue.poll();
Log.d(TAG, "丢弃旧帧，当前队列深度: " + mInputQueue.size());
}
// 正常提交数据
ByteBuffer buffer = codec.getInputBuffer(index);
// ... 填充数据
codec.queueInputBuffer(index, 0, size, pts, flags);
}小技巧：直播场景下，我建议把队列深度控制在2-3帧。太少了容易卡顿，太多了延迟高。这个值需要根据实际网络状况动态调整。
11.3 首帧快速显示
用户打开直播，最烦的就是黑屏等待。首帧显示速度直接影响留存率。
我记得有一次优化直播首开体验，从点击到出画面花了3秒多。后来做了几件事，压到了800ms以内：
- 预创建解码器：在用户点击前就初始化好MediaCodec
- 跳过B帧等待：首帧如果是B帧，直接丢弃等下一个I帧
- Surface提前准备：TextureView/SurfaceView提前创建好
// 首帧快速显示策略
public void onOutputBufferAvailable(MediaCodec codec, int index, MediaCodec.BufferInfo info) {
boolean isFirstFrame = (mRenderedFrameCount == 0);
if (isFirstFrame) {
// 首帧策略：如果是B帧，直接跳过
if (isBFrame(info.flags)) {
codec.releaseOutputBuffer(index, false);
Log.d(TAG, "首帧是B帧，跳过等待I帧");
return;
}
// 立即渲染，不做任何延迟
codec.releaseOutputBuffer(index, true);
mRenderedFrameCount++;
return;
}
// 正常渲染逻辑
// ...
}关键点：首帧显示不要做任何Buffer缓存，拿到就送显。等画面稳定了再开启正常Buffer管理。
11.4 直播场景优化
直播和点播不一样。点播可以预加载几秒，直播不行——延迟就是生命。
我总结了一套直播场景的优化方案：
| 优化项 | 具体做法 | 效果 |
|---|---|---|
| 解码器复用 | 切换频道时不销毁解码器，只重置 | 减少50%切换时间 |
| 动态丢帧 | 网络波动时丢弃非关键帧 | 延迟稳定在1秒内 |
| 渲染线程优先级 | 设置THREAD_PRIORITY_URGENT_DISPLAY | 减少渲染抖动 |
| 音频视频同步 | 以音频时钟为主，视频追赶 | 避免音画不同步 |
// 直播场景：动态丢帧策略
public void handleNetworkFluctuation() {
if (mCurrentLatency > MAX_ACCEPTABLE_LATENCY) {
// 延迟超标，开始丢帧
mDropFrameMode = true;
Log.w(TAG, "网络波动，开启丢帧模式，当前延迟: " + mCurrentLatency + "ms");
}
if (mDropFrameMode) {
// 只渲染I帧和P帧，丢弃B帧
if (isBFrame(currentFrame)) {
skipCurrentFrame();
return;
}
}
}注意：丢帧不能乱丢。我曾经犯过一个错误——连续丢了好几个P帧，结果画面直接花掉了。后来改成只丢B帧，问题解决。
11.5 整体架构图
下面这张图展示了低延迟解码的整体流程：
从这张图可以看出，低延迟解码是一个闭环系统。数据进来后，经过Buffer控制、解码、渲染三个环节，同时监控模块实时反馈，动态调整策略。
我的经验：别指望一个配置解决所有问题。不同机型、不同网络环境，参数都得调。我一般会在后台埋点，收集用户设备的延迟数据，然后针对性地调整策略。
最后说一句，低延迟和流畅度是矛盾的。你压得越狠，卡顿风险越高。找到那个平衡点，才是真本事。