自己对Binder的理解

数据结构：
binder_proc
binder_thread
binder_node
binder_transaction
binder_ref
binder_write_read
binder_transaction_data
flat_binder_object
具体细节，不是特别理解。下面描述一下自己的理解。从网上看别人博客，也只能理解到这了，再想深入，只能自己补充linux知识，自己分析源码了。这早晚都是必走的一条路，不如早开始。
client,server,servicemanager都运行在用户空间：
IPCThreadState每个线程都有一个对象。负责和Binder驱动打交道。
BpBinder包含一个引用号，引用号指向对应的binder_ref，binder_ref指向binder_node。binder_node中有BBinder在用户空间的地址。真正承载数据的传输结构是binder_transaction_data。传输业务函数的code,binder引用号，以及binder实体和binder引用实体，但是这两者要“打扁”成flat_binder_object。
Binder驱动运行在内核态：
binder驱动为每个进程，建立一个binder_proc，它主要有三部分组成。
进程内的binder_thread,binder_node,binder_ref。binder_ref有指针指向binder_node。binder驱动拿到用户进程的数据后，组成binder_transaction放入，目的进程或目的线程的todo队列。
binder驱动什么时候创建这些节点呢？
它遵循没有就创建的原则。binder驱动对ServiceManager有特殊处理，每个进程的0是ServiceManager的引用号。
1.client向smgr注册服务时，传输binder实体，Binder驱动解析到binder实体后，在内核空间对应的binder_proc中，建立binder_node节点。并在目的进程binder_proc中添加一个binder_ref节点，引用号返回给目的进程。此时目的进程是ServiceManager进程。
2.client向smgr请求service的代理时，client线程一般挂起等待回复。smgr封装一个bider_ref返回给binder驱动。驱动如果发现client的binder_proc中没有对应引用，新建一个,放入binder_node的信息。返回给client引用号。
3.Binder驱动管理用户进程中的binder线程的消亡。创建、销毁Binder线程，用户进程都要与Binder驱动交互。
这就是对binder驱动一般性的理解了。