MediaCodec启动流程概览：从configure到start的完整生命周期

做多媒体开发这几年，我碰到最多的一个问题就是："MediaCodec启动力什么这么慢？" 要回答这个问题，你首先得知道它启动时到底干了些什么。说白了，从你调用 configure() 到真正开始干活 start()，这中间有一整套复杂的流程。

我个人习惯把这段流程拆成三个核心阶段：配置准备、组件创建、状态切换。下面咱们一个一个来看。

阶段一：配置准备（configure）

你调用 configure() 的时候，MediaCodec 干了什么？

• 检查你传进来的 MediaFormat 是否合法。
• 根据 MIME 类型，从系统组件仓库中找到对应的 Codec 组件。
• 分配内部资源（比如输入输出 Buffer 的元数据空间）。
• 如果是 Surface 输入或输出，还要提前准备好 GraphicBuffer 的分配器。

阶段二：组件创建（configure 后半段）

configure 检查通过之后，系统就开始真正创建底层组件了。这一步才是时间的"大头"。嗯，这里要注意，从 Android 框架层看，它做了这些事情：

阶段三：状态切换（start）

当你调用 start() 的时候，MediaCodec 从 Configured 状态切换到 Executing 状态。这一步看起来简单，其实背后也有一堆事儿。

• 所有 Buffer 进入 Dequeued 状态，等待你输入数据。
• 如果是 Surface 输入，这时候会启动 Surface 的管道，等待生产者（比如 Camera 或 Renderer）送数据。
• Codec 内部的工作线程开始循环，准备处理数据。
• 对于硬件编解码器，可能还需要进行一次"预热"（比如加载预缩放参数、色域转换矩阵）。

从代码层面看，start() 会触发一个 start() 的 Binder 调用到服务端，服务端再回调本地的 OnStart 方法。如果服务端当前资源紧张（比如同时有很多 Codec 实例在跑），这个 Binder 调用可能会被排队。

完整生命周期总览

把上面三个阶段串起来，整个启动路径就是：

你想想看，从你第一行 App 代码启动 MediaCodec，到它真正准备好接收数据，最短也要几十毫秒，长的话可能到几百毫秒。这还没算上你准备 MediaFormat 和等待 Surface 就绪的时间。

总结一下

把整个启动流程拆开来看，你会发现最耗时的其实不是 App 层调用的那一瞬间，而是系统内部在 configure() 后半段偷偷做的组件创建和硬件分配。特别是硬件资源排队，你在多线程场景下频繁创建销毁 MediaCodec 的时候，这个问题会特别明显。