Android -- IPC通信机制之一Binder简介
随着慢慢进入Android Media模块，遇到了很多新的知识和难点，其中之一就是native代码中使用频繁的Binder通信机制。Binder是Android中使用最频繁的一种IPC通信机制，底层基于内核的binder驱动。谷歌大神在native层封装了一套Binder API，供我们实现自己的Binder服务。 Binder是一种Client/Server架构的通信机制，它往往以系统服务的形式存在于系统中。客户端获取一个服务代理对象，通过该服务代理对象与与远程的Server(通常服务端也会有一个服务端代理对象)进行操作交互，实现IPC通信。既然，Binder通信基于Client/Server架构，且以服务的形式存在，那就必须要考虑服务的管理工作。Android中有一个特殊的程序专门用来管理系统中各种各样的服务，它就是ServiceManager。我们实现了自己的服务后，需要注册到ServiceManager中；当Client要使用某个服务时，则要通过ServiceManager获取到该服务的代理对象。 说了这么多， 我们就以MediaServer这个服务为例，来分析native层Binder的通信机制。MediaServer是Android系统中一个庞大、复杂的模块，它在init.rc进行声明：
service media /system/bin/mediaserver当init进程解析到该服务声明时，会为它创建进程并启动它的主程序，具体定义在main_mediaserver.cpp中：
class main
user media
group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
ioprio rt 4
int main(int argc __unused, char** argv){ signal(SIGPIPE, SIG_IGN); char value[PROPERTY_VALUE_MAX]; bool doLog = (property_get("ro.test_harness", value, "0") > 0) && (atoi(value) == 1); pid_t childPid; // FIXME The advantage of making the process containing media.log service the parent process of // the process that contains all the other real services, is that it allows us to collect more // detailed information such as signal numbers, stop and continue, resource usage, etc. // But it is also more complex. Consider replacing this by independent processes, and using // binder on death notification instead. if (doLog && (childPid = fork()) != 0) { // media.log service //prctl(PR_SET_NAME, (unsigned long) "media.log", 0, 0, 0); // unfortunately ps ignores PR_SET_NAME for the main thread, so use this ugly hack strcpy(argv[0], "media.log"); sp<ProcessState> proc(ProcessState::self()); MediaLogService::instantiate(); ProcessState::self()->startThreadPool(); for (;;) { ... } else { // all other services if (doLog) { prctl(PR_SET_PDEATHSIG, SIGKILL); // if parent media.log dies before me, kill me also setpgid(0, 0); // but if I die first, don't kill my parent } InitializeIcuOrDie(); sp<ProcessState> proc(ProcessState::self());//1、创建ProcessState实例 sp<IServiceManager> sm = defaultServiceManager();//2、获取IServiceManager的实例，与ServiceManagner交互，用于注册或者获取服务 ALOGI("ServiceManager: %p", sm.get());//调试信息 AudioFlinger::instantiate(); MediaPlayerService::instantiate();//3、创建MediaPlayerService实例,通过ServiceManager注册服务 ResourceManagerService::instantiate(); CameraService::instantiate(); AudioPolicyService::instantiate(); SoundTriggerHwService::instantiate(); RadioService::instantiate(); registerExtensions(); //4、创建线程、启动线程池，处理Binder通信请求 ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); }}我们根据代码标记处的四步代码处理，来具体分析其中的Binder通信机制。
一、创建ProcessState对象
sp<ProcessState> proc(ProcessState::self());//1、创建ProcessState实例ProcessState类描述了当前进程的状态信息，每个进程只会有一个ProcessState实例。看它的构造过程：
//self()使用了单例模式,每个进程只有一个ProcessState对象sp<ProcessState> ProcessState::self(){ Mutex::Autolock _l(gProcessMutex); if (gProcess != NULL) { return gProcess; } gProcess = new ProcessState; return gProcess;}self()使用单例模式创建ProcessState实例，具体构造过程看其构造函数：ProcessState::ProcessState() : mDriverFD(open_driver())//打开/dev/binder这个虚拟设备，它的作用就是用于完成进程间通信 , mVMStart(MAP_FAILED) , mThreadCountLock(PTHREAD_MUTEX_INITIALIZER) , mThreadCountDecrement(PTHREAD_COND_INITIALIZER) , mExecutingThreadsCount(0) , mMaxThreads(DEFAULT_MAX_BINDER_THREADS) , mManagesContexts(false) , mBinderContextCheckFunc(NULL) , mBinderContextUserData(NULL) , mThreadPoolStarted(false) , mThreadPoolSeq(1){ if (mDriverFD >= 0) { // XXX Ideally, there should be a specific define for whether we // have mmap (or whether we could possibly have the kernel module // availabla).#if !defined(HAVE_WIN32_IPC) // mmap the binder, providing a chunk of virtual address space to receive transactions. /* *mmap将一个文件或者其它对象映射进内存 * *void* mmap(void* start,size_t length,int prot,int flags,int fd,off_t offset); * *start：映射区的开始地址，设置为0时表示由系统决定映射区的起始地址。 **length：映射区的长度。//长度单位是 以字节为单位，不足一内存页按一内存页处理**prot：期望的内存保护标志，不能与文件的打开模式冲突。是以下的某个值，可以通过or运算合理地组合在一起*PROT_EXEC //页内容可以被执行*PROT_READ //页内容可以被读取*PROT_WRITE //页可以被写入*PROT_NONE //页不可访问**flags：指定映射对象的类型，映射选项和映射页是否可以共享。它的值可以是一个或者多个以下位的组合体*MAP_FIXED //使用指定的映射起始地址，如果由start和len参数指定的内存区重叠于现存的映射空间，重叠部分将会被丢弃。* //如果指定的起始地址不可用，操作将会失败。并且起始地址必须落在页的边界上。*MAP_SHARED //与其它所有映射这个对象的进程共享映射空间。对共享区的写入，相当于输出到文件。* //直到msync()或者munmap()被调用，文件实际上不会被更新。*MAP_PRIVATE //建立一个写入时拷贝的私有映射。内存区域的写入不会影响到原文件。这个标志和以上标志是互斥的，只能使用其中一个。*MAP_DENYWRITE //这个标志被忽略。*MAP_EXECUTABLE //同上*MAP_NORESERVE //不要为这个映射保留交换空间。当交换空间被保留，对映射区修改的可能会得到保证。* //当交换空间不被保留，同时内存不足，对映射区的修改会引起段违例信号。*MAP_LOCKED //锁定映射区的页面，从而防止页面被交换出内存。*MAP_GROWSDOWN //用于堆栈，告诉内核VM系统，映射区可以向下扩展。*MAP_ANONYMOUS //匿名映射，映射区不与任何文件关联。*MAP_ANON //MAP_ANONYMOUS的别称，不再被使用。*MAP_FILE //兼容标志，被忽略。*MAP_32BIT //将映射区放在进程地址空间的低2GB，MAP_FIXED指定时会被忽略。当前这个标志只在x86-64平台上得到支持。*MAP_POPULATE //为文件映射通过预读的方式准备好页表。随后对映射区的访问不会被页违例阻塞。*MAP_NONBLOCK //仅和MAP_POPULATE一起使用时才有意义。不执行预读，只为已存在于内存中的页面建立页表入口。* *fd：有效的文件描述词。一般是由open()函数返回，其值也可以设置为-1，此时需要指定flags参数中的MAP_ANON,表明进行的是匿名映射。**off_toffset：被映射对象内容的起点。**成功执行时，mmap()返回被映射区的指针* */ mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);//mmap后，binder驱动会分配一块内存来接收数据 if (mVMStart == MAP_FAILED) { // *sigh* ALOGE("Using /dev/binder failed: unable to mmap transaction memory.\n"); close(mDriverFD); mDriverFD = -1; }#else mDriverFD = -1;#endif } LOG_ALWAYS_FATAL_IF(mDriverFD < 0, "Binder driver could not be opened. Terminating.");}其中有一个很重要的初始化操作就是调用open_driver()函数初始化了mDriverFD字段，它保存了/dev/binder设备文件的文件描述符：static int open_driver(){ int fd = open("/dev/binder", O_RDWR);//打开这个设备，获取对应的文件描述符，这个fd就是我们与kernel中的binder驱动交互的通道 if (fd >= 0) { fcntl(fd, F_SETFD, FD_CLOEXEC);//fcntl函数可以设置fd对应的文件的某些属性 int vers = 0; status_t result = ioctl(fd, BINDER_VERSION, &vers); if (result == -1) { ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno)); close(fd); fd = -1; } if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) { ALOGE("Binder driver protocol does not match user space protocol!"); close(fd); fd = -1; } size_t maxThreads = DEFAULT_MAX_BINDER_THREADS; result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);//设置fd所支持的最大线程数 if (result == -1) { ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno)); } } else { ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno)); } return fd;}/dev/binder是一个Binder设备，我们通过对该设备进行读写来与Binder驱动通信。该函数中打开了Binder设备，并对其进行了一些设置操作，如该设备支持的最大线程数等。再看构造函数中的处理，我们获取到了Binder设备的文件描述符后，需要调用mmap()把该文件映射到内存中，此时Binder驱动就会为该设备分配一块内存空间，用来进行数据交互。这里ProcessState的创建工作就结束了，它最主要的工作就是打开了Binder设备，并把它映射到内存中，以支持IPC通信。
二、获取ServiceManager代理
紧接着，看第二步：sp<IServiceManager> sm = defaultServiceManager();//2、获取IServiceManager的实例，与ServiceManagner交互，用于注册或者获取服务直接看defaultServiceManager()函数：
//使用了单例设计模式这里也使用了单例模式，主要是为了获取gDefaultServiceManager实例，它的类型是IServiceManager（IInterface的子类，IInterface中定义了两个重要的目标函数），该类定义了ServiceManager提供的所有业务方法：
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL
if (gDefaultServiceManager == NULL)
sleep(1);
}
}
return gDefaultServiceManager;
}
//IServiceManager是一个业务逻辑类，它定义了ServiceManager需要提供的服务;从函数声明可知,主要包括获取服务、检查服务、添加服务和枚举服务//重要地，它内部声明了一个宏定义函数:DECLARE_META_INTERFACE(ServiceManager);class IServiceManager : public IInterface{public: DECLARE_META_INTERFACE(ServiceManager); /** * Retrieve an existing service, blocking for a few seconds * if it doesn't yet exist. */ virtual sp<IBinder> getService( const String16& name) const = 0; /** * Retrieve an existing service, non-blocking. */ virtual sp<IBinder> checkService( const String16& name) const = 0; /** * Register a service. */ virtual status_t addService( const String16& name, const sp<IBinder>& service, bool allowIsolated = false) = 0; /** * Return list of all existing services. */ virtual Vector<String16> listServices() = 0; enum {//这里定义的是四个业务方法的编号，就是onTransact()、transact()函数中的code值 GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION, CHECK_SERVICE_TRANSACTION, ADD_SERVICE_TRANSACTION, LIST_SERVICES_TRANSACTION, };};
为了获取到ServiceManager的代理对象，这里有两个主要的函数调用：interface_cast()以及getContextObject()。我们从内而外分析，先看getContextObject()实现：//参数传入是NULL层次调用getStrongProxyForHandle()函数，由函数名称大概可知它会根据一个Handle值(这里为0)去得到一个代理；看它的具体实现：
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{
return getStrongProxyForHandle(0);//参数是0，是一个特殊的句柄;观察函数名大概可以猜出是要根据某一个句柄值，去找到某一个代理对象；从这看，这里的0更像是一个数组索引
}
//最后返回的是一个指向BpBinder类型的强指针sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle){ sp<IBinder> result; AutoMutex _l(mLock); handle_entry* e = lookupHandleLocked(handle);//根据参数值，找到它所对应的那个代理对象；这里参数值是0;返回值类型是handle_entry if (e != NULL) { // We need to create a new BpBinder if there isn't currently one, OR we // are unable to acquire a weak reference on this current one. See comment // in getWeakProxyForHandle() for more info about this. IBinder* b = e->binder; if (b == NULL || !e->refs->attemptIncWeak(this)) { if (handle == 0) {//从源码注释可知，handle为0代表了一个特殊的代理对象:context manager，即ServiceManager的代理对象 // Special case for context manager... // The context manager is the only object for which we create // a BpBinder proxy without already holding a reference. // Perform a dummy transaction to ensure the context manager // is registered before we create the first local reference // to it (which will occur when creating the BpBinder). // If a local reference is created for the BpBinder when the // context manager is not present, the driver will fail to // provide a reference to the context manager, but the // driver API does not return status. // // Note that this is not race-free if the context manager // dies while this code runs. // // TODO: add a driver API to wait for context manager, or // stop special casing handle 0 for context manager and add // a driver API to get a handle to the context manager with // proper reference counting. Parcel data; status_t status = IPCThreadState::self()->transact( 0, IBinder::PING_TRANSACTION, data, NULL, 0);//保证在我需要创建这样一个context manager实例之前，它已经注册到系统中了；否则，返回NULL if (status == DEAD_OBJECT) return NULL; } b = new BpBinder(handle); //创建BpBinder对象，用于填充;handle值会保存到mHandle,此处是0 e->binder = b; if (b) e->refs = b->getWeakRefs(); result = b; } else { // This little bit of nastyness is to allow us to add a primary // reference to the remote proxy when this team doesn't have one // but another team is sending the handle to us. result.force_set(b); e->refs->decWeak(this); } } return result;}果然，它通过lookupHandleLocked()函数，查找句柄(handle)值为0的那个代理对象：ProcessState::handle_entry* ProcessState::lookupHandleLocked(int32_t handle){ const size_t N=mHandleToObject.size(); if (N <= (size_t)handle) {//如果集合内存储的对象总数小于要被查找的索引值，则会创建一个新的对象 handle_entry e; e.binder = NULL;//填充对象,IBinder类型 e.refs = NULL;//填充对象,RefBase::weakref_type类型;用于引用计数,控制对象的消亡 status_t err = mHandleToObject.insertAt(e, N, handle+1-N); if (err < NO_ERROR) return NULL; } return &mHandleToObject.editItemAt(handle);}从我们分析的意图来看，0这个句柄值所对应的代理对象就应该是ServiceManager。该函数的整个处理过程类似数组的查找，最后返回一个ProcessState::handle_entry类型对象，它的类型定义是： struct handle_entry { IBinder* binder; RefBase::weakref_type* refs; };我们主要关注IBinder成员变量。如果根据句柄值，没有查找到对应的资源项，就会重新构建一个handle_entry对象，它的binder值为null；此时符合这种场景。回到getStrongProxyForHandle()函数，由于我们这里的handle值就是0，且e->binder为null。最后就会根据句柄值创建一个BpBinder实例，并返回函数调用。
至此，我们就遇到了几个重要的Binder类型：BpBinder、BBinder和IBinder，它们是Android中用于Binder通信的代表；即正真与Binder驱动交互，都要通过这三个类来完成。
我们首先看下这几个类的家族图谱：
BpBinder的主要定义如下：
//在Binder通信框架中，是客户端与Server进行交互的代理类;它与一个BBinder对应BBinder的定义类似：
class BpBinder : public IBinder
{
public:
BpBinder(int32_t handle);
inline int32_t handle() const { return mHandle; }
virtual const String16& getInterfaceDescriptor() const;
virtual status_t transact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
...
protected:
virtual ~BpBinder();
virtual void onFirstRef();
virtual void onLastStrongRef(const void* id);
virtual bool onIncStrongAttempted(uint32_t flags, const void* id);
private:
const int32_t mHandle;//保持handle值，此处为0；在与BBinder通信时，可以根据句柄值找到目的对象
...
};
//与BpBinder对应，是Server的代理类;它与BpBinder进行交互class BBinder : public IBinder{public: BBinder(); virtual const String16& getInterfaceDescriptor() const; ... virtual status_t transact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0); ...protected: virtual ~BBinder(); virtual status_t onTransact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0); ...};BpBinder中的transact()函数是Client端(这里是BpServiceManager)用来向Server代理端发送进程间通信请求的。当Binder驱动接收到Client组件发送过来的进程间通信请求后，就会调用BBinder::transact()处理该请求；BBinder中的onTransact()函数一般都是由一个BBinder的子类(这里是BnServiceManager，Server组件)来实现，它负责分发接收到的来自Client端的进程间通信请求，并交与某个服务类(服务类一般都是Server组件的子类，并实现服务的业务方法；我们注册一个服务时，就是将这个服务类注册进系统中。这里是Service Manager处理。
我们得到了new BpBinder(0)实例对象后，再返回到外层函数调用：//使用了单例设计模式interface_cast<IServiceManager>()函数是一个重要的模板函数，它定义IServiceManager.h中：
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock);
while (gDefaultServiceManager == NULL) {
/*
*ProcessState::self()->getContextObject(NULL)函数最终返回一个new BpBinder(0)对象实例
*
*所以就得出:
*
*interface_cast<IServiceManager>(new BpBinder(0));
*
*而BpBinder实例就是一个与Server交互的代理类，我们带着这个代理类实例去调用interface_cast()
*
*/
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL
if (gDefaultServiceManager == NULL)
sleep(1);
}
}
return gDefaultServiceManager;
}
/*一个模板函数当INTERFACE为IServiceManager时，整个函数定义就是:template<typename IServiceManager>inline sp<IServiceManager> interface_cast(const sp<IBinder>& obj){ return IServiceManager::asInterface(obj);}实际调用IServiceManager::asInterface(obj)函数*/template<typename INTERFACE>inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj){ return INTERFACE::asInterface(obj);}由代码可知，它实际调用的是IServiceManager::asInterface(obj)函数，那asInterface()函数到底是怎么声明的呢？在IInterface.h中有一个特殊的宏定义：#define DECLARE_META_INTERFACE(INTERFACE) \ static const android::String16 descriptor; \ static android::sp<I##INTERFACE> asInterface( \ const android::sp<android::IBinder>& obj); \ virtual const android::String16& getInterfaceDescriptor() const; \ I##INTERFACE(); \ virtual ~I##INTERFACE(); \(C++中'##'是连接符号，可以将两个token连接成一个token)它声明了几个函数，其中就有asInterface()，具体的类型名称都由模板类型决定；同时，这几个函数的定义也是由一个宏来定义的：
#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> I##INTERFACE::asInterface( \ const android::sp<android::IBinder>& obj) \ { \ android::sp<I##INTERFACE> intr; \ if (obj != NULL) { \ intr = static_cast<I##INTERFACE*>( \ obj->queryLocalInterface( \ I##INTERFACE::descriptor).get()); \ if (intr == NULL) { \ intr = new Bp##INTERFACE(obj); \ } \ } \ return intr; \ } \ I##INTERFACE::I##INTERFACE() { } \ I##INTERFACE::~I##INTERFACE() { } \而IServiceManager是IInterface的子类，自然而然就继承了这些宏定义的方法；同时，IServiceManager也明确了这两个宏定义的类型：DECLARE_META_INTERFACE(ServiceManager);
IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");//第二个变量会初始化一个descriptor成员变量，它跟进程间通信的合法性检测有关所以，我们就得出了这几个重要的函数声明与定义：
//#define DECLARE_META_INTERFACE(INTERFACE) \ static const android::String16 descriptor; \ static android::sp<IServiceManager> asInterface( \ const android::sp<android::IBinder>& obj); \ virtual const android::String16& getInterfaceDescriptor() const; \ IServiceManager(); \ virtual ~IServiceManager();
//#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \ const android::String16 IServiceManager::descriptor(NAME); \ const android::String16& \ IServiceManager::getInterfaceDescriptor() const { \ return IServiceManager::descriptor; \ } \ android::sp<IServiceManager> IServiceManager::asInterface( \ const android::sp<android::IBinder>& obj) \ { \ android::sp<IServiceManager> intr; \ if (obj != NULL) { \ intr = static_cast<IServiceManager*>( \ obj->queryLocalInterface( \ IServiceManager::descriptor).get()); \ if (intr == NULL) { \ intr = new BpServiceManager(obj); \ } \ } \ return intr; \ } \ IServiceManager::IServiceManager() { } \ IServiceManager::~IServiceManager() { } 我们初始化了descriptor成员，它描述了某个服务的名字；IServiceManager::asInterface()函数的定义也明确了，我们就接着看对它的调用。我们传入的参数是new BpBinder(0)实例对象，第一次调用时，我们会以BpBinder为参数创建一个BpServiceMananger对象。这里又冒出了一个BpXXX类，它又是什么呢？要搞清楚它的作用，我们首先要明确整个IServiceManager类的家族关系：
上图描述了IServiceManager类的整个家族图谱，同时它也是一个标准的使用Binder API搭建的一个使用Binder进行IPC通信的服务模板。此时我们的服务是ServiceManager。 因为Binder是基于客户端/服务端架构的，所以BpInterface、BnInterface分支分别代表了Client组件和Server组件(可以将它们归为Binder API的一部分)；BpServiceManager、BnServiceManager则是ServiceManage实现的Client组件和Server组件。 那我们再来看下BpServiceManager和BnServiceManager组件的实现：
// ----------------------------------------------------------------------
class BpServiceManager : public BpInterface<IServiceManager>
{
public:
BpServiceManager(const sp<IBinder>& impl)
: BpInterface<IServiceManager>(impl)
{
}
virtual sp<IBinder> getService(const String16& name) const
{
unsigned n;
for (n = 0; n < 5; n++){
sp<IBinder> svc = checkService(name);
if (svc != NULL) return svc;
ALOGI("Waiting for service %s...\n", String8(name).string());
sleep(1);
}
return NULL;
}
virtual sp<IBinder> checkService( const String16& name) const
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeString16(name);
remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);
return reply.readStrongBinder();
}
virtual status_t addService(const String16& name, const sp<IBinder>& service,
bool allowIsolated)
{//Parcel可以看做是一个数据存储类,都是将数据封装到对象中
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeString16(name);
data.writeStrongBinder(service);//服务实例
data.writeInt32(allowIsolated ? 1 : 0);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//remote()返回的就是new BpBinder(0)
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
virtual Vector<String16> listServices()
{
Vector<String16> res;
int n = 0;
for (;;) {
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());//首先写入IServiceManager的接口描述符，用于后面的CHECK_INTERFACE()合法性检测
data.writeInt32(n++);
status_t err = remote()->transact(LIST_SERVICES_TRANSACTION, data, &reply);
if (err != NO_ERROR)
break;
res.add(reply.readString16());
}
return res;
}
};
status_t BnServiceManager::onTransact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){ //printf("ServiceManager received: "); data.print(); switch(code) { case GET_SERVICE_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply);//检查该进程间通信的合法性，判断是否是从IServiceManager Client组件发送过来的，主要依据就是 //IMPLEMENT_META_INTERFACE宏实现中初始化的descriptor成员值，如果判断为非法，则不会往下执行 String16 which = data.readString16(); sp<IBinder> b = const_cast<BnServiceManager*>(this)->getService(which); reply->writeStrongBinder(b); return NO_ERROR; } break; case CHECK_SERVICE_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply); String16 which = data.readString16(); sp<IBinder> b = const_cast<BnServiceManager*>(this)->checkService(which); reply->writeStrongBinder(b); return NO_ERROR; } break; case ADD_SERVICE_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply); String16 which = data.readString16(); sp<IBinder> b = data.readStrongBinder(); status_t err = addService(which, b); reply->writeInt32(err); return NO_ERROR; } break; case LIST_SERVICES_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply); Vector<String16> list = listServices(); const size_t N = list.size(); reply->writeInt32(N); for (size_t i=0; i<N; i++) { reply->writeString16(list[i]); } return NO_ERROR; } break; default: return BBinder::onTransact(code, data, reply, flags); }}
如果我们要搭建一个名为MyService的自定义服务，整体架构上我们只需在IServiceManager类的位置声明一个类IMyService进行替换，定义自己的业务方法并实现IInterface的宏方法，再实现我们自己的Client组件和Server组件(其中的实现细节都可以参考上面的BpServiceManager和BnServiceManager)，那IMyService服务的整个框架就搭成了。
在创建BpServiceManager时，我们传入了一个BpBinder实例；在Client组件侧，我们进行Binder通信使用的就是这个new BpBinder(0)实例；BpRefBase有一个IBinder类型的指针变量mRemote，BpBinder实例就是保存在这个变量中，用于后面的Binder通信。
分析到这，我们就知道了重要的两点：
- interface_cast<>()函数并不是正真的接口类型转换，而是用BpBinder(mHandle为0)实例创建了一个BpServiceManager对象，以此来创建了Client组件，并为它提供了与Server组件通信的桥梁.
- defaultServiceManager()函数返回的是一个ServiceManager client组件的代理，我们通过这个Client组件实例与Server组件通信，来获得ServiceManager的服务.
三、注册系统服务
MediaPlayerService::instantiate();//3、创建MediaPlayerService实例,通过ServiceManager注册服务在了解了Binder通信的基本原理后，我们在来看一个使用Binder进行服务注册的实例。ServiceManager是所有服务的总管，服务都要通过它注册到系统中。我们看一下MediaPlayerService服务注册的过程，来简单分析一下Binder通信的实际过程。 MediaPlayerService的构造过程如下：
void MediaPlayerService::instantiate() {
defaultServiceManager()->addService(
String16("media.player"), new MediaPlayerService());//调用addService()添加的服务实例对象是BnXXXYYY的子类，它是实现了业务接口的Server组件子类.
}
addService()函数传入了一个MediaPlayerService实例对象，它实际是一个BnMediaPlayerService（MediaPlayerService的Server组件）的子类，并实现了IMeidaPlayerService中定义的所有业务方法。当我们调用ServiceManager的getService()获取MediaPlayerService的代理对象时，获取到的实际是一个代表代表该服务Server组件的类型为BpBinder的代理对象，我们还需调用IMediaPlayerService::asInterface()方法将该BpBinder实例转化成BpMediaPlayerService对象，供客户端调用MediaPlayerService提供的服务。我们只关注服务的注册过程，而不着重考虑MediaPlayerService的创建。该方法中调用了addService()方法进行服务注册，并传入了一个服务名称字符串和服务实例对象；由此我们基本可以猜出，别处如果要获取某个服务，应该就是通过这个名称字符串来查找、获取的。我们已经知道defaultServiceManager()函数返回的是一个BpServiceManager对象，直接看它的addService()方法：virtual status_t addService(const String16& name, const sp<IBinder>& service,transact()函数的第一个参数，我们可以看做是一个操作代码，或者是某个操作函数的标号；Server组件可以根据这个code值，得悉我们需要它做什么处理。 直接看BpBinder中的处理：
bool allowIsolated)
{//Parcel可以看做是一个数据存储类,都是将数据封装到对象中
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);//服务实例
data.writeInt32(allowIsolated ? 1 : 0);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//remote()返回的就是new BpBinder(0)
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
status_t BpBinder::transact(这里出现了一个新类型IPCThreadState，它是真正做事情的一个实体，并且每个线程都会有一个IPCThreadState实例。从Client组件传过来的请求都是靠它处理的。我们看它的self()函数：
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
// Once a binder has died, it will never come back to life.
if (mAlive) {
status_t status = IPCThreadState::self()->transact(
mHandle, code, data, reply, flags);//创建IPCThreadState实例，来进行真正的IPC通信
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}
//主要就是创建IPCThreadState对象，并使用了同步机制IPCThreadState* IPCThreadState::self(){ if (gHaveTLS) {restart: const pthread_key_t k = gTLS; IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k); if (st) return st; return new IPCThreadState;//调用构造函数,创建IPCThreadState对象 } if (gShutdown) return NULL; pthread_mutex_lock(&gTLSMutex); if (!gHaveTLS) { if (pthread_key_create(&gTLS, threadDestructor) != 0) { pthread_mutex_unlock(&gTLSMutex); return NULL; } gHaveTLS = true; } pthread_mutex_unlock(&gTLSMutex); goto restart;}看它的构造函数做了哪些处理：IPCThreadState::IPCThreadState() : mProcess(ProcessState::self()),/*保存当前进程的ProcessState对象*/ mMyThreadId(gettid()), mStrictModePolicy(0), mLastTransactionBinderFlags(0){ pthread_setspecific(gTLS, this); clearCaller(); mIn.setDataCapacity(256);//设置接手数据的缓冲大小 mOut.setDataCapacity(256);//设置发送数据的缓冲大小}由前面的分析可知，每个进程只会有一个ProcessState实例，这里保存了一份在mProcess成员中；mIn、mOut是它的两个内部成员：//可以把Parcel类看成是一个封装数据的类 Parcel mIn;//存储来自Binder设备的数据 Parcel mOut;//存储发送到Binder设备的数据分别对应着接收缓冲区和发送缓冲区，IPCThreadState构造过程中，给这两个缓冲区设置了缓冲大小。再分析IPCThreadState::transact()函数：
status_t IPCThreadState::transact(int32_t handle, uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){ status_t err = data.errorCheck(); flags |= TF_ACCEPT_FDS; IF_LOG_TRANSACTIONS() { TextOutput::Bundle _b(alog); alog << "BC_TRANSACTION thr " << (void*)pthread_self() << " / hand " << handle << " / code " << TypeCode(code) << ": " << indent << data << dedent << endl; } if (err == NO_ERROR) { LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(), (flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY"); err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);//将数据传给内核中的Binder驱动 } if (err != NO_ERROR) { if (reply) reply->setError(err); return (mLastError = err); } if ((flags & TF_ONE_WAY) == 0) { #if 0 if (code == 4) { // relayout ALOGI(">>>>>> CALLING transaction 4"); } else { ALOGI(">>>>>> CALLING transaction %d", code); } #endif if (reply) { err = waitForResponse(reply);//数据发送出去后，等待Binder驱动回应 } else { Parcel fakeReply; err = waitForResponse(&fakeReply); } #if 0 if (code == 4) { // relayout ALOGI("<<<<<< RETURNING transaction 4"); } else { ALOGI("<<<<<< RETURNING transaction %d", code); } #endif IF_LOG_TRANSACTIONS() { TextOutput::Bundle _b(alog); alog << "BR_REPLY thr " << (void*)pthread_self() << " / hand " << handle << ": "; if (reply) alog << indent << *reply << dedent << endl; else alog << "(none requested)" << endl; } } else { err = waitForResponse(NULL, NULL); } return err;}通过代码分析可知，IPCThreadState内部采用了发送数据、等待回应的处理模式，这应该是我们很熟悉的数据处理模型。对这两步我们分别来看，首先是数据发送：status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags, int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer){ binder_transaction_data tr;//binder_transaction_data是一个数据对象，它由Binder驱动定义 tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */ tr.target.handle = handle;//BpBinder实例中的句柄值，这里是0 tr.code = code;//传给Serve组件的操作码，表示某种操作 tr.flags = binderFlags; tr.cookie = 0; tr.sender_pid = 0; tr.sender_euid = 0; const status_t err = data.errorCheck(); if (err == NO_ERROR) { tr.data_size = data.ipcDataSize(); tr.data.ptr.buffer = data.ipcData(); tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t); tr.data.ptr.offsets = data.ipcObjects(); } else if (statusBuffer) { tr.flags |= TF_STATUS_CODE; *statusBuffer = err; tr.data_size = sizeof(status_t); tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer); tr.offsets_size = 0; tr.data.ptr.offsets = 0; } else { return (mLastError = err); }//将数据写到Binder驱动中 mOut.writeInt32(cmd); mOut.write(&tr, sizeof(tr)); return NO_ERROR;}将数据封装到binder_transaction_data结构，并发送到内核中；它由Binder驱动定义。等待回应的处理部分是：status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult){ uint32_t cmd; int32_t err; while (1) { if ((err=talkWithDriver()) < NO_ERROR) break;//我去，talkWithDriver()，多么实在的名字 err = mIn.errorCheck(); if (err < NO_ERROR) break; if (mIn.dataAvail() == 0) continue; cmd = (uint32_t)mIn.readInt32(); IF_LOG_COMMANDS() { alog << "Processing waitForResponse Command: " << getReturnString(cmd) << endl; } switch (cmd) { case BR_TRANSACTION_COMPLETE: if (!reply && !acquireResult) goto finish; break; case BR_DEAD_REPLY: err = DEAD_OBJECT; goto finish; case BR_FAILED_REPLY: err = FAILED_TRANSACTION; goto finish; case BR_ACQUIRE_RESULT: { ALOG_ASSERT(acquireResult != NULL, "Unexpected brACQUIRE_RESULT"); const int32_t result = mIn.readInt32(); if (!acquireResult) continue; *acquireResult = result ? NO_ERROR : INVALID_OPERATION; } goto finish; case BR_REPLY://字面意思 { binder_transaction_data tr; err = mIn.read(&tr, sizeof(tr)); ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY"); if (err != NO_ERROR) goto finish; if (reply) { if ((tr.flags & TF_STATUS_CODE) == 0) { reply->ipcSetDataReference( reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer), tr.data_size, reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), freeBuffer, this); } else { err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer); freeBuffer(NULL, reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer), tr.data_size, reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), this); } } else { freeBuffer(NULL, reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer), tr.data_size, reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), this); continue; } } goto finish; default: err = executeCommand(cmd);//执行回复命令 if (err != NO_ERROR) goto finish; break; } }finish: if (err != NO_ERROR) { if (acquireResult) *acquireResult = err; if (reply) reply->setError(err); mLastError = err; } return err;}IPCThreadState中保存了ProcessState实例对象，该对象又保存了Binder驱动设备文件的描述符mDriverFD；talkWithDriver()函数通过IO控制命令，从设备文件中读取回驱动的回复指令保存到mIn中，然后执行该命令：status_t IPCThreadState::executeCommand(int32_t cmd){ ... case BR_TRANSACTION://业务回复 { ... if (tr.target.ptr) { sp<BBinder> b((BBinder*)tr.cookie);//出现了BBinder类型，它是BnServiceXXX的父类型 error = b->transact(tr.code, buffer, &reply, tr.flags);//调用它的transact() } else { error = the_context_object->transact(tr.code, buffer, &reply, tr.flags); } //ALOGI("<<<< TRANSACT from pid %d restore pid %d uid %d\n", // mCallingPid, origPid, origUid); if ((tr.flags & TF_ONE_WAY) == 0) { LOG_ONEWAY("Sending reply to %d!", mCallingPid); if (error < NO_ERROR) reply.setError(error); sendReply(reply, 0); } else { LOG_ONEWAY("NOT sending reply to %d!", mCallingPid); } mCallingPid = origPid; mCallingUid = origUid; mStrictModePolicy = origStrictModePolicy; mLastTransactionBinderFlags = origTransactionBinderFlags; IF_LOG_TRANSACTIONS() { TextOutput::Bundle _b(alog); alog << "BC_REPLY thr " << (void*)pthread_self() << " / obj " << tr.target.ptr << ": " << indent << reply << dedent << endl; } } break; case BR_DEAD_BINDER: { BpBinder *proxy = (BpBinder*)mIn.readPointer();//讣告相关的代码处理，只有BpBinder类型会接收到 proxy->sendObituary(); mOut.writeInt32(BC_DEAD_BINDER_DONE); mOut.writePointer((uintptr_t)proxy); } break; case BR_CLEAR_DEATH_NOTIFICATION_DONE: ... return result;}BBinder::transact()：status_t BBinder::transact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){ data.setDataPosition(0); status_t err = NO_ERROR; switch (code) { case PING_TRANSACTION: reply->writeInt32(pingBinder()); break; default: err = onTransact(code, data, reply, flags); break; } if (reply != NULL) { reply->setDataPosition(0); } return err;}最后会将回复的指令传给它的子类调用onTransact()去处理，一般是BnYyyXxx或BnYyyXxx的子类型来实现onTransact()函数处理。
由于要分析Binder通信的实际过程需要了解Binder驱动本身的协议和设计过程，所以上述的分析就显得较为单薄了。有兴趣的同学可以深入了解下Binder驱动的设计及实现，我们这里只是简略的过了一下这个过程，没有深入分析；这里主要是侧重于使用Binder IPC通信机制，设计自己的服务。PS：这里有一篇内核大神写的文章，详细地介绍了Binder驱动的原理及架构，有兴趣的同学可以看看：Android Bander设计与实现 - 设计篇
四、创建线程池
main_mediaserver中，服务注册完毕后， 还调用了两个函数：ProcessState::self()->startThreadPool();//创建一个子线程，加入到线程池中，监听驱动是否有数据需要处理来时刻监测来自驱动的请求：
IPCThreadState::self()->joinThreadPool();//将当前主线程加入到线程池中，监听驱动是否有数据需要处理
void ProcessState::startThreadPool(){ AutoMutex _l(mLock); if (!mThreadPoolStarted) {//头一次调用，mThreadPoolStarted肯定为false mThreadPoolStarted = true;//这里设置为true，防止重复启动线程池 spawnPooledThread(true); }}
void ProcessState::spawnPooledThread(bool isMain){ if (mThreadPoolStarted) { String8 name = makeBinderThreadName(); ALOGV("Spawning new pooled thread, name=%s\n", name.string()); sp<Thread> t = new PoolThread(isMain);//主动创建了一个子线程，来监听驱动的请求 t->run(name.string()); }}
class PoolThread : public Thread{public: PoolThread(bool isMain) : mIsMain(isMain)//isMain为TRUE { } protected: virtual bool threadLoop() { IPCThreadState::self()->joinThreadPool(mIsMain);//将线程加入到线程池中，用于处理驱动的数据请求;joinThreadPool()函数参数默认为TRUE return false; } const bool mIsMain;};
void IPCThreadState::joinThreadPool(bool isMain)//isMain为true，表明这个线程是我们主动创建加入到线程池中的；否则，则表明这个线程是应Binder驱动的请求创建并加入到线程池的ProcessState::self()->startThreadPool()主要就是创建了一个子线程用于接收、处理驱动的数据；最后，也将当前主线程加入到了线程池中，用于处理来自驱动的数据。这也表明Binder设备的通信是支持多线程技术的。
{
LOG_THREADPOOL("**** THREAD %p (PID %d) IS JOINING THE THREAD POOL\n", (void*)pthread_self(), getpid());
mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);//BC_ENTER_LOOPER通知驱动该线程加入到了主循环中,可以接收数据
//BC_REGISTER_LOOPER通知驱动一个线程已经创建了
// This thread may have been spawned by a thread that was in the background
// scheduling group, so first we will make sure it is in the foreground
// one to avoid performing an initial transaction in the background.
set_sched_policy(mMyThreadId, SP_FOREGROUND);
status_t result;
do {
processPendingDerefs();
// now get the next command to be processed, waiting if necessary
result = getAndExecuteCommand();//内部调用talkWithDriver()监听驱动是否有数据需要处理，调用executeCommand()处理数据
if (result < NO_ERROR && result != TIMED_OUT && result != -ECONNREFUSED && result != -EBADF) {
ALOGE("getAndExecuteCommand(fd=%d) returned unexpected error %d, aborting",
mProcess->mDriverFD, result);
abort();
}
// Let this thread exit the thread pool if it is no longer
// needed and it is not the main process thread.
if(result == TIMED_OUT && !isMain) {//如果我们长时间没有等到通信请求、或者执行处理数据时超，并且该线程不是我们主动创建的时，则需要跳出循环
break;
}
} while (result != -ECONNREFUSED && result != -EBADF);
LOG_THREADPOOL("**** THREAD %p (PID %d) IS LEAVING THE THREAD POOL err=%p\n",
(void*)pthread_self(), getpid(), (void*)result);
mOut.writeInt32(BC_EXIT_LOOPER);//通知驱动该线程已经退出主循环，不再接收数据
talkWithDriver(false);//参数为FALSE，表示不再接收数据
}
PS：Binder图示源文件下载