Android -- IPC通信机制之一Binder简介

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()实现：

//参数传入是NULL
sp 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()函数是一个重要的模板函数，它定义IServiceManager.h中：

/*
一个模板函数

当INTERFACE为IServiceManager时，整个函数定义就是:

template
inline sp interface_cast(const sp& obj)
{
    return IServiceManager::asInterface(obj);
}
实际调用IServiceManager::asInterface(obj)函数
*/

template
inline 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图示源文件下载