3. MediaCodec同步模式与异步模式对比归纳总结

做多媒体开发的兄弟们，肯定绕不开MediaCodec。这东西的两种工作模式——同步和异步，我花了很长时间才真正吃透。今天咱们就掰开揉碎了聊，把它们的区别、适用场景、以及实际项目中的坑，一次性说明白。

3.1 两种模式的核心差异

说白了，同步模式就是“你等它”，异步模式就是“它通知你”。
我个人习惯这样理解：同步像个排队办事的窗口，你递一个请求就得等到结果回来，才能干下一件事。异步像个叫号系统，你注册一个监听器，系统处理完了喊你一声。

维度同步模式异步模式
API调用方式dequeueInputBuffer() / dequeueOutputBuffer() 阻塞或超时onInputBufferAvailable() / onOutputBufferAvailable() 回调
线程模型通常在主线程或单一工作线程串行调用需要配合HandlerThread或独立Looper
CPU占用忙等或轮询，易拉高CPU回调触发，空闲时不耗CPU
延迟抖动受dequeue超时影响，可能导致卡顿由框架主动推送，更平滑
编码器兼容性几乎所有设备都支持部分低端芯片或旧版本有坑
调试复杂度逻辑直观，好排查回调间状态管理易出错

我当年踩过一个坑：某项目在小米9上同步模式跑得稳稳当当，换到三星S10就偶发15ms以上的dequeueOutputBuffer超时。后来追查发现，厂商HAL层实现不同，同步模式下的内部缓冲区管理策略差异很大。嗯，异步模式虽然代码写起来麻烦点，反而能把这个抖动抹平。

3.2 同步模式详解

这是最传统的用法。你调用 dequeueInputBuffer 拿到一个输入槽，往里面填数据，然后 queueInputBuffer 扔回去。输出端同理，不断轮询 dequeueOutputBuffer。

// 同步模式典型伪代码
MediaCodec codec = MediaCodec.createDecoderByType(mimeType);
codec.configure(format, surface, null, 0);
codec.start();

