5、MediaPlayerService 架构：服务注册、客户端与服务端交互、播放状态机模型

各位同学，今天我们来聊聊 MediaPlayerService 的架构。说实话，这部分内容在 Android 多媒体框架里属于「承上启下」的关键环节。你想想看，上层应用调用一个 start()，底层硬件就开始解码播放，中间这一大坨逻辑到底是怎么串起来的？

我个人习惯把 MediaPlayerService 看作一个「中间人」。它不直接干活，但它知道谁在干活、怎么调度、状态对不对。今天我们就从三个角度来拆解它：服务怎么注册上去的、客户端怎么跟它通信、以及那个经典的播放状态机是怎么转的。

5.1 服务注册：MediaPlayerService 是如何被系统发现的？

先说服务注册。MediaPlayerService 本质上是一个 Binder 服务。它跑在 mediaserver 进程里。这个进程启动的时候，会调用 MediaPlayerService::instantiate()，把自己注册到 ServiceManager 里。

代码大概长这样：

// frameworks/av/media/mediaserver/main_mediaserver.cpp
int main(int argc, char** argv) {
    // ... 初始化过程
    MediaPlayerService::instantiate();
    // ... 其他服务注册
    ProcessState::self()->startThreadPool();
    IPCThreadState::self()->joinThreadPool();
}

嗯，这里要注意：instantiate() 内部会调用 defaultServiceManager()->addService()。注册的名字是 "media.player"。客户端通过这个名字来查找服务。

我在项目中遇到过一个问题：某个定制 ROM 把 mediaserver 进程搞崩溃了，结果所有 App 都无法播放视频。原因就是服务没了，客户端拿不到 Binder 代理。所以，服务注册的稳定性直接影响整个多媒体系统的可用性。

5.2 客户端与服务端交互：Binder 通信的完整链路

客户端怎么跟 MediaPlayerService 交互？说白了就是 Binder 调用。但这里有个细节：客户端拿到的其实是一个 Binder 代理对象，并不是真正的服务端对象。

交互流程大致如下：

1. 客户端调用 MediaPlayer.create()，内部会通过 ServiceManager 获取 "media.player" 服务的 Binder 代理。
2. 客户端调用代理对象的 create() 方法，服务端会创建一个 MediaPlayerBase 的子类实例（比如 NuPlayerDriver）。
3. 服务端返回一个 IMediaPlayer 的 Binder 代理给客户端。这个代理指向的是服务端创建的播放器实例。
4. 客户端后续的 setDataSource()、prepare()、start() 等操作，都通过这个代理进行。

代码层面，客户端调用 setDataSource() 时，大概会走这么一串：

// 客户端代码
sp<IMediaPlayer> player = ...; // 从 MediaPlayerService 获取
player->setDataSource(fd, offset, length);

// 服务端实际处理
status_t MediaPlayerBase::setDataSource(int fd, int64_t offset, int64_t length) {
    // 这里会调用具体的 Player 实现，比如 NuPlayer
    return mPlayer->setDataSource(fd, offset, length);
}

5.3 播放状态机模型：状态流转的核心逻辑

播放状态机是 MediaPlayerService 的灵魂。Android 官方文档里定义了一张状态图，我把它简化成 SVG 放在下面。你想想看，一个播放器从创建到销毁，中间要经历多少状态变化？

这张图我建议你多看几遍。每个状态都有它允许的操作集合。比如在 Idle 状态下，你只能调用 setDataSource() 或者 release()。如果你在 Idle 状态下调用 start()，服务端会返回一个错误。

状态机的实现代码在 MediaPlayerBase 和 NuPlayerDriver 里。核心逻辑就是维护一个 mState 变量，每次操作前检查当前状态是否合法。

// 简化的状态检查逻辑
status_t MediaPlayerBase::start() {
    if (mState != PREPARED && mState != PAUSED && mState != PLAYBACK_COMPLETE) {
        ALOGE("start() called in state %d", mState);
        return INVALID_OPERATION;
    }
    // 执行真正的 start 逻辑
    mState = STARTED;
    return OK;
}

5.4 状态机中的几个关键细节

有几个细节我想特别提一下：

• Error 状态：任何状态下发生错误，都会进入 Error 状态。进入 Error 后，唯一能做的就是 reset() 或者 release()。我记得有一次线上问题，App 在 Error 状态下调了 start()，结果直接 crash 了。
• prepareAsync() 与 prepare() 的区别：prepareAsync() 是异步的，不会阻塞调用线程。服务端会在准备完成后通过回调通知客户端。我个人建议在 UI 线程上使用 prepareAsync()，避免 ANR。
• seekTo() 的影响：seekTo() 可以在 Started、Paused、PlaybackCompleted 状态下调用。但 seek 过程中，状态不会改变。seek 完成后会触发 onSeekComplete() 回调。

5.5 总结一下

MediaPlayerService 的架构其实不复杂，但细节很多。服务注册保证了客户端能找到服务端；Binder 通信保证了跨进程调用的效率；状态机模型保证了播放行为的可预测性。

你想想看，如果没有状态机，客户端乱调用 API，服务端根本不知道该怎么处理。状态机就像交通规则，告诉每个操作什么时候该做什么、不该做什么。

嗯，这部分内容就到这里。下一节我们会深入 NuPlayer 的实现，看看真正的解码播放是怎么工作的。

---