自己對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驅動一般性的理解了。