while (!isEOS) {
    // 输入端
    int inIndex = codec.dequeueInputBuffer(TIMEOUT_US);  // 超时10ms
    if (inIndex >= 0) {
        ByteBuffer inputBuffer = codec.getInputBuffer(inIndex);
        // 从文件/网络读数据填充
        inputBuffer.put(data);
        codec.queueInputBuffer(inIndex, 0, data.length, pts, flags);
    }

    // 输出端
    MediaCodec.BufferInfo info = new MediaCodec.BufferInfo();
    int outIndex = codec.dequeueOutputBuffer(info, TIMEOUT_US);
    if (outIndex >= 0) {
        codec.releaseOutputBuffer(outIndex, true);  // 渲染到surface
    } else if (outIndex == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {
        // 处理格式变化
    }
}

⚠️ 常见两种死锁：

  • dequeueInputBuffer 超时设得太小（比如1ms），频繁返回 -1 导致空转，CPU打满。
  • dequeueOutputBuffer 在解复用线程和渲染线程之间互相等待，我见过一个案例，主线程卡在dequeue上，导致ANR。

3.3 异步模式详解

Android 5.0（API 21）之后引入了异步模式。你注册回调，不用自己轮询。框架内部用Handler把可用buffer推给你。代码结构更清晰，但线程模型要小心。

// 异步模式典型实现
codec.setCallback(new MediaCodec.Callback() {
    @Override
    public void onInputBufferAvailable(MediaCodec codec, int index) {
        // 咱不用自己取，框架直接给下标
        ByteBuffer buffer = codec.getInputBuffer(index);
        // 填数据… 
        codec.queueInputBuffer(index, 0, size, pts, flags);
    }

    @Override
    public void onOutputBufferAvailable(MediaCodec codec, int index, BufferInfo info) {
        // 输出就绪，直接渲染或处理
        codec.releaseOutputBuffer(index, true);
    }

    @Override
    public void onOutputFormatChanged(MediaCodec codec, MediaFormat format) {
        // 处理宽高变化等
    }

    @Override
    public void onError(MediaCodec codec, MediaCodec.CodecException e) {
        // 错误处理，千万别忽略
    }
});

// 必须指定一个HandlerThread或Looper
HandlerThread handlerThread = new HandlerThread("CodecCallback");
handlerThread.start();
codec.configure(format, surface, null, 0);
codec.start(); // 启动后会立刻触发onInputBufferAvailable

💡 小技巧：我曾经在华为P40上遇到回调不触发的问题。排查半天才找到原因——configure 必须在设置Looper的线程中调用。建议统一用 HandlerThread 管理，别在主线程里玩异步。

3.4 什么时候选同步？什么时候选异步？

这个我整理了一个决策指南，你对照着看：

  • 选同步：
    • 只需要编解码一个短片段（比如录制几秒视频）
    • 项目工期紧，不想搞复杂的线程管理
    • 用户设备全盘测试过，dequeue超时可接受
    • 代码需要兼容Android 4.4及以下（其实现在很少了）
  • 选异步：
    • 长时间播放 / 直播 / 实时通信场景
    • 需要精确控制渲染时序（比如VR）
    • 想要更低的CPU占用和更平滑的帧率
    • 团队有能力处理回调间的状态同步

你想想看，一个实时滤镜相机，每帧都要快速处理，同步模式下的轮询延迟累积起来，很容易出现掉帧。相反，异步回调里可以直接把buffer送进GL管线，几乎零额外延迟。

3.5 核心思维导图：两种模式对比流程

MediaCodec同步 vs 异步 对比流程图 同步模式（阻塞/轮询） dequeueInputBuffer(timeout) queueInputBuffer(index..) dequeueOutputBuffer(timeout) releaseOutputBuffer(index..) 异步模式（回调驱动） onInputBufferAvailable() queueInputBuffer(index..) onOutputBufferAvailable() releaseOutputBuffer(index..) 不同的触发方式 核心对比节点 同步：代码简单，但CPU空转 & 延迟抖动 异步：代码复杂，但CPU低耗 & 帧率平滑 选型看场景：短片段用同步，长流用异步

3.6 性能调优要点

我总结了几条实战经验，都是在线上产品中踩过的坑：

  1. 超时值别乱写。同步模式下dequeue超时，建议设成10~20ms。太短导致高频轮询，太长会放大卡顿感。
  2. 异步模式一定用独立的HandlerThread。别在主线程Looper上注册回调，否则回调里稍微做点重活，整个UI就卡了。我曾经在回调里直接做图像裁剪，导致帧率掉到15fps。
  3. Buffer复用很重要。不管是同步还是异步，拿到input/output buffer后尽量复用ByteBuffer，减少GC。
  4. 注意BufferInfo的presentationTimeUs。输出回调中这个时间戳必须严格单调递增，否则MediaMuxer混流时会报错，甚至花屏。
  5. 异步模式下的STATE_ERROR状态。一旦 onError 被调用，codec就废了，必须stop+release。别尝试继续操作。

💡 我的避坑习惯：写异步回调时，我习惯在 onOutputBufferAvailable 里加一个计数器，如果连续50次回调没有收到格式变化，就主动做一次格式查询。为什么？因为某些芯片在首帧回调中不一定会先触发 onOutputFormatChanged，导致解码出来的画面宽高不对。

3.7 选型建议

如果你现在要设计一个新的播放器或录制模块，我的建议很直接：

  • 新项目、API 21+：无脑选异步模式。代码结构干净，性能上限更高。
  • 旧项目维护或兼容低版本：用同步模式加检查。记得加上 video decoder 和 audio decoder 的独立超时监控。
  • 实时音视频（WebRTC风格）：必须异步。同步模式下的dequeue阻塞会打穿整个流水线。

嗯，这次就聊到这儿。同步和异步没有的好坏，关键看你项目的具体场景。选对了，卡顿少一半；选错了，后面调优够你喝一壶。

← 上一章 📖 返回目录 下一章 →