1. MediaServer 概述：Android多媒体架构、MediaServer进程角色、核心服务简介
各位同学，咱们今天正式进入《Android Media Server 开发实战》的第一章。
说实话，我当年刚接触 Android 多媒体时，第一反应是——这玩意儿也太复杂了吧？一堆服务、一堆进程、一堆接口，完全不知道从哪下手。后来踩了不少坑，才慢慢理清了头绪。
这一章，我就带你从全局视角，把 MediaServer 的底牌翻一遍。你不需要记住所有细节，但一定要理解它的“骨架”。
1.1 Android 多媒体架构：三层结构
Android 的多媒体系统，说白了就是三层：
- 应用层：你写的 App，调用 MediaPlayer、Camera、AudioRecord 等 API。
- 框架层：Java 层的 MediaPlayer、Camera 等类，通过 Binder 与 Native 层通信。
- Native 层：核心服务跑在 MediaServer 进程里，直接操作硬件。
我习惯把这三层比作“前台、中台、后台”。应用层是前台，用户直接交互；框架层是中台，负责调度；Native 层是后台，干脏活累活。
核心要点：MediaServer 进程就是那个“后台”，它承载了所有多媒体相关的核心服务。
你想想看，为什么 Android 要把这些服务单独放在一个进程里？而不是直接放在 SystemServer 里？
嗯，这里有个设计考量：多媒体服务对实时性要求高，而且容易出问题（比如解码器崩溃）。如果放在 SystemServer 里，一旦崩溃，整个系统就挂了。单独一个进程，挂了还能重启，不影响系统核心功能。
1.2 MediaServer 进程：多媒体的“大管家”
MediaServer 进程，在 Android 里是一个 Native 进程，路径在 /system/bin/mediaserver。
它启动时，会依次创建几个核心服务：
- MediaPlayerService：负责音视频播放、录制。
- CameraService：负责摄像头相关操作。
- AudioFlinger：负责音频混音、输出。
- AudioPolicyService：负责音频策略管理（比如插耳机时自动切换）。
- MediaCodecService：负责硬件编解码（Android 8.0 后独立出来）。
我记得有一次，客户反馈说播放视频时声音卡顿。我排查了半天，最后发现是 AudioFlinger 的线程优先级被其他进程抢占了。嗯，这种问题在多媒体开发中很常见，后面我们会专门讲怎么调优。
避坑指南：我曾经在调试 CameraService 时，发现预览画面一直黑屏。后来发现是 CameraService 启动时，硬件还没初始化完成。解决方案是在启动脚本里加了个延时。这种“时序问题”在多媒体开发中特别容易遇到。
1.3 核心服务简介
1.3.1 MediaPlayerService
MediaPlayerService 是播放和录制的核心。它内部维护了一个 MediaPlayerBase 的实例，负责与底层解码器交互。
它的工作流程大致是：
- 应用层通过 Binder 调用
create()创建播放器。 - MediaPlayerService 根据 URI 或文件描述符，创建对应的
MediaPlayerBase。 - 底层解码器（如 OMX、Stagefright）开始工作。
说白了，MediaPlayerService 就是一个“调度中心”，它自己不干活，而是把任务分发给底层的解码器。
1.3.2 CameraService
CameraService 负责管理摄像头硬件。它支持多个客户端同时访问（比如一个 App 预览，另一个 App 拍照），但同一时刻只能有一个客户端拥有“操作权”。
我遇到过一个问题：两个 App 同时打开摄像头，结果第二个 App 直接崩溃。后来发现是 CameraService 的“优先级策略”没处理好。解决方案是让第二个 App 等待，直到第一个 App 释放资源。
注意：CameraService 在 Android 8.0 之后引入了 Treble 架构，HAL 层变成了可插拔的。这意味着不同厂商的摄像头 HAL 实现可能完全不同，兼容性问题会比较多。
1.3.3 AudioFlinger
AudioFlinger 是音频系统的“心脏”。它负责：
- 混音：把多个音频流混合成一个输出。
- 路由：把音频输出到扬声器、耳机、蓝牙等设备。
- 音量控制：调节每个音频流的音量。
AudioFlinger 内部维护了一个 MixerThread，专门负责混音。我刚开始做音频开发时，一直不理解为什么播放音乐时，通知音会“打断”音乐。后来看了 AudioFlinger 的源码才明白——它用的是“优先级抢占”策略，通知音的优先级更高，所以会暂时降低音乐的音量。
嗯，这里要注意：AudioFlinger 的混音算法是纯 C++ 实现的，性能很高。但如果你在低端设备上同时播放多个音频流，可能会出现“爆音”或“卡顿”。这时候就需要调整 AudioPolicyService 的策略了。
1.4 知识体系结构图
下面这张图，是我自己整理的 MediaServer 核心服务关系图。你看一眼，就能明白它们之间的协作关系。
从这张图你可以看到，MediaServer 进程是“大脑”，三个核心服务是“手脚”，HAL 层是“翻译官”，硬件是“执行者”。
1.5 总结
这一章，我们主要讲了三个东西：
- Android 多媒体架构的三层结构：应用层、框架层、Native 层。
- MediaServer 进程的角色：多媒体的“大管家”，负责管理所有多媒体服务。
- 三个核心服务：MediaPlayerService（播放录制）、CameraService（摄像头）、AudioFlinger（音频混音）。
我个人觉得，理解 MediaServer 的关键在于“分层”和“解耦”。每一层只做自己的事，通过 Binder 通信。这种设计让系统更稳定，也更容易扩展。
嗯，这一章就到这里。下一章，我们会深入 MediaPlayerService 的源码，看看它到底是怎么工作的。
课后思考：如果让你设计一个多媒体系统，你会把服务放在同一个进程里，还是拆成多个进程？为什么？