1. Stagefright概述：多媒体框架演进史、Stagefright在Android中的地位、与OpenMAX的协作关系
大家好，我是你们的老朋友。今天咱们正式开讲Stagefright。
说实话，每次带新人时，我总会被问到同一个问题："Android播放视频到底是怎么跑的？" 嗯，这个问题看似简单，但背后牵扯的东西可不少。今天这第一讲，我们先搭个骨架，把Stagefright的来龙去脉、它在Android体系中的位置，以及它和OpenMAX怎么配合的，一次性讲清楚。
1.1 多媒体框架的演进：从CPlayer到NuPlayer
Android的多媒体播放框架，其实经历过好几轮迭代。我入行那会儿，Android 2.x时代还在用CPlayer，那是个基于OpenCORE的庞然大物。说白了，OpenCORE是PacketVideo公司贡献的，功能很全，但太臃肿了。你想想看，一个播放器框架，代码量几十万行，光是状态机就能绕晕人。
后来Google实在受不了了，在Android 2.3开始引入Stagefright。我记得当时我们团队做移植，看到Stagefright的代码量只有OpenCORE的十分之一，大家都松了一口气。Stagefright的设计哲学很明确：轻量、高效、专注硬件加速。
再往后，Android 4.0时代又冒出了NuPlayer。这玩意儿是Stagefright的进化版，主要解决了一个痛点——直播流的处理。NuPlayer把播放器拆成了更细粒度的组件，比如Decoder、Renderer、DataSource，每个组件都可以独立替换。我在项目中遇到过，有些芯片厂商的硬件解码器接口不标准，NuPlayer的组件化设计让我们只需要替换Decoder模块，其他代码完全不用动。
到了Android 5.0以后，NuPlayer基本成了默认播放器，Stagefright则退居二线，主要负责一些底层解码任务。但不管怎么变，Stagefright的核心思想一直延续至今。
- OpenCORE → Stagefright → NuPlayer，这是Android多媒体框架的三次迭代
- Stagefright的诞生是为了替代臃肿的OpenCORE，追求轻量和高效
- NuPlayer是Stagefright的进化版，主要增强了直播和组件化能力
1.2 Stagefright在Android中的地位
Stagefright在Android系统里到底扮演什么角色？我用一句话概括：它是Android多媒体子系统的"交通枢纽"。
你看这张图就明白了：
从这张图你能看到，Stagefright处于中间层。往上，它接收来自MediaPlayer或ExoPlayer的Java调用；往下，它调度解封装器、解码器、渲染器，最终把数据送到硬件。说白了，它就是那个"承上启下"的角色。
我个人习惯把Stagefright比作一个项目经理。它自己不干具体的活（比如解码、渲染），但它知道什么时候该叫谁干活，干完了怎么把结果拼起来。你想想看，如果没有这个项目经理，应用层就得直接跟硬件解码器打交道，那代码得乱成什么样？
1.3 Stagefright与OpenMAX的协作关系
聊完Stagefright的地位，咱们得说说它跟OpenMAX怎么配合。OpenMAX全称是Open Media Acceleration，是Khronos组织定义的一套多媒体加速标准。Android从2.3开始就把它作为硬件解码的标准接口。
为什么需要OpenMAX？原因很简单：硬件解码器千奇百怪。高通有高通的解码器，MTK有MTK的解码器，全志有全志的解码器。如果没有一个统一接口，Stagefright得为每个芯片写一套适配代码，那工作量就太大了。
OpenMAX IL（Integration Layer）定义了这样几个核心角色：
| 角色 | 职责 | 类比 |
|---|---|---|
| Client | 使用OpenMAX组件的调用者（即Stagefright） | 项目经理 |
| Component | 具体的编解码器实例 | 工人 |
| Tunnel | 组件之间的直接数据通道 | 传送带 |
| Port | 组件的输入/输出端口 | 工位 |
Stagefright和OpenMAX的协作流程，我总结为三步：
- 组件发现：Stagefright通过
OMXMaster扫描系统里的OpenMAX组件库，找到匹配的解码器。比如你要播放H.264视频，它会找名字里带"AVC"或"H264"的组件。 - 状态机驱动：OpenMAX组件有明确的状态机：Loaded → Idle → Executing → Pause。Stagefright通过调用
OMX_SendCommand来驱动状态切换。嗯，这里要注意，状态切换是异步的，Stagefright必须等待组件回调OMX_EventCmdComplete才能继续下一步。 - 数据流转：Stagefright把压缩的视频数据通过
OMX_EmptyThisBuffer送给解码器，解码器解码完成后通过OMX_FillThisBuffer把原始图像数据返回。这个过程是流水线式的，可以同时有多个buffer在流转。
我举个例子，你感受一下：
// Stagefright 调用 OpenMAX 解码的简化流程
// 1. 找到组件
sp<OMXNodeInstance> node = omx->getNode("OMX.qcom.video.decoder.avc");
// 2. 设置端口参数
OMX_VIDEO_PARAM_PORTFORMATTYPE format;
format.nPortIndex = 0; // 输入端口
format.eCompressionFormat = OMX_VIDEO_CodingAVC;
omx->setParameter(node, OMX_IndexParamVideoPortFormat, &format);
// 3. 切换到执行状态
omx->sendCommand(node, OMX_CommandStateSet, OMX_StateExecuting);
// 4. 等待回调
// ... 收到 OMX_EventCmdComplete 后继续
// 5. 送数据解码
omx->emptyBuffer(node, inputBuffer);
// 解码完成后，从输出端口取数据
omx->fillBuffer(node, outputBuffer);
这段代码看起来简单，但实际项目中坑不少。我曾经遇到过一个情况：某款芯片的OpenMAX组件在状态切换时，回调顺序跟标准不一样。Stagefright按照标准流程等OMX_EventCmdComplete，结果一直等不到，导致播放卡死。最后我们不得不给Stagefright打了一个补丁，增加超时机制。
1.4 小结
好了，第一讲的内容就到这里。我们回顾一下：
- Android多媒体框架从OpenCORE演进到Stagefright，再到NuPlayer，核心趋势是轻量化、组件化、硬件加速
- Stagefright在Android体系中扮演中间调度层的角色，连接Java应用和底层硬件
- Stagefright通过OpenMAX IL标准与硬件解码器协作，统一了不同芯片的适配接口
下一讲，我们会深入Stagefright的源码，看看它的核心类结构和状态机是怎么设计的。到时候我会带大家手撕AwesomePlayer的代码，敬请期待。