Binder是Android 提供的IPC通信方式之一，也無疑是最重要的通信方式之一。整個Android框架處處可以見到Binder的身影。
下圖畫出了Binder從Java到native層的框架：
在native層BBinder承擔着Service的功能，而Bpbinder實現的是proxy的功能。IBinder的內部類DeathRecipient起死亡通知的作用。每一個Service都繼承自BBinder，每一個BBinder的地址都保存在驅動層，並在驅動層有對應的node。Bpbinder對應於驅動層的一個 node reference，通過此reference可以找打對應的node，從而實現Bp端到Bn端的通信。
整個通信流程爲：
1.native層的Bpbinder將IPC函數調用所需的code和param打包，傳遞到驅動層。驅動層通過Bpbinder傳遞下來的handle找到對應的binder node，然後將這些參數copy到node所對應進程的共享內存。之後喚醒等待線程，然後讀取這些參數，把參數傳遞給BBinder。從而實現了代理端到service端的參數傳遞。
2.BBinder的subclass JavaBBinder位於JNI層。當BBinder的虛函數onTransact被調用的時候，實際上調用的是JavaBBinder的onTransact（……）函數。而JavaBBinder的member中保存了Java層的binder對象的全局引用，通過反射調用這個全局引用所對應的binder對象的execTransact（……）函數。從而實現了native層到Java層的通信。
3.Java層的BBinder再調用其subclass的onTransact函數，真正的處理就在其subclass中得到處理。
注意：當A進程中的BBinder傳遞到B進程中，B獲得的是一個Bpbinder對象。當B進程把這個Bpbinder傳遞迴A進程的時候，A獲得的是BBinder。這是因爲驅動層做了檢測，當傳遞的handle（Bpbinder在驅動層對應一個handle）所對應的node所在的進程與目的進程相同的時候，handle會被替換爲node，這樣在從B傳遞一個Bpbinder到A進程的時候，A進程獲得的將會是一個BBinder對象。