Binder机制，从Java到C （10. Binder驱动）

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了。