Binder简介

　　Binder是Android系统进程间通信的主要方式之一。

　　1.在ASOP中，Binder使用传统的C/S通信方式：即一个进程作为服务端提供诸如视音频解封装，解码渲染，地址查询等各种服务，众多进程作为客户端向服务端发起请求，获得所需的服务。

　　2.面向对象的封装模式：首先Binder是作为一个实体类存在于Server端，该对象拥有一系列的借口来实现对服务端的各种操作，而在诸多的Client端，都存在一个Binder入口，通往了特定的Server端，就像是Server端的Binder实体拥有许许多多的指针遍布于各个Client中，Client就通过这个指针实现了向服务端的请求。

　　二、Binder结构

　　首先看一下安卓的整体架构，可其遍布于整个安卓系统中，自地向上形成了一个统一的接口：(转载)

　　当然，Client和Service端都通过一个ServiceManager进行统一管理，具体通信模型如下：

　　三、结合代码讲解

　　当然，要细说Binder机制可不是一朝一夕的事情，我们今天结合安卓MediaPlayer的native层代码，来看看Binder是如何实现跨进程通信的。如果没有这方面知识还是建议先去小补一下。附上类图：

　　我们知道MediaPlayer的java层代码调用的就是再往下的native层C/C++代码，其中setDataSource()函数作为开路先锋带动了往下的各个类，所以我们就抓住它来分析一下Binder机制。直接看MediaPlayer.cpp的setDataSource()代码吧。

　　//代码目录：/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());//通过IPC机制获取一个远程服务

　　if (service != 0) {

　　sp player(service->create(this, mAudioSessionId));//通过MediaPlayerService端创建了一个Client

　　if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||

　　(NO_ERROR != player->setDataSource(fd, offset, length))) {//调用Client的setDataSource()

　　player.clear();

　　}

　　err = attachNewPlayer(player);

　　}

　　return err;

　　}

　　getMediaPlayerService()函数：一眼望去，就是请求Service无疑了。MediaPlayer.cpp中并没有这个函数的实现方法，所以我们去他的父类IMediaDeathNotify寻找，嘿，果然在这儿!

　　//代码码目录：/frameworks/av/media/libmedia/IMediaDeathNotifier.cpp

　　/*static*/const sp

　　IMediaDeathNotifier::getMediaPlayerService()

　　{

　　ALOGV("getMediaPlayerService");

　　Mutex::Autolock _l(sServiceLock);

　　if (sMediaPlayerService == 0) {

　　sp sm = defaultServiceManager();

　　sp binder;

　　do {

　　binder = sm->getService(String16("media.player"));

　　if (binder != 0) {

　　break;

　　}

　　ALOGW("Media player service not published, waiting...");

　　usleep(500000); // 0.5 s

　　} while (true);

　　if (sDeathNotifier == NULL) {

　　sDeathNotifier = new DeathNotifier();

　　}

　　binder->linkToDeath(sDeathNotifier);

　　sMediaPlayerService = interface_cast(binder);

　　}

　　ALOGE_IF(sMediaPlayerService == 0, "no media player service!?");

　　return sMediaPlayerService;

　　}

　　这段代码就是Client端的请求服务了，通过调用defaultServiceManager()得到IServiceManager，通过调用IServiceManager的getService()函数来查询“media.player”是否注册，如果注册则返回对应的IBinder，留给Client进行通信。然后就是通过interface_cast将IBinder转化为服务端IMediaPlayerService的指针返回。可是这个inteface_cast()是什么呢?是一个强制类型转换吗?不不不，一叶障目罢了，我们来看看它的定义：

　　代码目录：frameworks/native/include/binder/IInterface.h

　　template

　　inline sp interface_cast(const sp& obj)

　　{

　　return INTERFACE::asInterface(obj);

　　}

　　好家伙，直接返回自身的，即IMediaPlayerService::asInteface(),我们继续追,额，我就不贴代码了，你会发现IMediaPlayerService中并没有这个函数的定义，怎么回事儿?去父类看看!一对比就能发现蹊跷了：

　　/frameworks/native/include/binder/IInterface.h

　　// ----------------------------------------------------------------------

　　#define DECLARE_META_INTERFACE(INTERFACE) \

　　static const ::android::String16 descriptor; \

　　static ::android::sp asInterface( \

　　const ::android::sp<::android::IBinder>& obj); \

　　virtual const ::android::String16& getInterfaceDescriptor() const; \

　　I##INTERFACE(); \

　　virtual ~I##INTERFACE(); \

　　#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \

　　const ::android::String16 I##INTERFACE::descriptor(NAME); \

