文章仅仅用于个人的学习记录，基本上内容都是网上各个大神的杰作，此处摘录过来以自己的理解学习方式记录一下。 个人最为认可和推崇的大神文章： http://blog.csdn.net/luoshengyang/article/details/6618363 罗升阳Binder系列文章 http://blog.csdn.net/innost/article/details/47208049 Innost的Binder讲解
https://my.oschina.net/youranhongcha/blog/149575 侯 亮的Binder系列文章.
1、ProcessState
它被设计成单例模式，因此一个进程只会走一次它的构造，这也间接导致了只会打开一次binder设备(某一个server端.) 而当调用ProcessState::self()的时候就会调用.
ProcessState::ProcessState() //构造 : mDriverFD(open_driver())//在初始化列表时打开驱动. , mVMStart(MAP_FAILED) , mManagesContexts(false) , mBinderContextCheckFunc(NULL) , mBinderContextUserData(NULL) , mThreadPoolStarted(false) , mThreadPoolSeq(1) { if (mDriverFD >= 0) { // mmap the binder, providing a chunk of virtual address space to receive transactions. //把设备文件映射到进程的虚拟地址空间.第一个好处，可以直接读写。 //BINDER_VM_SIZE = ((1*1024*1024) - (4096 *2)) 1M-8K mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0); if (mVMStart == MAP_FAILED) { //...... } #else mDriverFD = -1; #endif } //...... } ProcessState中另一个比较有意思的域是mHandleToObject，在.h文件中Vector<handle_entry>mHandleToObject声明.它是本进程中记 录所有BpBinder的向量表，非常重要.在Binder架构中，应用进程是通过“binder句柄”来找到对应的BpBinder的。从这张向量表中我们可 以看 到，那个句柄值其实对应着这个向量表的下标.
struct handle_entry { IBinder* binder; RefBase::weakref_type* refs; }; 其中binder域记录的就是BpBinder对象. 2、IPCThreadState最终和Binder驱动打交道的地方，它是线程单例，存到了线程的本地存储区域. 由于 IPCThreadState的构造函数的声明如下，是在private下面声明的所以其它类不能实例化它，但是可以通过self()方法 来得到它的实例。 private: IPCThreadState(); ~IPCThreadState();
IPCThreadState* IPCThreadState::self() { if (gHaveTLS) {//第一次进来为false restart: const pthread_key_t k = gTLS; //TLS是Thread Local Storage的意思.线程本地存储的意思(C层实现的和java层的ThreadLocal类一样)， //有pthread_getspecific,那么肯定有地方调用 pthread_setspecific。 IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k); if (st) return st; return new IPCThreadState; } //...... } 构造：函数如下，需要特别关注的由mProcess私有变量的初始化问题，此变量标记了当前线程输入那个进程，并且通过 ProcessState的self方法拿到这个单例模式的ProcessState的变量，就可以拿到在实例化时候打开binder设备时返回 的文件描述符fd了，其实最终IPCThreadState还是通过这个fd通过ioctl机制来和设备驱动文件通信。
IPCThreadState::IPCThreadState() : mProcess(ProcessState::self()),//很关键！！！ mMyThreadId(androidGetTid()), mStrictModePolicy(0), mLastTransactionBinderFlags(0) { pthread_setspecific(gTLS, this);//在构造中这个存入本地存储区.保证每个线程有自己的IPCThreadState. clearCaller(); mIn.setDataCapacity(256); mOut.setDataCapacity(256); } 2.1、 IPCThreadState中的client端发出请求和驱动交互的大体流程： 一般在代理端如BpServiceManager的addservice调用时，本身代理端是没有通信机制的它还是要靠BpBinder来操作， 所以都会获得一个mRemote，这是一个BpBinder对象然后调用它的 transact()方法传入指定的命令 code,更具code驱动会做 出反应。
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) { //当是一个service通过service manager 调用addservice，然后到这里的时候. //这里的mHandle为0，code为ADD_SERVICE_TRANSACTION。ADD_SERVICE_TRANSACTION是上面以参数形式传进来的， //那mHandle的只是由前面实例化BpBinder传入的值决定的，一般在如：BpXXXX : public BpInterface<XXX> //而在实例化BpXXX的时候构造中都会需要传入一个IBinder对象，在跨进程调用的时候这个对象就是此处的BpBinder //传入这个BpBinder的时候由于模板类BpInterface就会去实例化BpRefBase最终实例化这个BpBinder的相关变量. status_t status = IPCThreadState::self()->transact( mHandle, code, data, reply, flags); if (status == DEAD_OBJECT) mAlive = 0; return status; } return DEAD_OBJECT; } 可以看出BpBinder最终是调用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(); //IPCThreadState::transact函数的参数flags ==0 ，这是因为在BpBinder中默认参数列表传入的0. flags |= TF_ACCEPT_FDS;//TF_ACCEPT_FDS = 0x10 ,binder.h linux中
//......
if (err == NO_ERROR) { //准备好一个struct binder_transaction_data结构体变量，这个是等一下要传输给Binder驱动程序的数据. //这里就是发送数据的地方.把它的handle，code，data封装好然后写入到IPCThreadState的mOut中 err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL); } //...... //如果没有设置TF_ONE_WAY这个置也就是需要回复。 if ((flags & TF_ONE_WAY) == 0) {//0x10&0x01确实会进入. //...... //等待回复，如果reply可以用就直接用，否则自己新建一个. if (reply) { err = waitForResponse(reply); } else { Parcel fakeReply; err = waitForResponse(&fakeReply); } //...... } else { //不需要回复的时候会走到这里. err = waitForResponse(NULL, NULL); } return err; } 可以看到在IPCThreadState的 transact方法中主要有两步，第一步把要传输的数据封装成 binder_transaction_data的结构 体（就是要这么定义，也方便驱动那别解析啊，大家都按照这种来）然后写入到Parcel mOut当中，这个就是当前的IPCThrea d State要往驱动中传入的序列化的数据.第二步就是真正通过ioctl要和驱动去交流的地方在 waitForResponse当中.
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传输过程中的数据.
//这个结构体的初始化设置.
tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process */ tr.target.handle = handle; tr.code = code;//注意！！！！这个code会存入到封装的binder_transaction_data结构体当中!!!!!注意和cmd的区别 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(); //data.ipcData();就相当于. //writeInt32(IPCThreadState::self()->getStrictModePolicy() | STRICT_MODE_PENALTY_GATHER); //writeString16("android.os.IServiceManager"); //writeString16("media.player"); //writeStrongBinder(new MediaPlayerService()); tr.data.ptr.buffer = data.ipcData();
//真正要传输的数据保存的地方.
tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);
//记录一下偏移量.
tr.data.ptr.offsets = data.ipcObjects(); } else if (statusBuffer) { //...... } else { return (mLastError = err); } //Parcel mOut 往驱动发送的数据最终都存入到mOut. mOut.writeInt32(cmd);//cmd为BC_TRANSACTION直接存入到mOut当中，在binder_thread_write方法中读取. mOut.write(&tr, sizeof(tr)); return NO_ERROR; } 注意此处写入的cmd不要和一开始从BpXXXX传入的code弄混了，这个cmd就是和binder设备文件进行ioctl的时候的命令 码，在驱动的实现中又具体的定义.此处的 writeStrongBinder也十分的关键后面再分析.接下来看一下 waitForResponse。
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult) { int32_t cmd; int32_t err; while (1) { //
最后bwr.write_size和bwr.read_size均为0，IPCThreadState::talkWithDriver函数什么也不做，返回到IPCThreadState::waitForResponse函
中
//
在IPCThreadState::waitForResponse函数，又继续从mIn读出一个整数，这个便是BR_TRANSACTION_COMPLETE.
//
进入到Binder驱动程序中的binder_ioctl函数中。由于bwr.write_size为0，bwr.read_size不为0，这次
直接就进入到binder_thread_read //函数中。这时候，
//thread->transaction_stack!=0,thread-
>todo为空,线程通过:
wait_event_interruptible(thread->wait, binder_has_thread_work(thread))
//进入睡眠状态，等待Service Manager来唤醒了。(！！！！反正最终又是要等待Service Manager来唤醒，注意此时Service Manager已经被唤醒)
//主要调用了talkWithDriver函数来与Binder驱动程序进行交互 if ((err=talkWithDriver()) < NO_ERROR) break; //从驱动返回以后，这里开始操作mIn了，看来talkWithDriver中把mOut发出去，然后从driver中读到数据放到mIn中了。 err = mIn.errorCheck();//addservice时候，mIn读出一个整数，这个便是BR_NOOP了，这是一个空操作，什么也不做。 if (err < NO_ERROR) break; if (mIn.dataAvail() == 0) continue; cmd = mIn.readInt32();//取出来驱动放入的命令. //...... 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: //...... return err; } 此时我们主要关注的是往驱动发出的时候的事情，那么此时就是去调用 talkWithDriver.一定要注意那个mProcess的成员变 量mDriverFD,最终是通过，这个fd和binder设备文件交互. binder_write_read这个结构体用来进一步的封装和驱动交互的数据 结构。通过下面可见最终还是通过ioctl来和binder驱动进行交互.Binder驱动收到后根据不同的cmd做出不同的处理.
status_t IPCThreadState::talkWithDriver(bool doReceive) { if (mProcess->mDriverFD <= 0) { return -EBADF; } // binder_write_read是用来与Binder设备交换数据的结构, binder_write_read bwr;//来换传入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_size = outAvail; bwr.write_buffer = (uintptr_t)mOut.data();//!!!非常重要，看出来把前面的cmd和
binder_transaction_data放入到了buffer
// This is what we'll read. if (doReceive && needRead) { //接收数据缓冲区信息的填充。如果以后收到数据，就直接填在mIn中了。 bwr.read_size = mIn.dataCapacity(); bwr.read_buffer = (uintptr_t)mIn.data(); } else { bwr.read_size = 0; bwr.read_buffer = 0; }
//......
// Return immediately if there is nothing to do. status_t err; do { //...... #if defined(HAVE_ANDROID_OS) //看来不是read/write调用去和Binder设备文件进行通信，而是ioctl方式。 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; } //...... } while (err == -EINTR);//应该是只要有数据就会一直循环的往外发送，通过ioctl的返回值判断的.
//......
if (err >= NO_ERROR) { //到这里从驱动中回来了，回复数据就在bwr中了，bmr接收回复数据的buffer就是mIn提供的 if (bwr.write_consumed > 0) { if (bwr.write_consumed < mOut.dataSize()) mOut.remove(0, bwr.write_consumed); else mOut.setDataSize(0);//从驱动回来以后，首先是把mOut的数据清空.方便下一次操作啊. } if (bwr.read_consumed > 0) { mIn.setDataSize(bwr.read_consumed);//然后设置已经读取的内容的大小. mIn.setDataPosition(0); } //...... return NO_ERROR; } //然后就返回到了waitForResponse当中.我们去看一下. //在addservice流程中到这里，我们发送addService的流程就彻底走完了。 return err; } 此处一定要注意bwr算是又进行了一层的封装，把 binder_transaction_data和cmd等放入mOut当中的数据通过： bwr.write_buffer = (uintptr_t)mOut.data()、bwr.read_buffer = (uintptr_t)mIn.data()等放入到了binder_write_read结构体的对应的buffer缓冲区中。
3、 ProcessState::self()->startThreadPool()和 IPCThreadState::self()->joinThreadPool()两个操作. 3.1、 ProcessState:: startThreadPool方法.
void ProcessState::startThreadPool() { AutoMutex _l(mLock); if (!mThreadPoolStarted) { mThreadPoolStarted = true; spawnPooledThread(true); } } 可以看到就是调用了spawnPooledThread(true).
void ProcessState::spawnPooledThread(bool isMain) { if (mThreadPoolStarted) { String8 name = makeBinderThreadName(); ALOGV("Spawning new pooled thread, name=%s\n", name.string()); //创建线程池，然后run起来，和java的Thread何其像也。 sp<Thread> t = new PoolThread(isMain);//会去实例化父类Thread. t->run(name.string());//调用PoolThread::run，实际调用了父类Thread的run } } Thread的run函数最终调用子类的threadLoop函数，这里即为PoolThread::threadLoop函数：
virtual bool threadLoop() { //此时mIsMain为true. IPCThreadState::self()->joinThreadPool(mIsMain); return false; } 可以看到此处也是调用 IPCThreadState::self()->joinThreadPool().一般在native层的标准调用： ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); 它们的区别是，这里的参数isMain都是等于true，表示是应用程序自己主动创建的Binder线程，而不是Binder驱动程序请求应用程序创 建的.接下来看看 IPCThreadState:: joinThreadPool()的实现.
注意它在. h的声明文件中void joinThreadPool(bool isMain = true) 默认的参数是true.
void IPCThreadState::joinThreadPool(bool isMain) { mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER); set_sched_policy(mMyThreadId, SP_FOREGROUND); status_t result; do {//进入到这个循环中. processPendingDerefs(); // now get the next command to be processed, waiting if necessary result = getAndExecuteCommand();//去里面读取 if (result < NO_ERROR && result != TIMED_OUT && result != -ECONNREFUSED && result != -EBADF) { ...... } // 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); ...... mOut.writeInt32(BC_EXIT_LOOPER); talkWithDriver(false); } 函数最终是在一个无穷循环中，通过调用talkWithDriver函数来和Binder驱动程序进行交互，实际上就是调用 talkWithDriver来等待Client 的请求，然后调用executeCommand来处理请求，而在getAndExecuteCommand 函数中，最终会调 用BBinder::transact来真正处理Client的 请求.
status_t IPCThreadState::getAndExecuteCommand() { status_t result; int32_t cmd; result = talkWithDriver(); if (result >= NO_ERROR) { size_t IN = mIn.dataAvail(); if (IN < sizeof(int32_t)) return result; cmd = mIn.readInt32(); IF_LOG_COMMANDS() { alog << "Processing top-level Command: " << getReturnString(cmd) << endl; } result = executeCommand(cmd); // 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; } 可以看到就是调用到executeCommand(int cmd )
status_t IPCThreadState::executeCommand(int32_t cmd) { BBinder* obj; RefBase::weakref_type* refs; status_t result = NO_ERROR; switch (cmd) { ...... default: printf("*** BAD COMMAND %d received from Binder driver\n", cmd); result = UNKNOWN_ERROR; break; } if (result != NO_ERROR) { mLastError = result; } return result; } 它会走到case为：BR_TRANSACTION当中，我们单独提取出来分析.
case BR_TRANSACTION: //Binder通信 { binder_transaction_data tr; result = mIn.read(&tr, sizeof(tr)); ALOG_ASSERT(result == NO_ERROR, "Not enough command data for brTRANSACTION"); if (result != NO_ERROR) break; Parcel buffer; buffer.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); const pid_t origPid = mCallingPid; const uid_t origUid = mCallingUid; const int32_t origStrictModePolicy = mStrictModePolicy; const int32_t origTransactionBinderFlags = mLastTransactionBinderFlags; mCallingPid = tr.sender_pid; mCallingUid = tr.sender_euid; mLastTransactionBinderFlags = tr.flags; int curPrio = getpriority(PRIO_PROCESS, mMyThreadId); if (gDisableBackgroundScheduling) { if (curPrio > ANDROID_PRIORITY_NORMAL) { // We have inherited a reduced priority from the caller, but do not // want to run in that state in this process. The driver set our // priority already (though not our scheduling class), so bounce // it back to the default before invoking the transaction. setpriority(PRIO_PROCESS, mMyThreadId, ANDROID_PRIORITY_NORMAL); } } else { if (curPrio >= ANDROID_PRIORITY_BACKGROUND) { // We want to use the inherited priority from the caller. // Ensure this thread is in the background scheduling class, // since the driver won't modify scheduling classes for us. // The scheduling group is reset to default by the caller // once this method returns after the transaction is complete. set_sched_policy(mMyThreadId, SP_BACKGROUND); } } //ALOGI(">>>> TRANSACT from pid %d uid %d\n", mCallingPid, mCallingUid); //前面是来了一个命令，解析成BR_TRANSACTION,然后读取后续的信息 Parcel reply; status_t error; IF_LOG_TRANSACTIONS() { TextOutput::Bundle _b(alog); alog << "BR_TRANSACTION thr " << (void*)pthread_self() << " / obj " << tr.target.ptr << " / code " << TypeCode(tr.code) << ": " << indent << buffer << dedent << endl << "Data addr = " << reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer) << ", offsets addr=" << reinterpret_cast<const size_t*>(tr.data.ptr.offsets) << endl; } if (tr.target.ptr) { sp<BBinder> b((BBinder*)tr.cookie);//看来这个binder_transaction_data.cookie很关键啊！！！！！！！！ error = b->transact(tr.code, buffer, &reply, tr.flags); } else { /* the_context_object是IPCThreadState.cpp中定义的一个全局变量， 可通过setTheContextObject函数设置 */ 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; 接下来再看一下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);//就是调用自己的onTransact函数嘛,谁实例化的就调用谁！ break; } if (reply != NULL) { reply->setDataPosition(0); } return err; } 然后会调用到子类的onTransact函数来处理. PCThreadState接收到了Client处的请求后，就会调用BBinder类的transact函数，并传入相关参数，BBinder类的transact函数最终调 用BnMediaPlayerService类的onTransact函数，于是，就开始真正地处理Client的请求 .
![这一次,binder真正理解了(二) -----ServiceManager启动ServiceManager 启动binder原理概述ServiceManager[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)