从mediaserver入手快速理解binder机制（最简单理解binder）
Posted 请给我倒杯茶
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了从mediaserver入手快速理解binder机制（最简单理解binder）相关的知识，希望对你有一定的参考价值。
本文转载自;https://blog.csdn.net/u010164190/article/details/53015194
Android的binder机制提供一种进程间通信的方法，使一个进程可以以类似远程过程调用的形式调用另一个进程所提供的功能。binder机制在Java环境和C/C++环境都有提供。
android的代码中，与C/C++的binder包括一些类型和接口的定义和实现，相关的代码在下面这几个文件中：
frameworks\base\include\utils\IInterface.h
frameworks\base\include\utils\Binder.h
frameworks\base\include\utils\BpBinder.h
frameworks\base\include\utils\IBinder
frameworks\base\include\utils\Parcel.h
frameworks\base\include\utils\IPCThreadState.h
frameworks\base\include\utils\ProcessState.h
frameworks\base\libs\utils\Binder.cpp
frameworks\base\libs\utils\BpBinder.cpp
frameworks\base\libs\utils\IInterface.cpp
frameworks\base\libs\utils\IPCThreadState.cpp
frameworks\base\libs\utils\Parcel.cpp
frameworks\base\libs\utils\ProcessState.cpp
为了了解这些类、接口之间的关系以及binder的实现机制，最好是结合一个例子来进行研究。我选择的例子是android自带的媒体播放器的实现。其媒体播放器的相关代码在下面这些目录中：
frameworks\base\include\media
frameworks\base\media
使用startUML的反向工程功能分析上面这些代码，并进行了一定的整理之后，得到下面这幅类图（点击可查看原尺寸图片）。
android的媒体播放功能分成两部分，一部分是媒体播放应用，一部分是媒体播放服务（MediaServer，在系统启动时由init所启动，具可参考init.rc文件）。这两部分分别跑在不同的进程中。媒体播放应用包括Java程序和部分C++代码，媒体播放服务是C++代码，并且需要调用外部模块opencore来实现真正的媒体播放。媒体播放应用和媒体播放服务之间需要通过binder机制来进行相互调用，这些调用包括：
（1）媒体播放应用向媒体播放服务发控制指令
（2）媒体播放服务向媒体播放应用发事件通知（notify）
媒体播放服务对外提供多个接口，在上面得图中包括其中的2个接口：IMediaService和IMediaPlayer，IMediaplayer用于创建和管理播放实例，而IMediaplayer接口则是播放接口，用于实现指定媒体文件的播放以及播放过程的控制。
上面的图中还有媒体播放应用向媒体播放服务提供的1个接口：IMediaPlayerClient，用于接收notify。
这些接口因为需要跨进程调用，因此需要用到binder机制。每个接口包括两部分实现，一部分是接口功能的真正实现（BnInterface），这部分运行在接口提供进程中；另一部分是接口的proxy（BpInterface），这部分运行在调用接口的进程中。binder的作用就是让这两部分之间建立联系。下图是整个播放器的一个概要说明。
媒体播放器比较复杂一些，总共实现了3个接口，不过要了解binder的机制，只需要研究其中一个接口就足够了。在这里选择IMediaPlayerService接口来看一下。
IMediaPlayerService接口包括六个功能函数：create(url)、create(fd)、decode(url)、decode(fd）、createMediaRecord()、createMetadataRetriever()。在这里不介绍这些函数是做什么的，我们只关注如何通过binder还提供这些函数接口。
（二） 接口定义
（1） 定义接口类
首先定义IMediaPlayerService类，这是一个接口类（C++的术语应该叫纯虚类）。该接口类定义在文件frameworks\base\include\media\IMediaPlayerService.h。代码如下：
class IMediaPlayerService: public IInterface
{
public:
DECLARE_META_INTERFACE(MediaPlayerService);
virtual sp<IMediaRecorder> createMediaRecorder(pid_t pid) = 0;
virtual sp<IMediaMetadataRetriever> createMetadataRetriever(pid_t pid) = 0;
virtual sp<IMediaPlayer> create(pid_t pid, const sp<IMediaPlayerClient>& client, const char* url) = 0;
virtual sp<IMediaPlayer> create(pid_t pid, const sp<IMediaPlayerClient>& client, int fd, int64_t offset, int64_t length) = 0;
virtual sp<IMemory> decode(const char* url, uint32_t *pSampleRate, int* pNumChannels, int* pFormat) = 0;
virtual sp<IMemory> decode(int fd, int64_t offset, int64_t length, uint32_t *pSampleRate, int* pNumChannels, int* pFormat) = 0;
}; |
|
可以看到，在这个接口类中定义了IMediaPlayerService需要提供的6个函数接口，因为是接口类，所以定义为纯虚函数。需要注意这个接口类的名称有严格要求，必须是以大写字母I开始。
重点关注在这些函数前面的一个宏定义： DECLARE_META_INTERFACE(MediaPlayerService)。这个宏定义必须要有，其中封装了实现binder所需要的一些类成员变量和成员函数通过这些成员函数可以为一个binder实现创建proxy。这个宏定义在问价frameworks\base\include\utils\IInterface.h里，在后面还会讲到。这个宏定义的参数必须是接口类的名称去除字母I后剩下的部分。
另外说明一下，可以看到接口类中所定义的函数的返回值都是sp<xxxx>的形式，看起来有点怪异。sp是android中定义的一个模板类，用于实现智能指针功能。sp<IMediaPlayer>就是IMediaPlayer的智能指针，可以简单地把它看成是标准C++中的指针定义即 IMediaPlayer* 即可。
（2） 定义和实现binder类
binder类包括两个，一个是接口实现类，一个接口代理类。接口代理类继承自BpInterface，接口实现类继承自BnInterface。这两个基类都是模板类，封装了binder的进程间通信机制，这样使用者无需关注底层通信实现细节。
对于IMediaPlayerService接口，其binder接口实现类为BnMediaPlayerService，接口代理类为BpMediaPlayerService。需注意这两个类的名称有严格要求，必须以Bn和Bp开头，并且后面的部分必须是前面所定义的接口类的名称去除字母‘I’。比如前面所定义的接口类为IMediaPlayerService，去除字母I后是MediaPlayerService，所以两个binder类的名称分别是BnMediaPlayerService和BpMediaPlayerService。为什么有这样的要求？原因就在前面提到的宏定义DECLARE_META_INTERFACE()和另一个宏定义IMPLEMENT_META_INTERFACE()里面。有兴趣的话可以去看一下，这两个宏定义都在文件frameworks\base\include\utils\IInterface.h里。
BpMediaPlayerService是一个最终实现类。定义并且实现在在文件frameworks\base\media\libmidia\IMediaPlayerService.cpp中。在看BpMediaPlayerService的代码之前，先看一下在IMediaPlayerService.cpp文件的开始部分的一个枚举定义：
enum {
CREATE_URL = IBinder::FIRST_CALL_TRANSACTION,
CREATE_FD,
DECODE_URL,
DECODE_FD,
CREATE_MEDIA_RECORDER,
CREATE_METADATA_RETRIEVER,
};
这些6个枚举定义对应于IMediaPlayerService接口所提供的6个功能函数，可以称为这些功能函数的功能代码，用于在进程之间进行RPC是标识需要调用哪个函数。如果不想定义这些枚举值，在后面需要用到这些值的地方直接写上1，2，3，4，5，6也是可以的，不过……一个合适的程序员会这么干吗？
下面看一下BpMediaPlayerService的代码。
（3） BpMediaPlayerService代码分析
class BpMediaPlayerService: public BpInterface<IMediaPlayerService>
{
public:
BpMediaPlayerService(const sp<IBinder>& impl)
: BpInterface<IMediaPlayerService>(impl)
{
}
virtual sp<IMediaMetadataRetriever> createMetadataRetriever(pid_t pid)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeInt32(pid);
remote()->transact(CREATE_METADATA_RETRIEVER, data, &reply);
return interface_cast<IMediaMetadataRetriever>(reply.readStrongBinder());
}
virtual sp<IMediaPlayer> create(pid_t pid, const sp<IMediaPlayerClient>& client, const char* url)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeInt32(pid);
data.writeStrongBinder(client->asBinder());
data.writeCString(url);
remote()->transact(CREATE_URL, data, &reply);
return interface_cast<IMediaPlayer>(reply.readStrongBinder());
}
virtual sp<IMediaRecorder> createMediaRecorder(pid_t pid)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeInt32(pid);
remote()->transact(CREATE_MEDIA_RECORDER, data, &reply);
return interface_cast<IMediaRecorder>(reply.readStrongBinder());
}
virtual sp<IMediaPlayer> create(pid_t pid, const sp<IMediaPlayerClient>& client, int fd, int64_t offset, int64_t length)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeInt32(pid);
data.writeStrongBinder(client->asBinder());
data.writeFileDescriptor(fd);
data.writeInt64(offset);
data.writeInt64(length);
remote()->transact(CREATE_FD, data, &reply);
return interface_cast<IMediaPlayer>(reply.readStrongBinder());
}
virtual sp<IMemory> decode(const char* url, uint32_t *pSampleRate, int* pNumChannels, int* pFormat)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeCString(url);
remote()->transact(DECODE_URL, data, &reply);
*pSampleRate = uint32_t(reply.readInt32());
*pNumChannels = reply.readInt32();
*pFormat = reply.readInt32();
return interface_cast<IMemory>(reply.readStrongBinder());
}
virtual sp<IMemory> decode(int fd, int64_t offset, int64_t length, uint32_t *pSampleRate, int* pNumChannels, int* pFormat)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeFileDescriptor(fd);
data.writeInt64(offset);
data.writeInt64(length);
remote()->transact(DECODE_FD, data, &reply);
*pSampleRate = uint32_t(reply.readInt32());
*pNumChannels = reply.readInt32();
*pFormat = reply.readInt32();
return interface_cast<IMemory>(reply.readStrongBinder());
}
};
首先可以看到，这个类继承自模板类BpInterface，指定类型为接口类IMediaPlayerService。BpInterface模板类定义在文件IInterface.h。看一下BpInterface的定义就可以发现，BpMediaPlayerService这样定义了以后，事实上间接继承了IMediaPlayerService，从而可以提供IMediaPlayerService接口所定义的接口函数。BpMediaPlayerService需要实现这些接口函数。在一个简单的构造函数之后，就是这些接口函数的实现。可以看到，所有的接口函数的实现方法都是一致的，都是通过binder所提供的机制将参数仍给binder的实现类，并获取返回值。这也就是这个类之所以成为代理类的原因。下面具体看一下一个接口函数。这里选的是函数create(url）。
virtual sp<IMediaPlayer> create(pid_t pid, const sp<IMediaPlayerClient>& client, const char* url)
{
Parcel data, reply;
data.writeInterfaceToken(IMediaPlayerService::getInterfaceDescriptor());
data.writeInt32(pid);
data.writeStrongBinder(client->asBinder());
data.writeCString(url);
remote()->transact(CREATE_URL, data, &reply);
return interface_cast<IMediaPlayer>(reply.readStrongBinder());
}
这个接口函数的参数指定了一个URL，函数将为这个URL创建一个播放器实例用于播放该URL。
函数首先定义了两个局部变量data和reply，变量的类型都是Parcel。Parcel是一个专为binder通信的数据传送而定义的类，该类提供了对多种类型的数据的封装功能，同时提供多个数据读取和写入函数，用于多种类型的数据的写入和读取，支持的数据类型既包括简单数据类型，也包括对象。这里定义的变量data是用于封装create()函数调用所需要的输入参数，而reply则是用于封装调用的返回数据（包括输出参数的值和函数返回值）。
函数首先向data中写入各种数据。第一个写入的是接口的一个描述字符串，binder的实现类中会用这个字符串来对接口做验证，防止调用错误。这个字符串也可以不写，如果不写，在binder实现类中相应的也就不要做验证了。跟在描述字符串后面写入的是该接口函数所需要的各种的输入参数。需要说明的是，Pacel提供一种先入先出的数据存储方式，即数据的写入顺序和读取顺序必须严格一致，否则将会出错。
完成数据写入后，函数调用remote()->transact()用于完成binder通信。transact()函数的第一个参数就是前面提到过的功能代码。transact()的功能是将data中的数据传给binder的实现类，函数调用结束后，reply中将包含返回数据。首先来看看remote()成员函数。前面讲到过BpMediaPlayerService通过继承BpInterface模板类间接继承了IMediaPlayerService接口类，其实BpInterface类是一个有两个父类的多重继承子类，另一个父类是BpRefbase（frameworks\base\include\utils\Binder.h）。remote()就是继承自BpRefBase类的一个成员函数，该函数返回BpRefBase类中定义的一个私有属性mRemote。mRemote是对IBinder接口类的子类BpBinder的一个对象的引用（参考前面的类关系图）。transact()函数在IBinder接口类中定义（frameworks\base\include\utils\Binder.h），并在BpBinder类中实现（frameworks\base\include\utils\BpBinder.h、frameworks\base\libs\utils\BpBinder.cpp）。在transact()函数中将调用IPCThreadState类的transact()函数，并进而通过Lniux内核中的android共享内存驱动来实现进程间通信。不过这些细节这里就不多说了。在这里BpBinder类对象是一个关键，是实现Binder代理的核心之一。BpBinder类可以看成是一个通信handle（类似于网络编程中的socket），用于实现进程间通信。接下来需要研究的是这个BpBinder类对象（即mRemote成员变量的值）是从哪里来的。
回过头来BpMediaPlayerService的构造函数（看前面的代码）。该构造函数的参数是一个IBinder对象的引用。mRemote的值就是在这里传进来的这个对象。那么这个对象又是怎么来的呢？要搞清楚这一点就需要找到创建BpMediaPlayerService类的实例的代码，这个代码就就跟在该类的定义代码的下面。继续看IMediaPlayerService.cpp文件，在BpMediaPlayerService类定义的后面，是下面这样一行代码：
IMPLEMENT_META_INTERFACE(MediaPlayerService, "android.hardware.IMediaPlayerService");
这行代码调用了一个宏定义IMPLEMENT_META_INTERFACE()。这个宏定义与前面提到过的DECLARE_META_INTERFACE()相呼应。看名字就知道，IMPLEMENT_META_INTERFACE()宏是对DECLARE_META_INTERFACE()所定义的成员函数的具体实现。这个宏的第一个参数与DECLARE_META_INTERFACE()的参数需完全一样，第二参数是接口的描述字符串（这个字符串前面也已经讲到过了）。描述字符串不重要，重要的是宏里面定义的一个静态成员函数asInterface()。BpMediaPlayerService的类实例是在IMediaPlayerService的静态成员函数asInterface()中创建的，在IInterface.h中定义了一个内联函数interface_cast()，对这个成员函数进行了封装。通过看代码容易知道，BpMediaPlayerService的构造函数的参数是通过interface_cast()的参数传进来的。
好，下面就该看看这个interface_cast()是在哪里调用的，它的参数到底是什么。找到frameworks\base\media\libmedia\mediaplayer.cpp文件，其中的MediaPlayer::getMediaPlayerService()的实现代码：
const sp<IMediaPlayerService>& MediaPlayer::getMediaPlayerService()
{
Mutex::Autolock _l(sServiceLock);
if (sMediaPlayerService.get() == 0) {
sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder;
do {
binder = sm->getService(String16("media.player"));
if (binder != 0)
break;
LOGW("MediaPlayerService not published, waiting...");
usleep(500000); // 0.5 s
} while(true);
if (sDeathNotifier == NULL) {
sDeathNotifier = new DeathNotifier();
}
binder->linkToDeath(sDeathNotifier);
sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);
}
LOGE_IF(sMediaPlayerService==0, "no MediaPlayerService!?");
return sMediaPlayerService;
}
看一下上面这段代码中的红色字体部分。结合前面的分析，可知BpBinder类的对象实例是从android的服务管理器的getService()函数中获取，进一步追进去，会发现下面这样一段代码：
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}
Android的服务管理器是一个单独的进程，也向外提供接口。这段代码的含义，是通过Android的服务管理器的接口代理，请求调用服务管理器的checkService()接口函数，查找指定的服务（上面就是查找media.player服务），查找成功后返回一个BpBinder类的对象实例，用于供IMediaPlayerService代理使用。这个对象BpBinder是在Parcel::readStrongBinder()函数里面创建的。那么到底是怎么创建出来的呢？在这里没有必要追到ServiceManager的实现代码里去，毕竟我们只是想知道BpBinder的对象是如何创建的，我们可以换一个例子来看。回到前面的BpMediaPlayerService::create()函数的实现，是不是很眼熟。没错，在那个函数里也创建了一个BpBinder类对象，那个对象是是给IMediaPlayer接口代理使用的。虽然接口不同，但是创建原理是一样的。我们继续，下面该到binder的另一个类——实现类的代码了。
（3） BnMediaPlayerService代码分析
BnMediaPlayerService类的定义在文件frameworks\base\include\media\IMediaPlayService.h，实现则与BpMediaPlayerService一样是在文件frameworks\base\media\libmidia\IMediaPlayerService.cpp中。类定义的代码如下：
class BnMediaPlayerService: public BnInterface<IMediaPlayerService>
{
public:
virtual status_t onTransact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
};
这个类继承自BnInterface模板类，约束类型为IMediaPlayerService。看一下BnInterface模板类的定义（IInterface.h）就可以知道，BnMediaPlayerService间接继承了IMediaPlayerService接口类。不过BnInterface类并没有实现IMediaPlayerService所定义的6个接口函数，因此BnInterface还是一个纯虚类。这些接口需要在BnMediaPlayerService的子类中真正实现，这个子类就是MediaPlayerService（frameworks\base\media\libmidiaservice\MediaPlayerService.h，frameworks\base\media\libmidiaservice\MediaPlayerService.cpp）。在BnMediaPlayerService的成员函数onTransact()中，需要调用这6个接口函数。BnMediaPlayerService中主要就是定义并实现了onTransact()函数。当在代理那边调用了transact()函数后，这边的onTransact()函数就会被调用。BnMediaPlayerService的实现代码如下：
#define CHECK_INTERFACE(interface, data, reply) \
do { if (!data.enforceInterface(interface::getInterfaceDescriptor())) { \
LOGW("Call incorrectly routed to " #interface); \
return PERMISSION_DENIED; \
} } while (0)
status_t BnMediaPlayerService::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case CREATE_URL: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
pid_t pid = data.readInt32();
sp<IMediaPlayerClient> client = interface_cast<IMediaPlayerClient>(data.readStrongBinder());
const char* url = data.readCString();
sp<IMediaPlayer> player = create(pid, client, url);
reply->writeStrongBinder(player->asBinder());
return NO_ERROR;
} break;
case CREATE_FD: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
pid_t pid = data.readInt32();
sp<IMediaPlayerClient> client = interface_cast<IMediaPlayerClient>(data.readStrongBinder());
int fd = dup(data.readFileDescriptor());
int64_t offset = data.readInt64();
int64_t length = data.readInt64();
sp<IMediaPlayer> player = create(pid, client, fd, offset, length);
reply->writeStrongBinder(player->asBinder());
return NO_ERROR;
} break;
case DECODE_URL: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
const char* url = data.readCString();
uint32_t sampleRate;
int numChannels;
int format;
sp<IMemory> player = decode(url, &sampleRate, &numChannels, &format);
reply->writeInt32(sampleRate);
reply->writeInt32(numChannels);
reply->writeInt32(format);
reply->writeStrongBinder(player->asBinder());
return NO_ERROR;
} break;
case DECODE_FD: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
int fd = dup(data.readFileDescriptor());
int64_t offset = data.readInt64();
int64_t length = data.readInt64();
uint32_t sampleRate;
int numChannels;
int format;
sp<IMemory> player = decode(fd, offset, length, &sampleRate, &numChannels, &format);
reply->writeInt32(sampleRate);
reply->writeInt32(numChannels);
reply->writeInt32(format);
reply->writeStrongBinder(player->asBinder());
return NO_ERROR;
} break;
case CREATE_MEDIA_RECORDER: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
pid_t pid = data.readInt32();
sp<IMediaRecorder> recorder = createMediaRecorder(pid);
reply->writeStrongBinder(recorder->asBinder());
return NO_ERROR;
} break;
case CREATE_METADATA_RETRIEVER: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
pid_t pid = data.readInt32();
sp<IMediaMetadataRetriever> retriever = createMetadataRetriever(pid);
reply->writeStrongBinder(retriever->asBinder());
return NO_ERROR;
} break;
default:
return BBinder::onTransact(code, data, reply, flags);
}
}
首先是一个宏定义CHECK_INTERFACE()，这个宏定义的作用是检查接口的描述字符串，这个前面也提到过，不需细说。然后就是onTrasact()函数的实现。这个函数的结构也很简单，就是根据参数code的值分别执行不同的功能调用。code的取值就是前面提到过的接口功能代码。函数的参数除了code，还包括Parcel类的两个对象data和reply,分别用于传送输入参数和返回数据，与transact()函数的参数相对应。还有一个参数flag在这里用不上，不讨论。对应我们前面所选择的接口函数的例子create(url)，看看这边对应的实现：
case CREATE_URL: {
CHECK_INTERFACE(IMediaPlayerService, data, reply);
pid_t pid = data.readInt32();
sp<IMediaPlayerClient> client = interface_cast<IMediaPlayerClient>(data.readStrongBinder());
const char* url = data.readCString();
sp<IMediaPlayer> player = create(pid, client, url);
reply->writeStrongBinder(player->asBinder());
return NO_ERROR;
}
首先是从data对象中依次取出各项输入参数，然后调用接口函数create()（将在子类MediaPlayerService中实现），最后向reply中写入返回数据。这个函数返回后，代理那边的transact()也会跟着返回。
那么onTransact()函数是怎么被调用的呢？通过查看BnInterface模板类的定义可以看到，这个类也是一个多重继承类，另一个父类是BBinder（frameworks\base\include\utils\Binder.h，frameworks\base\libs\utils\Binder.cpp）。BBinder类继承自IBinder，也实现了transact()函数，在这个函数中调用onTransact()函数。而BBinder对象的transact()函数则是在IPCThreadState类的executeCommand()成员函数中调用的。这已经涉及到较底层的实现，在这里不再多说。
上面这部分代码还与前面提到过的BpBinder对象的创建有关系。看其中的红色字体部分，通过create()函数调用会创建一个IMediaPlayer接口类的子类的对象，这个对象其实是MediaPlayerService::Client类（可以看一下MediaPlayerService的定义）的对象实例，而MediaPlayerService::Client类是继承自BnMediaPlayer类的，与BnMediaPlayerService类类似，BnMediaPlayer其实也是一个binder实现类（是BBinder的子类，进而也是IBinder的子类）。在上述代码中，通过Parcel的writeStrongBinder()函数将这个对象写入reply，而在代理侧，通过Parcel的readStrongBinder()函数读取则可以得到一个BpBinder的对象。至于类的具体创建过程已经封装在Parcel类的定义中，这里就不再多说了。
（4） 接口功能的真正实现
到这里两个binder类就已经定义完了，下面就是IMediaPlayerService接口函数的真正实现。前面已经说过这些函数在类MediaPlayerService中实现。这个类继承自BnMediaPlayerService，也间接地继承了IMediaPlayerService接口类定义的6个功能函数，只需要按照正常方式实现这6个功能函数即可，当然为了实现这6个函数就需要其它一大堆的东西，不过这些具体的实现方法已经与binder机制无关，不再多说。
在MediaPlayerService类中定义了一个静态函数instantiate()，在这个函数中创建MediaPlayerService的对象实例，并将这个对象注册到服务管理器中。这样需要使用的时候就可以从服务管理器获取IMediaPlayerService的代理对象。这个instantiate()是在MediaServer程序的main()函数中调用的。
void MediaPlayerService::instantiate() {
defaultServiceManager()->addService(
String16("media.player"), new MediaPlayerService());
}
（三） 总结一下
说了这么多，总结一下。下图是binder机制的层次模型。
如果一个服务需要通过binder机制对外提供跨进程的接口，需要做下面这些事情。
（1） 第一步，需要为这个接口定义一个继承自IInterface的接口类，假设叫做IMyService。
（2） 第二步，需要定义两个binder类，其中一个是代理类BpMyService，需继承自BpInterface；另一个是实现类BnMyService，需继承自BnInterface。
（3） 第三步，定义BnMyService的子类，这个子类可以是任何名字，比如就叫MyService，在其中真正实现接口所提供的各个函数。
（4） 第四步，创建MyService的实例，注册到服务管理器（如IMediaPlayerService），也可以在其它接口的函数中创建（如上面的IMediaPlayer）。
_____________________________________________________________________
Binder, BBinder和BpBinder
这3个类，是对Android Binder框架的抽象，其实这个BBinder，改成BnBinder可能更形象一些。
但是要注意的是，一个IXXXService的继承图中，BpBinder并不在这个继承关系之中，也就是说BpBinder并没有子类。但是BBinder是在这个继承关系当中的，它的子类就是BnInterface。
换句话说，BBinder和BpBinder的功能并不是对称的，以前就是没有理解到这一点，才会一直很糊涂。
BpBinder的是存在于BpRefBase中的mRemote的成员变量中。从Client调用Service的过程中分析，就更清楚了。
假设有一个IXXXService接口：
class IXXXService : public IInterface {
....
public void helloWorld(const char* str);
....
}
（1）client调用service
client得到一个BpXXXService以后
（a）会调用BpXXXService实现的helloWorld，它会将str参数打包到Parcel中。然后调用remote()->transact(xxx)
（b）remote()是在BpXXXService的父类BpRefBase中实现的，返回的就是一个BpBinder.实际上调用的就是BpBinder的transact
（c）BpBinder的transact实现，就是直接调用IPCThreadState::self()->transact()发送数据。
（2）service接收client请求：
（a）通过IPCThreadState接收到client的请求后，首先会调用BBinder的transact方法。
（b）BBinder的transact方法又会调用子类实现的虚拟方法onTransact。这个虚拟方法是在BnXXXService中实现的。
（c）onTransact方法，会通过传递进来的参数来判断，需要调用IXXXService中的那个方法，示例中只有一个helloWorld方法。
（d）直接调用helloWorld，就会找到它的真正实现，也就是BnXXXService的子类XXXService中的helloWorld方法。
总结一下，从上面的流程当中就可以看出前文说的，BpBinder并不在继承关系当中，它只是一个打包数据，并通过IPCThreadState::self()->transact()方法发送出去。
而BBinder和BnXXXService的作用，就是接收IPCThreadState传递过来的信息，解包数据，并调用XXXService真正的实现。
IPC的数据处理，Binder Driver和ServiceManager学习后会继续分析总结。
以上是关于从mediaserver入手快速理解binder机制（最简单理解binder）的主要内容，如果未能解决你的问题，请参考以下文章
Android-深入理解Binder
android binder 机制二(client和普通server)
Android Binder解析
Binder驱动理解
源码分析——从AIDL的使用开始理解Binder进程间通信的流程
从Activity的启动流程理解Binder