　　const ::android::String16& \

　　I##INTERFACE::getInterfaceDescriptor() const { \

　　return I##INTERFACE::descriptor; \

　　} \

　　::android::sp I##INTERFACE::asInterface( \

　　const ::android::sp<::android::IBinder>& obj) \

　　{ \

　　::android::sp intr; \

　　if (obj != NULL) { \

　　intr = static_cast( \

　　obj->queryLocalInterface( \

　　I##INTERFACE::descriptor).get()); \

　　if (intr == NULL) { \

　　intr = new Bp##INTERFACE(obj); \

　　} \

　　} \

　　return intr; \

　　} \

　　I##INTERFACE::I##INTERFACE() { } \

　　I##INTERFACE::~I##INTERFACE() { } \

　　#define CHECK_INTERFACE(interface, data, reply) \

　　if (!(data).checkInterface(this)) { return PERMISSION_DENIED; } \

　　IInterface中有这么一段奇怪的代码段，不妨，仔细看一下，哦，原来是一对宏声明和定义!而IMediaPlayerService里刚好有这两个宏的调用!那么就见泰山了。我们将IMediaPlayerService置换进去，就能看到IBinder转IMediaPlayerService的实现了!我就不再贴出了。

　　好了扯远了，我们通过getDefaultService得到了一个注册名为“mediapalyer"的服务，并通过interface_cast转换为一个IMediaPlayerService的指针返回。我们继续往下看：

　　sp player(service->create(this, mAudioSessionId));

　　原来是调用IMediaPlayer的creat函数，我们去看看：

　　代码目录：/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());

　　}

　　asBinder()是直接将client转化为binder接口，而没有经过ServiceManager这个中介，说明这是个匿名管道，只能在这两个进程间进行通信。来看一下：

　　// static

　　sp IInterface::asBinder(const sp& iface)

　　{

　　if (iface == NULL) return NULL;

　　return iface->onAsBinder();

　　}

　　template inline IBinder* BpInterface::onAsBinder() { return remote(); }

　　remote()得到的就是远端的BpBinder。

　　remote() ->transact(),这个函数要好好说道一下：

　　1.BpBinder,BBinder,IBinder是安桌Binder机制的抽象，其中BpBinder不在这些继承关系中。

　　2.remote()是在BpRefBase的子类中实现的，返回的就是一个BpBinder。

　　3.BpBinder的transact实现，就是直接调用IPCThreadState::self()->transact()发送数据。

　　4.Service端通过IPCThreadState接收到client的请求后，首先会调用BBinder的transact()方法。

　　5.BBinder的transact方法又会调用子类实现的虚拟方法onTransact。这个虚拟方法是在BnXXXService中实现的

　　所以，我们直接在BnMediaPlayerService中寻找onTransact()的CREAT实现:

　　xref: /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);

　　reply->writeStrongBinder(IInterface::asBinder(player));

　　return NO_ERROR;

　　} break;

　　...}

　　}

　　首先又将BpBinder转回了sp,然后调用了creat()方法，可是我们发现BnMediaPlayerService中只有一个onTransact()的实现，所以这个creat()我们要去它的子类寻找，果然就在MediaPlayerService中：无锡人流医院 http://xmobile.wxbhnk120.com/

　　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());

　　ALOGD("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;

　　}

　　代码简单易懂，创建了它一个自身类Client并返回指针供远端调用，这个Client包含了上层java的大部分接口。好了，回到我们的开始地方：

　　//代码目录：/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());//通过IPC机制获取一个远程服务

　　if (service != 0) {

　　sp player(service->create(this, mAudioSessionId));//通过MediaPlayerService端创建了一个Client

　　if ((NO_ERROR != doSetRetransmitEndpoint(player)) ||

　　(NO_ERROR != player->setDataSource(fd, offset, length))) {//调用Client的setDataSource()

　　player.clear();

　　}

　　err = attachNewPlayer(player);

　　}

　　return err;

　　}

　　后面就没啥说的了，直接调用Client的setDataSource进入了下一步处理。

　　总结一下：我们发现native层的大部分类都是采用IXXX，BpXXX，BnXXX形式的。在MediaPlayer框架层，由IMediaPlayer，IMediaPlayerService，IMediaPlayerClient三大元老组成了基本框架，由IBinder，BBinder(准确来说叫BnBinder比较合适)，BpBinder将其粘合。

　　我们发现，IXXX里总是一些虚抽象函数，不存在定义，由BpXXX和BnXXX继承它，BpXXX作为Client端的代理类，发起服务的请求，服务的实现则统一放在BnXXX类里。