2. Android MultiMedia框架完全解析 - MediaPlayer的C/S架构与Binder机制实现
在Android中大量使用到了C/S架构来实现应用层和底层服务交互，而Binder机制无处不在。
同样MediaPlayer也使用了这种机制，MediaPlayer在运行的时候，同样可以分为Client/Server两个部分，他们分别在不同的进程中运行，不同进程间的通信使用Binder机制，我们这里就以setDataSource()为例，讲解一下他们是如何建立关系的，架构图如下：
1）如果从功能角度看，最上层是java层MediaPlayer的API， 然后通过JNI层到C++层之间的IPC通信，最下边就是palyer的具体实现了（StageFrightPlayer，NuPlayer等等）
2）C++层是比较重要的环节，这一块也是C/S架构的核心，主要围绕C++层MediaPlayer通过BpMediaPlayerService这个proxy对象，经过IPC与远程服务端MediaPlayerService（BnMediaPlayerService）通信，完成C/S架构。（Bpxxx是一个代理外包，所有真正的工作是再Bnxxx里面做的，这里p指proxy，n指native）
3）当Server端接受到Client端的请求，MediaPlayerService会为每一个Client进程创建一个会话，这里就是new一个MediaPlayer::Client对象与其交互，然后这个对象再根据Client端请求的资源类型去判断创建了什么类型的Player，就是最下面那些。（最下面这些Player很多都是芯片厂商自己做的，每家做的都不一样）
继续分析setDataSource函数（setDataSource - 2）
在上一节中，我们分析了从java层到JNI层的一些步骤，这里，我们继续分析。
static void
android_media_MediaPlayer_setDataSourceFD(JNIEnv *env, jobject thiz, jobject fileDescriptor, jlong offset, jlong length)
{
sp mp = getMediaPlayer(env, thiz);
if (mp == NULL ) {
jniThrowException(env, "java/lang/IllegalStateException", NULL);
return;
}
if (fileDescriptor == NULL) {
jniThrowException(env, "java/lang/IllegalArgumentException", NULL);
return;
}
int fd = jniGetFDFromFileDescriptor(env, fileDescriptor);
ALOGV("setDataSourceFD: fd %d", fd);
process_media_player_call( env, thiz, mp->setDataSource(fd, offset, length), "java/io/IOException", "setDataSourceFD failed." );
} 上一节中我们分析到了这里，它位于frameworks/base/media/jni/android_media_MediaPlayer.cpp文件中，下面就跳转到frameworks/av/media/libmedia/mediaplayer.cpp中：
status_t MediaPlayer::setDataSource(int fd, int64_t offset, int64_t length)
{
ALOGV("setDataSource(%d, %" PRId64 ", %" PRId64 ")", fd, offset, length);
status_t err = UNKNOWN_ERROR;
const sp service(getMediaPlayerService());
//获取BpMediaPlayerService这个MediaPlayerService的proxy代理
if (service != 0) {
sp player(service->create(this, mAudioSessionId));
if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||
(NO_ERROR != player->setDataSource(fd, offset, length))) {
player.clear();
}
err = attachNewPlayer(player);
}
return err;
} 在这个过程中，mediaplayer.cpp中的setDataSource会从ServiceManager中获取MediaPlayerService服务，然后通过服务来创建Player，这个Player就是真正干活的Player。
下面仔细分析一些这个步骤：
1）通过Binder获取远程服务
通过getMediaPlayerService得到的service就是BpMediaPlayerService，这是和MediaPlayerService进程中对应的BnMediaPlayerService负责Binder通信，BpMediaPlayerService中的create只是通过binder机制将CREATE命令发送出去，真正的工作是在Bn端做的，这个发送命令的代码位于frameworks/av/media/libmedia/IMediaPlayerService.cpp中：
virtual sp create(
const sp& client, audio_session_t audioSessionId) {
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeStrongBinder(IInterface::asBinder(client));
data.writeInt32(audioSessionId);
remote()->transact(CREATE, data, &reply);
return interface_cast(reply.readStrongBinder());
} 在这个函数中，Parcel是Binder进行通信的数据载体，Bp端向Bn端发送的数据结构是data，Bn端向Bp端回复的数据是reply。然后通过remote()->transact()发送CREATE命令到Bn端。
在服务端的Bn端，BnMediaPlayerService通过onTransact()接受这个命令，并把结果通过replay返回。代码同样位于frameworks/av/media/libmedia/IMediaPlayerService.cpp中：
status_t BnMediaPlayerService::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch (code) {
case CREATE: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
sp client =
interface_cast(data.readStrongBinder());
audio_session_t audioSessionId = (audio_session_t) data.readInt32();
sp player = create(client, audioSessionId);
//BnMediaPlayerService的子类是MediaPlayerService，所以这里会调用MediaPlayerService的create方法
reply->writeStrongBinder(IInterface::asBinder(player));
return NO_ERROR;
} break;
case CREATE_MEDIA_RECORDER:
......
}
} BnMediaPlayerService的子类是MediaPlayerService，即MediaPlayerService继承自BnMediaPlayerService。这里首先生成了一个IMediaPlayerClient，这个类用于MediaPlayerService与MediaPlayer通信。然后调用MediaPlayerService类的create函数，这里就把客户端的指令最终传送到服务端了，等服务端完成这个指令后，通过Binder通信，填写reply这个Parcel，把最终的结果回馈给客户端，这个流程就算执行完毕了。
这里创建了2个匿名Binder Server：IMediaPlayerClient和IMediaPlayer。
2）服务端创建会话
最终调用了MediaPlayerService的create方法，文件位于frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp中：
sp MediaPlayerService::create(const sp& client,
audio_session_t audioSessionId)
{
pid_t pid = IPCThreadState::self()->getCallingPid();
int32_t connId = android_atomic_inc(&mNextConnId);
sp c = new Client(
this, pid, connId, client, audioSessionId,
IPCThreadState::self()->getCallingUid());
ALOGV("Create new client(%d) from pid %d, uid %d, ", connId, pid,
IPCThreadState::self()->getCallingUid());
wp w = c;
{
Mutex::Autolock lock(mLock);
mClients.add(w);
}
return c;
} 在这个函数中，创建了一个MediaPlayerService::Client实例，也就是说，MediaPlayerService会为每个client应用程序创建一个相应的MediaPlayerServece::Client，来提供服务。也就是说，mediaplayer.cpp中执行的setDataSource函数，在MediaPlayerService.cpp中，实际上只是创建了一个client，并将两者对应起来，如果再次执行setDataSource函数，会创建第二个client。同时看这个函数的返回值类型，为sp
3）回执后setDataSource的流程
继续回到frameworks/av/media/libmedia/mediaplayer.cpp中的MediaPlayer::setDataSource函数中，上面执行完了create函数，MediaPlayerService创建了一个client对应，同时将这个client返回到MediaPlayer中，那就继续执行下面的：
player->setDataSource(fd, offset, length)
此时，这个player就对应刚创建的client，以后每次执行有关player的操作，都会对应执行到MediaPlayerService::Client中的操作，所以，这里就执行到了MediaPlayerService::Client::setDataSource函数中：
status_t MediaPlayerService::Client::setDataSource(int fd, int64_t offset, int64_t length)
{
ALOGV("setDataSource fd=%d (%s), offset=%lld, length=%lld",
fd, nameForFd(fd).c_str(), (long long) offset, (long long) length);
............
player_type playerType = MediaPlayerFactory::getPlayerType(this,
fd,
offset,
length);
sp p = setDataSource_pre(playerType);
if (p == NULL) {
return NO_INIT;
}
// now set data source
setDataSource_post(p, p->setDataSource(fd, offset, length));
return mStatus;
}
这里面有三个重点，我都标红了。这三个重点放在后面再讲，这里先分析Media这块的Binder机制：
class BpMediaPlayerService: public BpInterface
class BnMediaPlayerService: public BnInterface
class IMediaPlayerService: public IInterface
IMediaPlayerService类中定义了MediaPlayerService中能够提供的服务函数，这个IMediaPlayerService类定义在IMediaPlayerService.h中，并且，需要通过DECLARE_META_INTERFACE宏来声明asInterface这个函数，这个函数与interface_cast相关。interface_cast函数就能够通过asInterface这个函数，创建一个BpMediaPlayerService。当然，具体实现是在asInterface函数中实现的，而asInterface函数的实现是在IMPLEMENT_META_INTERFACE宏中。
在IMediaPlayerService.h中，包含对IMediaPlayerService类的声明和BnMediaPlayerService的声明。
IMediaPlayerService类中包含BpMediaPlayerService需要实现的虚函数，相当于IMediaPlayerService.cpp 的头文件。BnMediaPlayerService中只声明一个onTransact函数。
在IMediaPlayerService.cpp中，包含了BpMediaPlayerService类的实现和BnMediaPlayerService类中onTransact函数的实现。
下面来看一下简单的代码实现（IMediaPlayerService.h）：
class IMediaPlayerService: public IInterface
{
public:
DECLARE_META_INTERFACE(MediaPlayerService);
virtual sp createMediaRecorder(const String16 &opPackageName) = 0;
virtual sp createMetadataRetriever() = 0;
virtual sp create(const sp& client, int
audioSessionId = 0)= 0;
virtual sp getOMX() = 0;
virtual sp makeCrypto() = 0;
virtual sp makeDrm() = 0;
virtual sp makeHDCP(bool createEncryptionModule) = 0;
virtual sp getCodecList() const = 0;
virtual sp listenForRemoteDisplay(const String16 &opPackageName,
const sp& client, const String8& iface) = 0;
enum BatteryDataBits {
xxxxxx
};
virtual void addBatteryData(uint32_t params) = 0;
virtual status_t pullBatteryData(Parcel* reply) = 0;
};
// ----------------------------------------------------------------------------
class BnMediaPlayerService: public BnInterface
{
public:
virtual status_t onTransact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
};
在IMediaPlayerService.cpp中，直接声明BpMediaPlayerService，它继承自BpInterface
同时，还包含BnMediaPlayerService::onTransact函数的具体实现。
以sp
virtual sp create(
const sp& client, int audioSessionId) {
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeStrongBinder(IInterface::asBinder(client));
data.writeInt32(audioSessionId);
remote()->transact(CREATE, data, &reply);
return interface_cast(reply.readStrongBinder());
} 在Binder中，我们知道，Bp端只是一个Proxy，真正的实现是在Bn端，所以，在看这个文件中，就能够看到，Bp端只是填写data这个Parcel，然后通过remote()->transact()来把真正需要做的内容(CREATE命令)传递给Bn端。而Bn端其实只有一个onTransact函数，在这个函数中根据不同的case来分别处理：
status_t BnMediaPlayerService::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch (code) {
case CREATE: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
sp client =
interface_cast(data.readStrongBinder());
int audioSessionId = data.readInt32();
sp player = create(client, audioSessionId);
reply->writeStrongBinder(IInterface::asBinder(player));
return NO_ERROR;
} break;
mediaplayer.cpp这个是客户端，客户端提出的请求，最终由服务端来完成，服务端就是MediaPlayerService.cpp，由上面的代码，调用到create函数，这个函数在MediaPlayerService.cpp中实现：
sp MediaPlayerService::create(const sp& client,
int audioSessionId)
{
pid_t pid = IPCThreadState::self()->getCallingPid();
int32_t connId = android_atomic_inc(&mNextConnId);
sp c = new Client(
this, pid, connId, client, audioSessionId,
IPCThreadState::self()->getCallingUid());
ALOGV("Create new client(%d) from pid %d, uid %d, ", connId, pid,
IPCThreadState::self()->getCallingUid());
wp w = c;
{
Mutex::Autolock lock(mLock);
mClients.add(w);
}
return c;
} 在create函数中，其实是创建了一个MediaPlayerService::Client的实例，并且这个实例通过一个线程来维护。也就是说，MediaPlayerService会为每个客户端创建一个相应的MediaPlayerService::Client实例，用来提供服务。
这里又使用了一个小技巧，注意上面我标红的代码，首先是Bp端：data.writeStrongBinder(IInterface::asBinder(client));
这段代码又什么用呢？
它实际上是生成了一个匿名Binder Server，生成的Binder名字叫做IMediaPlayerClient，通过IInterface::asBinder(client)，这个Binder的BpMediaPlayerClient获取到BnMediaPlayerClient的handle，这样就能够将Bp端和Bn端联系起来。具体的代码在这里就不仔细分析了。总之，这个Binder没有注册到ServiceManager中，只能在这个进程内部使用。
同时这个IMediaPlayerClient并没有创建完整，后续的代码继续看上面标红的代码，这次在Bn端：
sp
interface_cast
这次是真正的创建好IMediaPlayerClient了，然后就是下面的代码，来创建player，在创建player的create函数中，需要把这个Client传进去，同时，又再次用了上面介绍的匿名Binder Server的方法，再次创建了一个匿名Binder server，这次创建的是IMediaPlayer。
sp
reply->writeStrongBinder(IInterface::asBinder(player));
这里可能要晕了，怎么弄了这么多Binder Server？
所以这里把这些Binder的关系屡屡。
首先是一个大Boss——IMediaPlayerService：
class IMediaPlayerService: public IInterface —— IMediaPlayerService.h
class BnMediaPlayerService: public BnInterface
class BpMediaPlayerService: public BpInterface
这个MediaPlayerService需要处理的事情很多，对于IMediaPlayer的事情它要管，对于IMediaMetadataRetriever的事情它也要管，同时还有其他的如：IMediaRecorder，IOMX，IMediaCodecList等等。所以在内部，它会把一些任务分流，比如IMediaPlayer，它执行完create函数后，它为每个客户创建了一个MediaPlayerService::Client实例，并启用一个线程来负责它。
在log信息中可以看到：
01-01 00:06:02.373 230 535 V MediaPlayerService: Client(1) constructor
01-01 00:06:02.373 230 535 V MediaPlayerService: Create new client(1) from pid 1841, uid 10036,
每个客户端都对应MediaPlayerService中的一个Client，并且都有自己的一个connId。
除此之外，还启动了一个IMediaPlayerClient：
class IMediaPlayerClient: public IInterface —— IMediaPlayerClient.h
class BnMediaPlayerClient: public BnInterface
class BpMediaPlayerClient: public BpInterface
这个IMediaPlayerClient负责一个客户端的回调函数，比如对于一个MediaPlayer，MediaPlayerService通过IMediaPlayerClient来通知对应的MediaPlayer。
具体这个可以分析NuPlayerDriver: notifyListener_l(0xb5f17080), (5, 1024, 768)的执行流程。
这个IMediaPlayerClient只负责notify这个过程，它相当于包裹在MediaPlayer外面的一层wrapper。
那么最里面的是什么?肯定是IMediaPlayer啊~
class IMediaPlayer: public IInterface —— IMediaPlayer.h
class BnMediaPlayer: public BnInterface
class BpMediaPlayer: public BpInterface
这个就于playback息息相关了，对于每个MediaPlayer常用的函数，start，stop，setDataSource，pause，seekTo等等，都是通过它来传递给MediaPlayerService::Client的。
比如对于start的流程，首先mediaplayer.cpp中发出start的函数 ---> 到达IMediaPlayer的Bp端 ---> 传到IMediaPlayer的Bn端 ---> 到达MediaPlayerService::Client端的MediaPlayerService::Client::start函数 ---> NuPlayerDriver::start ---> NuPlayer: kWhatStart
就这样执行下去了。
后面再分析一个seekto，invoke，notify的流程。
理论上是除了setDataSource外，其他函数的流程都是相同的，notify可能例外一点。
至此，终于把Binder这一块的知识大致缕清了。
