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对象。