Binder驱动的代码都在kernel里面，这里就简单讲一下里面涉及到的几个东西：
1.Memory
Binder其实本质上就是一中数据传输方式，这种方式是通过binder driver实现的。
我们知道其他的一些IPC的方法，在传递数据的时候，一般都会有两次拷贝，发送者拷贝到底层，底层再拷贝给接收者。
但是Binder通过共享內存进行通信，只有一次copy。
看下面的图中，每个涉及到Binder通信的进程，都会有一个共享内存，它是binder驱动和进程之间的共享内存。但是进程是无法对内存进行写操作的，是只读的。
Process A向Process B传递数据時，这些数据会被driver从ProcessA copy 到 binder和ProcessB之间的共享內存中。ProcessB已经映射过地址，就可以直接读取内存里面的数据了，就不需要再做一次拷贝动作了
在ProcessState初始化的时候，就会调用mmap()去映射地址。
./frameworks/native/libs/binder/ProcessState.cpp
ProcessState::ProcessState()
: mDriverFD(open_driver())
, ….
{
if (mDriverFD >= ) {
mVMStart = mmap(, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, );
...
}
}
2.binder_ref / binder_node
我们拿到一个代理对象，通过binder驱动来调用远程的服务，那Binder到底是如何根据代理对象找到实体對象的呢？
其实Binder驱动会在内核为process创建一個binder_proc 结构提，在binder_proc中保存着四个RB Tree。
其中三个tree就是保存binder_ref和binder_node的。就是传递来传递去的代理对象和实体对象。
一个tree保存binder_node；另外两个tree保存binder_ref,这两个tree的内容其实都一样，只是为了便于搜索，就建了两个不同key的tree。
这三个tree都具体存写什么东西？
-->这样说，一个process里有个实体对象，就有多少个binder_node；一个process有多少个代理对象指向远端，就有多少个binder_ref.
看下面的图中：
ProcessA向binder驱动传入一个handle，binder驱动就会根据handle在tree中找到对应的binder_ref。 binder_ref里面有一个node变量， 它就是对应的实体对象的node的地址，靠它找到对应的binder_node。然后在binder_node里面，也有一个变量：cookie，它就是BBinder的地址。找到BBinder就OK了。