在上一篇博客中Android源码分析–MediaServer源码分析（一），我们知道了ProcessState和defaultServiceManager，在分析源码的过程中，我们被Android的Binder通信机制中的各种复杂的类关系搞的眼花缭乱，接下来我们就以MediaPlayerService为例来分析一下Binder的通信机制。首先来回顾一下：
BpBinder和BBinder都是Android中Binder通信的代表类，其中BpBinder是客户端用来与Server交互的代理类，p代表的就是proxy，而BBinder则是交互的目的端；BpBinder和BBinder是相互对应的，Binder系统会通过handle来标识对应的BBinder。
Android的通信机制基本上可以看做是Client、Server和ServiceManager三者之间的交互：
注册MediaPlayerService
我们知道若要使用一个Service的话首先要进行注册，所有首先让我们来看看MediaService是如何注册的，文件位置：frameworks\base\media\libmediaplayerservice\MediaPlayerService.cpp
void MediaPlayerService::instantiate() {defaultServiceManager()->addService(String16(“media.player”), new MediaPlayerService());}
defaultServiceManager返回的其实是一个BpServiceManager对象，在这里我看到了注册的函数addService：
virtual status_t addService(const String16& name, const sp<IBinder>& service){Parcel data, reply;//将Descriptor作为令牌.writeStrongBinder(service);status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);return err == NO_ERROR ? reply.readExceptionCode() : err;}
Parcel类可以看作一个数据块，在该类的内部主要封装了一些数据操作的方法。在写入数据之后remote()->transact方法，remote()方法返回的值是mRemote，在上一篇中我们知道它是一个BpBinder对象，之后我们的通信工作就交由了BpBinder的transact方法：
status_t BpBinder::transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){// Binder一旦死去将永远不能复活.if (mAlive) {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类中。
IPCThreadState类分析
IPCThreadState也是以单例模式设计的。由于每个进程只维护了一个ProcessState实例，同时ProcessState只启动一个 Pool thread，也就是说每一个进程只会启动一个Pool thread，因此每个进程则只需要一个IPCThreadState即可。首先让我们来看看这个self方法，文件位置：frameworks\base\libs\binder\IPCThreadState.cpp
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;}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;}
TLS是Thread Local Storage的缩写，表示线程本地存储，类似于Java中的ThreadLocal机制)pthread_getspecific和)pthread_setspecific方法分别提供了设置变量和获取变量的方法。
在这里我们看到了get方法，有get方法就一定有对应的set方法，set的设置就在构造函数中：
IPCThreadState::IPCThreadState(): mProcess(ProcessState::self()),mMyThreadId(androidGetTid()),mStrictModePolicy(0),mLastTransactionBinderFlags(0){pthread_setspecific(gTLS, this);clearCaller();mIn.setDataCapacity(256);mOut.setDataCapacity(256);}
可以看到在构造函数中IPCThreadState将自身和线程本地存储关联起来了，在每一个IPCThreadState中都存在一个mIn和mOut，mIn用来存储接收Binder的数据，mOut用来存储发送到Binder的数据。
接下来看看transact方法：
status_t IPCThreadState::transact(int32_t handle,uint32_t code, const Parcel& data,Parcel* reply, uint32_t flags){status_t err errorCheck();flags |= TF_ACCEPT_FDS;(err == NO_ERROR) {……err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL);}(reply) {err = waitForResponse(reply);} else {Parcel fakeReply;err = waitForResponse(&fakeReply);}……} else {err = waitForResponse(NULL, NULL);}return err;}
在这里省略了一些打印输出信息的语句，在这里我们可以清楚的看到通信的流程：先写入数据，然后等待接收数据。
如何进行通信最美不过偷瞄你是你忽然转头，看见你的微笑
