Android(安卓)-- IPC通信机制之一Binder简介
16lz
2021-01-25
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 class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4当init进程解析到该服务声明时，会为它创建进程并启动它的主程序，具体定义在main_mediaserver.cpp中：
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 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 proc(ProcessState::self());//1、创建ProcessState实例 sp 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 proc(ProcessState::self());//1、创建ProcessState实例 ProcessState类描述了当前进程的状态信息，每个进程只会有一个ProcessState实例。看它的构造过程：
//self()使用了单例模式,每个进程只有一个ProcessState对象sp 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;//默认情况,最大支持的Binder线程为15个 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 sm = defaultServiceManager();//2、获取IServiceManager的实例，与ServiceManagner交互，用于注册或者获取服务 直接看defaultServiceManager()函数：
//使用了单例设计模式sp defaultServiceManager(){ if (gDefaultServiceManager != NULL) return gDefaultServiceManager; { AutoMutex _l(gDefaultServiceManagerLock); while (gDefaultServiceManager == NULL) { gDefaultServiceManager = interface_cast( ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL if (gDefaultServiceManager == NULL) sleep(1); } } return gDefaultServiceManager;} 这里也使用了单例模式，主要是为了获取gDefaultServiceManager实例，它的类型是IServiceManager（IInterface的子类，IInterface中定义了两个重要的目标函数），该类定义了ServiceManager提供的所有业务方法：
//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 getService( const String16& name) const = 0; /** * Retrieve an existing service, non-blocking. */ virtual sp checkService( const String16& name) const = 0; /** * Register a service. */ virtual status_t addService( const String16& name, const sp& service, bool allowIsolated = false) = 0; /** * Return list of all existing services. */ virtual Vector 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()实现：
//参数传入是NULLsp ProcessState::getContextObject(const sp& /*caller*/){ return getStrongProxyForHandle(0);//参数是0，是一个特殊的句柄;观察函数名大概可以猜出是要根据某一个句柄值，去找到某一个代理对象；从这看，这里的0更像是一个数组索引} 层次调用getStrongProxyForHandle()函数，由函数名称大概可知它会根据一个Handle值(这里为0)去得到一个代理；看它的具体实现：
//最后返回的是一个指向BpBinder类型的强指针sp ProcessState::getStrongProxyForHandle(int32_t handle){ sp 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对应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通信时，可以根据句柄值找到目的对象 ...};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)实例对象后，再返回到外层函数调用：
//使用了单例设计模式sp defaultServiceManager(){ if (gDefaultServiceManager != NULL) return gDefaultServiceManager; { AutoMutex _l(gDefaultServiceManagerLock); while (gDefaultServiceManager == NULL) {/* *ProcessState::self()->getContextObject(NULL)函数最终返回一个new BpBinder(0)对象实例 * *所以就得出: * *interface_cast(new BpBinder(0)); * *而BpBinder实例就是一个与Server交互的代理类，我们带着这个代理类实例去调用interface_cast() * */ gDefaultServiceManager = interface_cast( ProcessState::self()->getContextObject(NULL));//这里有两个函数调用,interface_cast()以及getContextObject()，参数是NULL if (gDefaultServiceManager == NULL) sleep(1); } } return gDefaultServiceManager;} interface_cast
/*一个模板函数当INTERFACE为IServiceManager时，整个函数定义就是:templateinline sp interface_cast(const sp& obj){ return IServiceManager::asInterface(obj);}实际调用IServiceManager::asInterface(obj)函数*/templateinline sp interface_cast(const sp& obj){ return INTERFACE::asInterface(obj);} 由代码可知，它实际调用的是IServiceManager::asInterface(obj)函数，那asInterface()函数到底是怎么声明的呢？在IInterface.h中有一个特殊的宏定义：
#define DECLARE_META_INTERFACE(INTERFACE) \ static const android::String16 descriptor; \ static android::sp asInterface( \ const android::sp& 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::asInterface( \ const android::sp& 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() { } \ 而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 asInterface( \ const android::sp& 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::asInterface( \ const android::sp& obj) \ { \ android::sp intr; \ if (obj != NULL) { \ intr = static_cast( \ 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{public: BpServiceManager(const sp& impl) : BpInterface(impl) { } virtual sp getService(const String16& name) const { unsigned n; for (n = 0; n < 5; n++){ sp svc = checkService(name); if (svc != NULL) return svc; ALOGI("Waiting for service %s...\n", String8(name).string()); sleep(1); } return NULL; } virtual sp 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& 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 listServices() { Vector 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 b = const_cast(this)->getService(which); reply->writeStrongBinder(b); return NO_ERROR; } break; case CHECK_SERVICE_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply); String16 which = data.readString16(); sp b = const_cast(this)->checkService(which); reply->writeStrongBinder(b); return NO_ERROR; } break; case ADD_SERVICE_TRANSACTION: { CHECK_INTERFACE(IServiceManager, data, reply); String16 which = data.readString16(); sp 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 list = listServices(); const size_t N = list.size(); reply->writeInt32(N); for (size_t i=0; iwriteString16(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& service, 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; } transact()函数的第一个参数，我们可以看做是一个操作代码，或者是某个操作函数的标号；Server组件可以根据这个code值，得悉我们需要它做什么处理。
直接看BpBinder中的处理：
status_t BpBinder::transact( 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，它是真正做事情的一个实体，其与Binder驱动真正交互信息；并且每个线程都会有一个IPCThreadState实例。从Client组件传过来的请求都是靠它处理的。我们看它的self()函数：
//主要就是创建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;}分析self()函数主要流程：当第一次调用self()函数时，gHaveTLS为false，因而不会进入第一个if判断中，也不会创建IPCThreadState。但是随后它进入第二个if判断，并启动TLS（Thread Local Storate，类似Java的ThreadLocal），然后返回到restart处新建一个IPCThreadState。当以后再被调用时，gHaveTLS为true：如果本地线程已经创建过IPCThreadState，那么pthread_getspecific就不为空：否则返回一个新建的IPCThreadLocal。
看它的构造函数做了哪些处理：
IPCThreadState::IPCThreadState() : mProcess(ProcessState::self()),/*保存当前进程的ProcessState对象*/ mMyThreadId(gettid()), mStrictModePolicy(0), mLastTransactionBinderFlags(0){ pthread_setspecific(gTLS, this); clearCaller(); mIn.setDataCapacity(256);//设置接手数据的缓冲大小为256 mOut.setDataCapacity(256);//设置发送数据的缓冲大小为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);//整理数据,存入mOut对象中 } 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(statusBuffer); tr.offsets_size = 0; tr.data.ptr.offsets = 0; } else { return (mLastError = err); }//将数据写到mOut Parcel对象中 mOut.writeInt32(cmd); mOut.write(&tr, sizeof(tr)); return NO_ERROR;} 将数据封装到binder_transaction_data结构,并最终存储到mOut中，准备发送到内核中；它由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()，多么实在的名字;其中会整理mOut中存储的数据信息，并最终发送给Binder驱动 err = mIn.errorCheck();//程序执行到此,说明已经收到了Binder驱动的回复,此时一般完成了相关的Binder请求 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(tr.data.ptr.buffer), tr.data_size, reinterpret_cast(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), freeBuffer, this); } else { err = *reinterpret_cast(tr.data.ptr.buffer); freeBuffer(NULL, reinterpret_cast(tr.data.ptr.buffer), tr.data_size, reinterpret_cast(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), this); } } else { freeBuffer(NULL, reinterpret_cast(tr.data.ptr.buffer), tr.data_size, reinterpret_cast(tr.data.ptr.offsets), tr.offsets_size/sizeof(binder_size_t), this); continue; } } goto finish;//跳出while循环,结束当前函数调用 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控制命令，向Binder设备文件发送mOut中的数据、读取驱动的回复指令保存到mIn中，然后执行该命令：
status_t IPCThreadState::talkWithDriver(bool doReceive){ if (mProcess->mDriverFD <= 0) { return -EBADF; } binder_write_read bwr;//Binder驱动定义的数据交换结构,可以用来保存需要发送到驱动程序的数据,以及Binder驱动返回的回复数据 // Is the read buffer empty? const bool needRead = mIn.dataPosition() >= mIn.dataSize(); // We don't want to write anything if we are still reading // from data left in the input buffer and the caller // has requested to read the next data. const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;//在bwr中填充需要write的内容和大小 bwr.write_size = outAvail; bwr.write_buffer = (uintptr_t)mOut.data();//在bwr中填写需要read的数据请求 // This is what we'll read. if (doReceive && needRead) { bwr.read_size = mIn.dataCapacity(); bwr.read_buffer = (uintptr_t)mIn.data(); } else { bwr.read_size = 0; bwr.read_buffer = 0; } IF_LOG_COMMANDS() { TextOutput::Bundle _b(alog); if (outAvail != 0) { alog << "Sending commands to driver: " << indent; const void* cmds = (const void*)bwr.write_buffer; const void* end = ((const uint8_t*)cmds)+bwr.write_size; alog << HexDump(cmds, bwr.write_size) << endl; while (cmds < end) cmds = printCommand(alog, cmds); alog << dedent; } alog << "Size of receive buffer: " << bwr.read_size << ", needRead: " << needRead << ", doReceive: " << doReceive << endl; } // Return immediately if there is nothing to do. if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;//如果既不需要发送数据,又不需要读取数据;直接返回 bwr.write_consumed = 0;//write_consumed表明驱动消耗的数据量 bwr.read_consumed = 0;//read_consumed表明我们读取到的数据量 status_t err; do { IF_LOG_COMMANDS() { alog << "About to read/write, write size = " << mOut.dataSize() << endl; }#if defined(__ANDROID__) if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0) err = NO_ERROR; else err = -errno;#else err = INVALID_OPERATION;#endif if (mProcess->mDriverFD <= 0) { err = -EBADF; } IF_LOG_COMMANDS() { alog << "Finished read/write, write size = " << mOut.dataSize() << endl; } } while (err == -EINTR); IF_LOG_COMMANDS() { alog << "Our err: " << (void*)(intptr_t)err << ", write consumed: " << bwr.write_consumed << " (of " << mOut.dataSize() << "), read consumed: " << bwr.read_consumed << endl; } if (err >= NO_ERROR) {//Parcel::mDataSize表明当前Parcel中已有的数据量 if (bwr.write_consumed > 0) {//如果驱动程序只是消耗了部分数据,则从mOut中移除那部分 if (bwr.write_consumed < mOut.dataSize()) mOut.remove(0, bwr.write_consumed); else mOut.setDataSize(0);//否则数据全部消耗完,数据设置为0 } if (bwr.read_consumed > 0) {//从驱动读取到了数据,设置mIn中的数据量大小 mIn.setDataSize(bwr.read_consumed); mIn.setDataPosition(0);//mDataPos是当前已处理过的数据量,此时为0 } IF_LOG_COMMANDS() { TextOutput::Bundle _b(alog); alog << "Remaining data size: " << mOut.dataSize() << endl; alog << "Received commands from driver: " << indent; const void* cmds = mIn.data(); const void* end = mIn.data() + mIn.dataSize(); alog << HexDump(cmds, mIn.dataSize()) << endl; while (cmds < end) cmds = printReturnCommand(alog, cmds); alog << dedent; } return NO_ERROR; } return err;}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 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驱动的请求创建并加入到线程池的{ 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，表示不再接收数据}status_t IPCThreadState::getAndExecuteCommand(){ status_t result; int32_t cmd; result = talkWithDriver();//向Binder驱动发送数据/接收reply数据 if (result >= NO_ERROR) { size_t IN = mIn.dataAvail();//有没有可读数据 if (IN < sizeof(int32_t)) return result; cmd = mIn.readInt32();//如果有,先读取一个cmd,看下是执行哪些操作 IF_LOG_COMMANDS() { alog << "Processing top-level Command: " << getReturnString(cmd) << endl; } pthread_mutex_lock(&mProcess->mThreadCountLock); mProcess->mExecutingThreadsCount++; if (mProcess->mExecutingThreadsCount >= mProcess->mMaxThreads && mProcess->mStarvationStartTimeMs == 0) { mProcess->mStarvationStartTimeMs = uptimeMillis(); } pthread_mutex_unlock(&mProcess->mThreadCountLock); result = executeCommand(cmd);//执行cmd pthread_mutex_lock(&mProcess->mThreadCountLock); mProcess->mExecutingThreadsCount--; if (mProcess->mExecutingThreadsCount < mProcess->mMaxThreads && mProcess->mStarvationStartTimeMs != 0) { int64_t starvationTimeMs = uptimeMillis() - mProcess->mStarvationStartTimeMs; if (starvationTimeMs > 100) { ALOGE("binder thread pool (%zu threads) starved for %" PRId64 " ms", mProcess->mMaxThreads, starvationTimeMs); } mProcess->mStarvationStartTimeMs = 0; } pthread_cond_broadcast(&mProcess->mThreadCountDecrement); pthread_mutex_unlock(&mProcess->mThreadCountLock); // After executing the command, ensure that the thread is returned to the // foreground cgroup before rejoining the pool. The driver takes care of // restoring the priority, but doesn't do anything with cgroups so we // need to take care of that here in userspace. Note that we do make // sure to go in the foreground after executing a transaction, but // there are other callbacks into user code that could have changed // our group so we want to make absolutely sure it is put back. set_sched_policy(mMyThreadId, SP_FOREGROUND); } return result;}ProcessState::self()->startThreadPool()主要就是创建了一个子线程用于接收、处理驱动的数据；最后，也将当前主线程加入到了线程池中，用于处理来自驱动的数据。这也表明Binder设备的通信是支持多线程技术的。
PS：Binder图示源文件下载
更多相关文章
- “罗永浩抖音首秀”销售数据的可视化大屏是怎么做出来的呢？
- Nginx系列教程（三）| 一文带你读懂Nginx的负载均衡
- 不吹不黑！GitHub 上帮助人们学习编码的 12 个资源，错过血亏...
- [置顶] android 跨进程通信
- android launcher之检测应用程序图标在桌面是否存在
- android中的设计模式--观察者模式
- Android(安卓)如何自定义一个ContentProvider
- Jetpack: ViewModelSavedState遇到的问题
- Android的活动介绍