这篇博文其实就是想简单的来记录下Binder驱动在Android中的重要性，早在2012年的时候就按着2.3的源码深入学习过Binder驱动的底层实现（Android之binder驱动个人学习小结），Binder驱动主要是android为了构建C/S的通信模型而量身定做的，没有过多复杂的协议，一个Parcl基本包含了所要传递的所有信息，本文就对FrameWork从运用到的Binder机制做一个模型的总结。
还是先把Android的Binder驱动架构提炼出来先，如下图所示是典型的CS架构，和Binder驱动密切相关的结构体包括BBinder、BpBinder、BpRefBase：
一个基于Binder的驱动架构，一般的实现过程分为如下几部：
先来看下Binder架构下涉及的一般类图布局会如下所示
基于以上Android的类，我们构建的Ixxx定义整个通信的接口函数，主要由Bpxxx来实现但主要是进行命令字与数据的打包传输，然后远程链接到本地的Bnxxx进行业务的解析与处理。一般需要构建2个文件：Ixxx.h，Ixxx.cpp.
在Ixxx.h内部申请Ixxx接口类，以及类Bnxxx的申明，一般该类只对应一个成员函数即OnTransact；在Ixxx.cpp中主要实现类Bpxxx的申明以及对Ixxx的接口函数进行实现，其核心是调用BpBinder来实现的。
理解Binder最好的方式是ServiceManager，一般以BnxxxService命名服务，都会向其进行服务的注册，而BpxxxClient是直接通过和SM在客户端的代理来获取BnxxxService在本地的代理。
其实按照我个人的理解，Bpxxx和Bnxxx更好的理解是2个进程间的通信，当然作为Service和Client是最好的使用方式。比如先前通过一个客户端的BpxxxClient发出一个请求建立一个Client处的Bpxxx接口，相应的在服务端也就存在着Bnxxx的实现函数，故而这两者之间就可以实现正常的通讯，当然Bnxxx不在是以服务的形象存在与SM中，只是简单的实现进程、线程间的通信而已。
下面将从一个SurfaceFlinger进程的启动到Binder驱动的操作，以及Bnxxx和Bpxxx的通信来简单介绍。
step1: Binder驱动的open和mmap过程
int main(int argc, char** argv) {
SurfaceFlinger::publishAndJoinThreadPool(true);
// When SF is launched in its own process, limit the number of
// binder threads to 4.
ProcessState::self()->setThreadPoolMaxThreadCount(4);
return 0;
}
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState;
return gProcess;
}
ProcessState作为一个进程中唯一的变量（所谓的单列模式），他是真正和Binder驱动打交道的地方所在
ProcessState::ProcessState()
: mDriverFD(open_driver())
, mVMStart(MAP_FAILED)
, 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.
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
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.");
}
上述的构造函数主要完成Binder驱动的打开已经mmap的操作。
step2:Binder驱动的交互主要是接收其他的客户端请求
void ProcessState::startThreadPool()
{
AutoMutex _l(mLock);
if (!mThreadPoolStarted) {
mThreadPoolStarted = true;
spawnPooledThread(true);
}
}
void IPCThreadState::joinThreadPool(bool isMain)
{
talkWithDriver();
executeCommand();
}
在这里是通过获取和binder驱动的交互，得到待处理的信息后进行executeCommand的执行，该函数其实内部就是找到对应的本地的BBinder来执行他的transact，而通过上图的继承关系可知，一般就直接有Bnxxx的Ontransact来解析完成，如下所示;
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;
}
step3: 作为客户端是如何发送相关消息的
当你在Client有了对应的proxy后，直接操作的就是BpBinder的相关内容，我们常常见到的remote->(xxx)其实内部的实现是这样的：
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);
if (status == DEAD_OBJECT) mAlive = 0;
return status;
}
return DEAD_OBJECT;
}
可以看到是一个IPCThreadState在和帮助者你，再看他的transaction：
status_t IPCThreadState::transact(int32_t handle,
uint32_t code, const Parcel& data,
Parcel* reply, uint32_t flags)//数据的发送
{
if (reply) {
err = waitForResponse(reply);//等待服务端的回复
}
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{
status_t IPCThreadState::talkWithDriver(bool doReceive)//和底层走的最近的地方
}
其实无论是Binder的服务端还是客户端，真正的Binder在内核驱动中度会为当前的进程维护一个binder的node树，只有有新的节点产生经过内核驱动后都会记录下来，使得一旦远程的客户通过代理访问时，都是能找到对应的Binder实体，并找个该实体所示的loop服务线程，进行必要的唤醒与处理。最终反馈处理后的数据到客户端，客户端益是从线程的等待到唤醒这个过程来响应相关的处理结果，进行保存。
Binder驱动在下面要介绍的camera和SurfaceFlinger架构中会普遍的用到，所以先在这里总一个最简单的应用方式总结，以便更好的阅读代码。