Android 多媒体体系完整总结

📚 Android 多媒体体系完整总结

一、官方 Android 多媒体栈

1. 应用层

VideoView
- UI 控件，最简单的播放方式。
- 内部封装 MediaPlayer，自动解码+渲染。
- 优点：快速开发；缺点：可控性差。
MediaPlayer
- Java 播放器类，支持音视频播放。
- 内部调用 MediaCodec 或系统解码器。
- 控制能力比 VideoView 强，但仍有限。

2. 编解码 API

MediaCodec (Java API)
- Java 层直接控制编解码器。
- 适合逐帧处理、视频编辑、硬件加速解码。
- 优点：和 UI 结合方便；缺点：JNI 开销。
AMediaCodec (NDK API)
- NDK 提供的 C/C++ 接口，功能几乎等同于 MediaCodec。
- 优点：避免 JNI 开销，性能更好；和 C/C++ 库结合更自然。
- 缺点：文档少，调试难度高。
- 使用场景：播放器内核、游戏引擎、跨平台项目、嵌入式系统。

3. 框架内部

Stagefright
- Android 内置多媒体框架。
- 负责封装/解封装、调度编解码器、同步音视频。
- 对上层提供 MediaCodec/MediaPlayer。

4. 硬件抽象层

OMX (OpenMAX IL)
- Khronos 标准接口，用于抽象硬件编解码器。
- 芯片厂商实现 OMX 插件，提供硬件加速。
- 普通开发者不会直接使用。

二、第三方生态

FFmpeg：跨平台完整多媒体库，功能全，但 Android 不内置。
ExoPlayer：Google 官方开源播放器库，基于 MediaCodec，支持流媒体。
VLC/IJKPlayer/Vitamio：第三方播放器 SDK，常基于 FFmpeg。
GPU/硬件接口：OpenGL ES/Vulkan，用于渲染和特效。

三、为什么选 MediaCodec vs AMediaCodec

✅ 选择 MediaCodec 的理由

语言栈：主要用 Java/Kotlin 开发 App。
UI 集成 ：需要和 SurfaceView、TextureView 等控件结合。
开发效率：Java API 封装更好，调试更方便。
生态完整 ：和 MediaExtractor、MediaMuxer、MediaPlayer 等配合自然。

✅ 选择 AMediaCodec 的理由

性能敏感：避免 JNI 开销，减少 Java ↔ Native 的切换。
Native 主导项目：播放器内核、游戏引擎、跨平台框架主要用 C++。
库集成：需要和 FFmpeg、OpenGL、Vulkan 等 C/C++ 库紧密结合。
嵌入式/跨平台：在 Android 只是其中一个平台，统一用 C++ 更方便。

👉 一句话总结：

MediaCodec → 给 Java/Kotlin App 开发者，方便和 UI/Framework 配合。
AMediaCodec → 给 Native/C++ 开发者，方便和底层库/引擎配合。
功能几乎一样，选择取决于 项目语言栈 和 性能需求。

四、层级关系图（文字版）

复制代码

App层: VideoView / MediaPlayer
   ↓
Framework层: MediaCodec (Java)
   ↓
NDK层: AMediaCodec (C++)
   ↓
Stagefright 框架
   ↓
OMX 插件 / HAL
   ↓
硬件编解码器 (GPU/ISP/VPU)

FFmpeg/ExoPlayer/VLC/IJKPlayer：独立于 Android 框架，可作为替代或补充。

五、使用场景对比

接口/框架	封装程度	控制粒度	性能	典型场景
VideoView	高	低	一般	简单视频播放
MediaPlayer	中	中	一般	普通播放
MediaCodec	中	高	中	视频编辑、逐帧处理
AMediaCodec	中	高	高	播放器内核、游戏引擎
Stagefright	内部实现	高	高	系统框架
OMX	底层	底层	高	芯片厂商实现硬件编解码
FFmpeg	中	高	软件为主	跨平台播放器、转码工具
ExoPlayer	高	中	中	流媒体播放
VLC/IJKPlayer	中	高	中	第三方播放器