1. 多媒体工程架构总览：核心分层、模块划分、关键接口、架构演进方向
多媒体工程是 Android 系统中复杂度最高、耦合最深的子系统之一，涉及音视频采集、编解码、渲染、流传输和文件封装/解封装等环节。一个周正的架构方案需要先建立全局分层视图，明确每层的边界、组件职责与数据/控制流走向，再根据业务场景权衡选型并识别潜在风险。本章作为总览，用一张分层结构图配合两种典型数据流（本地回放、推流录制），给出后续章节展开的骨架。
核心主张：多媒体架构应遵循“跨层复用、接口收敛、硬件加速抽象、动态管线化”四项原则。分层清晰后，每层才能独立演进而不破坏信任链路。
核心分层与模块划分
从系统和业务视角出发，Android 多媒体可以切分为四个主要层次，每一层有其独立的数据域和错误域，层间通过定义好的接口进行通信。下表总结了各层的核心模块与关键职责：
| 层次 | 核心模块 | 边界职责 | 典型接口/类型 |
|---|---|---|---|
| 应用层 | MediaPlayer, ExoPlayer, CameraX, 自定义 Surface | UI 交互、生命周期管理、播放/录制状态机 | TextureView, SurfaceHolder, MediaCodec.Callback |
| 多媒体框架层 | MediaExtractor, MediaCodec, AudioTrack, MediaMuxer | 解封装、编解码控制、音轨混合、时钟同步 | MediaExtractor#selectTrack, MediaCodec#dequeueOutputBuffer |
| 硬件抽象层 | Codec2 (OMX), Camera HAL, Audio HAL | 封装硬件差异、提供统一编解码/采集抽象 | IOMX, CameraDevice.createCaptureRequest |
| 驱动 & 内核 | V4L2, ALSA, GPU 驱动, DMA | 实际硬件寄存器操作、缓冲管理、中断处理 | ioctl, mmap, ION |
关键接口与数据流/控制流
多媒体管线中最重要的两条流：数据流（压缩/非压缩音视频帧）和控制流（状态转换、参数配置、同步信号）。以下用两个典型场景说明层间交互：
- 本地文件回放：
MediaSource (File/Content) → MediaExtractor (demux) → MediaCodec (decode) → Surface/AudioTrack
控制流方向：播放器状态机 →seekTo→ Extractor 跳帧 → Codec 刷新 → 渲染同步。 - 实时推流录制：
Camera → ImageReader/Surface → MediaCodec (encode) → MediaMuxer → RTMP Sink
控制流方向：录制状态机 →setInputSurface→ 编码参数 → 流媒体封装。
信任链路风险：框架层对底层 HAL 的调用是单向的，应用代码不能绕过框架直接操作硬件。如果厂商 HAL 实现不符合公版规范，会导致
MediaCodec.dequeueOutputBuffer 返回错误状态且无法恢复。必须通过 CTS 认证的 HAL 实现来保障信任。
选型权衡
在定义项目架构时，有两种主流方案：
- 系统预置 MediaPlayer/MediaCodec 方案：适合标准格式、短周期交付。优势在于集成简单、谷歌维护更新；缺点是定制能力弱，难以支持私有封装格式或特殊后处理。
- 自研 Pipeline（如 ExoPlayer 改造）：适合长线产品、需要自定义协议、渲染链或特效处理。优势是组件可替换、便于性能调优；代价是开发成本高、需要投入持续的兼容性测试。
实际项目中常采用混合策略：视频解码用系统 Codec 保持电池续航，音频后处理用 Native 滤镜管线，流传输层自建 TLS/RTMP 实现。这种组合能最大化复用系统能力，又保留业务灵活性。
风险点与落地步骤
| 风险点 | 说明 | 缓解措施 |
|---|---|---|
| 厂商 Codec 兼容性 | 不同 SoC 对特定分辨率/编码模式的实现存在偏差 | 引入 Codec 适配层 + 运行时特性查询 + 灰名单降级 |
| Surface 生命周期混乱 | Activity 重建或窗口可见性变化导致渲染通道失效 | 统一 Surface 持有者模式 + 校验 isValid() + 双缓冲 |
| 音视频同步漂移 | AudioTrack 时间戳与视频渲染时钟不一致 | 主时钟选择 AudioTrack 的 getTimestamp + 阈值调速 |
| OOM 与 ION 内存泄露 | 大量未释放的编码输出 buffer 导致系统内存耗尽 | 严格遵循 releaseOutputBuffer 时序 + ION 泄漏检测 |
落地步骤建议分三批：第一批（2 周）：搭建最小可播放管线（Extractor + Decoder + Surface），确认核心数据流跑通；第二批（3 周）：引入控制流（Seek、Pause、Loop），集成 DRM 与音轨切换；第三批（2 周）：编解码模式切换、低延迟模式与 HAL 兼容性测试。
验收标准
架构方案通过以下五项检查即视为达标：
- 分层拓扑清晰，所有跨层调用只能经过定义好的接口（如
IMediaPlayer.aidl），无直接引用底层类。 - 两条典型数据流（回放 & 录制）可在 30 帧下连续 8 小时稳定运行，无 OOM 或帧率骤降。
- Seek 到任意位置后音视频重新同步偏差 ≤ 50ms，且不出现爆音。
- 厂商 Codec 兼容性用例覆盖前 10 品牌 Top20 机型，通过率 ≥ 95%。
- 架构文档中标识出所有信任边界（如：应用不可直接调用 Codec2 Native），并有对应的异常处理预案。
进阶视角：Android 13+ 推出的
Codec2 优先 模式将逐步取代 OMX 传统方案，新项目宜直接选择 Codec2 HAL 作为底层编解码抽象，以获取更好的低延迟和可扩展性。