通信过程：
binder设备驱动会为每个进程分配一个数据结构binder_proc，每进程中的每个用到了binder通信的线程分配数据结构binder_thread。
binder设备驱动会为服务进程中的每个服务对象分配数据结构binder_node，它隶属于服务进程的binder_proc，即binder_node是binder_proc的子结构，binder_node中记录了服务对象在服务进程中的地址；会为客户进程中每个引用分配binder_ref，binder_ref会指向客户进程引用的服务对象的binder_node。
binder驱动为客户进程每个引用都会维护一个handle，它存在于binder_ref中（binder_ref.desc），它就像进程打开某个文件产生的文件描述符一样，进程每引用一个服务，就会分配一个最小未使用的整数作为handle。handle是客户进程相关的，多个进程引用同一个服务得到的handle并不是一样的。
当服务进程向ServiceManager注册服务时，会带上服务的名称字符串，驱动会为服务进程中的服务对象增加一个binder_node，归属于服务进程的binder_proc。
当把注册服务的请求发给ServiceManager时，ServiceManager也是服务对象的一个引用者，驱动会为ServiceManager增加一个binder_ref，指向服务对象的binder_node。驱动把binder_ref.desc（ServiceManager）作为handle返回给ServiceManager，ServiceManager保存此handle和服务名称字符串。
当客户进程向ServiceManager获取服务时，ServiceManager根据服务名称字符串找到服务对象在ServiceManager进程中的handle。在ServiceManager的应答的过程中，驱动根据此handle在ServiceManager进程的binder_proc找到对应的binder_ref，并根据它找到服务对象的binder_node。然后，驱动会为客户进程增加一个binder_ref，指向服务对象的binder_node，最后把binder_ref.desc（客户进程）作为handle返回给客户进程。
客户进程使用得到的handle向服务进程发起请求，驱动会在根据此handle在客户进程的binder_proc查找对应的binder_ref，并找到它指向的binder_node，并找到binder_node所属的binder_proc，最终驱动把请求放入服务进程的接收队列中。
服务进程收到请求后，从binder_node中找到服务对象的地址，然后调用该服务对象。所以，对于服务对象，在客户进程中表现出来的是handle，在服务进程中表现出来的是地址，驱动会对它们进行映射。