12、Codec2 框架：Codec2 组件模型、与 OMX 的对比、高效编解码实现
好，咱们今天聊聊 Codec2。说实话，Android 多媒体这块，OMX 统治了将近十年。但时代变了，硬件越来越复杂，需求越来越刁钻，OMX 那套老架构有点扛不住了。Google 在 Android 10 开始力推 Codec2，到了 Android 12 之后，基本就是新设备的标配了。
我个人习惯把 Codec2 看作是一次「从底层到上层」的彻底重构。它不是给 OMX 打补丁，而是另起炉灶。你想想看，OMX 是 2000 年初的标准，那时候的手机能干啥？现在呢？4K、HDR、AI 编码、低功耗... 老架构确实力不从心。
12.1 Codec2 组件模型：核心设计思路
Codec2 的组件模型，说白了就是「面向接口编程」的极致体现。它把编解码器抽象成一个个 组件 (Component)，每个组件只干一件事，并且通过标准化的接口对外暴露能力。
核心概念就三个：组件 (Component)、接口 (Interface)、图 (Graph)。
- 组件 (Component)：最基础的执行单元。比如一个 H.264 解码器是一个组件，一个音频混音器也是一个组件。组件内部封装了具体的算法和硬件加速逻辑。
- 接口 (Interface)：组件之间通信的契约。Codec2 定义了一套标准接口，比如
C2Buffer、C2Work、C2Param。所有组件都必须遵守这些接口。 - 图 (Graph)：多个组件连接起来形成的处理流水线。比如「解封装 -> 视频解码 -> 渲染」就是一个典型的图。
关键点：Codec2 的组件是「无状态」的。什么意思？组件本身不保存任何中间状态，所有状态都通过 C2Work 传递。这跟 OMX 那种「组件内部维护状态机」的思路完全不同。
我在项目中遇到过一个问题：OMX 组件在处理异常时，状态机经常卡死，导致整个解码链路挂掉。Codec2 这种无状态设计，说白了就是「一次请求，一次响应」，出错了直接返回错误码，不会把组件搞成僵尸状态。
12.2 与 OMX 的对比：到底强在哪？
咱们直接上对比表，一目了然：
| 对比维度 | OMX (OpenMAX IL) | Codec2 |
|---|---|---|
| 状态管理 | 组件内部维护复杂状态机 (Loaded->Idle->Executing) | 无状态，通过 Work 传递上下文 |
| 线程模型 | 组件内部自行管理线程，回调机制复杂 | 外部驱动管理线程，组件只处理数据 |
| Buffer 管理 | Native Buffer 句柄传递，跨进程开销大 | 使用 C2Buffer 抽象，支持零拷贝 |
| 扩展性 | 添加新功能需要修改规范 | 通过自定义 Param 和 Interface 扩展 |
| 调试难度 | 状态机日志满天飞，定位问题靠猜 | Work 链可追溯，每个步骤清晰可见 |
| 硬件适配 | 需要实现完整的 IL 层，工作量巨大 | 只需实现核心编解码逻辑，框架层代码复用 |
嗯，这里要注意：OMX 并不是一无是处。它最大的优势是「成熟」，市面上几乎所有芯片厂商都支持。但 Codec2 的设计更符合现代软件工程理念——高内聚、低耦合。
我曾经在一个项目里调试 OMX 的 buffer 死锁问题，整整花了三天。最后发现是芯片驱动在 FillBufferDone 回调里做了耗时操作，导致状态机卡在 Executing 状态。换成 Codec2 之后，这种问题基本不会出现，因为 buffer 的流转完全由框架控制，组件只管处理数据。
12.3 高效编解码实现：Codec2 的杀手锏
Codec2 的高效体现在三个层面：Buffer 零拷贝、异步流水线、自适应参数协商。
12.3.1 Buffer 零拷贝
OMX 时代，buffer 从应用层传到驱动层，中间要经过多次内存拷贝。Codec2 引入了 C2Buffer 抽象，底层可以映射到 dma-buf 或者 GraphicBuffer，实现真正的零拷贝。
// Codec2 中创建 Buffer 的典型方式
std::shared_ptr<C2Buffer> buffer = C2Buffer::CreateLinearBuffer(
memory_block, // 可以是 dma-buf fd
offset,
size
);
// 设置元数据
buffer->setInfo(std::make_shared<C2StreamPictureSizeInfo>(
0, // 流 ID
1920, 1080
));你看，buffer 本身携带了元数据，不需要像 OMX 那样通过额外的 SetParameter 来传递。这减少了 IPC 调用次数，性能自然就上去了。
12.3.2 异步流水线
Codec2 的编解码是异步的。组件收到 C2Work 后，立即返回，然后通过回调通知结果。这样框架可以同时调度多个 Work，形成流水线。
我的经验：在实现 Codec2 解码器时，我建议把硬件加速的 submit 和 wait 分开。submit 放在 process() 里，wait 放在 onWorkDone() 回调里。这样能最大化利用硬件 DMA 的并行能力。
// 伪代码：Codec2 解码器的 process 实现
c2_status_t MyDecoder::process(
const std::unique_ptr<C2Work>& work) {
// 1. 解析 Work 中的 input buffer
auto input = work->input.buffers[0];
// 2. 提交到硬件（非阻塞）
int hw_handle = submit_to_hardware(input->data());
// 3. 保存上下文，用于回调
pending_works_[hw_handle] = std::move(work);
return C2_OK; // 立即返回
}
// 硬件完成回调
void MyDecoder::onHardwareDone(int hw_handle) {
auto work = std::move(pending_works_[hw_handle]);
// 4. 填充 output buffer
work->worklets[0]->output.buffers[0] = ...;
work->worklets[0]->output.flags = C2FrameData::FLAG_END_OF_STREAM;
// 5. 通知框架
listener_->onWorkDone(shared_from_this(), std::move(work));
}12.3.3 自适应参数协商
Codec2 支持在运行时动态调整参数。比如视频解码器可以根据当前帧率自动调整输出分辨率，而不需要重新配置整个组件。
注意：自适应参数协商虽然灵活，但容易引入竞态条件。我曾经在调试时发现，如果 setParameter 和 process 同时调用，会导致参数不一致。解决方案是在 process 入口加一个轻量级的读写锁。
12.4 核心流程图：Codec2 编解码数据流
下面这张图展示了 Codec2 从输入到输出的完整数据流。我特意把 Buffer 流转和 Work 调度画在了一起，方便你理解。
12.5 避坑指南：Codec2 开发中的常见问题
最后，分享几个我在实际开发中踩过的坑：
- Work 生命周期管理：
C2Work是 shared_ptr，但要注意循环引用。我曾经在回调里持有了组件的 shared_ptr，导致组件无法释放。解决方案是用 weak_ptr。 - Buffer 对齐要求：硬件解码器通常要求 buffer 地址对齐到 16 字节或 32 字节。Codec2 的
C2MemoryBlock默认不保证对齐，需要手动处理。 - 参数协商时机：不要在
process中间调用setParameter。我建议在onStart阶段完成所有参数协商，运行期间只读不写。 - 性能调优：如果发现编解码帧率上不去，先检查
process的耗时。Codec2 的异步模型下，process应该微秒级返回，否则就是硬件提交部分有阻塞。
我的小技巧：调试 Codec2 时，打开 adb shell dumpsys media.c2，可以查看所有组件的状态、待处理的 Work 数量、buffer 使用情况。这个命令比看 logcat 高效十倍。
好了，关于 Codec2 的组件模型、与 OMX 的对比、以及高效实现，就聊到这里。记住一句话：Codec2 不是 OMX 的替代品，而是对多媒体编解码的重新思考。理解了这个设计哲学，你写出来的组件自然就是高效的。