引言：

对于Android系统，一般是从java层到native层，再到kernel驱动层，形成一个完整的软件架构。Android系统中的Binder IPC通信机制的整体架构，从java层到底层驱动层是怎么样的一个架构和原理的呢？

概念与理解

Binder整体架构

图中红色代表整个Java层 binder架构相关组件：
Binder类代表Server端，BinderProxy类代码Client端；
图中蓝色代表Native层Binder架构相关组件；
上层Java层的Binder逻辑是建立在Native层架构基础之上的，核心逻辑都是交予Native层方法来处理。
java层中framework层的ServiceManager类与Native层的功能并不完全对应，framework层的ServiceManager类的实现最终是通过BinderProxy传递给Native层来完成的

Binder类图

图中浅蓝色都是Interface，其余都是Class：

ServiceManager：通过getIServiceManager方法获取的是ServiceManagerProxy对象； ServiceManager的addService, getService实际工作都交由ServiceManagerProxy的相应方法来处理；
ServiceManagerProxy：其成员变量mRemote指向BinderProxy对象，ServiceManagerProxy的addService, getService方法最终是交由mRemote来完成。
ServiceManagerNative：其方法asInterface()返回的是ServiceManagerProxy对象，ServiceManager便是借助ServiceManagerNative类来找到ServiceManagerProxy；
Binder：其成员变量mObject和方法execTransact()用于native方法
BinderInternal：内部有一个GcWatcher类，用于处理和调试与Binder相关的垃圾回收。
IBinder：接口中常量FLAG_ONEWAY：客户端利用binder跟服务端通信是阻塞式的，但如果设置了FLAG_ONEWAY，这成为非阻塞的调用方式，客户端能立即返回，服务端采用回调方式来通知客户端完成情况。另外IBinder接口有一个内部接口DeathDecipient(死亡通告)。

Binder类分层

整个Binder从kernel至，native，JNI，Framework层所涉及的全部类

源码走读：

 注册服务：

获取服务：