关于binder

1. Server注册服务。Server作为众多Service的拥有者，当它想向Client提供服务时，得先去Service Manager（以后缩写成SM）那儿注册自己的服务。Server可以向SM注册一个或多个服务。

2. Client申请服务。Client作为Service的使用者，当它想使用服务时，得向SM申请自己所需要的服务。Client可以申请一个或多个服务。

3. 当Client申请服务成功后，Client就可以使用服务了。

1. Client和Server是存在于用户空间

2. Client与Server通信的实现，是由Binder驱动在内核空间实现

3. SM作为守护进程，处理客户端请求，管理所有服务项。

1. 首先，XXXServer(XXX代表某个)在自己的进程中向Binder驱动申请创建一个XXXService的Binder的实体，

2. Binder驱动为这个XXXService创建位于内核中的Binder实体节点以及Binder的引用，注意，是将名字和新建的引用打包传递给SM（实体没有传给SM），通知SM注册一个名叫XXX的Service。

3. SM收到数据包后，从中取出XXXService名字和引用，填入一张查找表中。

4. 此时，如果有Client向SM发送申请服务XXXService的请求，那么SM就可以在查找表中找到该Service的Binder引用，并把Binder引用(XXXBpBinder)返回给Client。

在进一步了解Binder通信机制之前，我们先弄清几个概念。

1. 引用和实体。这里，对于一个用于通信的实体（可以理解成具有真实空间的Object），可以有多个该实体的引用（没有真实空间，可以理解成实体的 一个链接，操作引用就会操作对应链接上的实体）。如果一个进程持有某个实体，其他进程也想操作该实体，最高效的做法是去获得该实体的引用，再去操作这个引 用。

2. 有些资料把实体称为本地对象，引用成为远程对象。可以这么理解：引用是从本地进程发送给其他进程来操作实体之用，所以有本地和远程对象之名。

如果你足够细心，会发现这里有一个问题：

Sm和Server都是进程，Server向SM注册Binder需要进程间通信，当前实现的是进程间通信却又用到进程间通信。这就好比鸡生蛋、蛋生鸡，但至少得先有其中之一。

巧妙的Binder解决思路：

针对Binder的通信机制，Server端拥有的是Binder的实体；Client端拥有的是Binder的引用。
如果把SM看作Server端，让它在Binder驱动一运行起来时就有自己的Binder实体（代码中设置ServiceManager的Binder 其handle值恒为0）。这个Binder实体没有名字也不需要注册，所有的client都认为handle值为0的binder引用是用来与SM通信 的（代码中是这么实现的），那么这个问题就解决了。那么，Client和Server中这么达成协议了（handle值为0的引用是专门与SM通信之用 的），还不行，还需要让SM有handle值为0的实体才算大功告成。怎么实现的呢？！当一个进程调用Binder驱动时，使用 BINDER_SET_CONTEXT_MGR命令（在驱动的binder_ioctl中）将自己注册成SM时，Binder驱动会自动为它创建 Binder实体。这个Binder的引用对所有的Client都为0。

AIDL：在跨进程通信的时候，Client端使用的Poxy里面封装了一个binder与Server端的stub（也是一个binder对象）进行交互，两个binder作为接口调用BinderDriver的transact来发送数据包，以及onTransact接收处理数据包。

AIDL Binder框架分为服务器接口、Binder驱动、以及客户端接口；简单想一下，需要提供一个全局服务，那么全局服务那端即是服务器接口，任何程序即客户端接口，它们之间通过一个Binder驱动访问。

服务器端接口（Stub类）：实际上是Binder类的对象，该对象一旦创建，内部则会启动一个隐藏线程，会接收Binder驱动发送的消息，收到消息后，会执行Binder对象中的onTransact()函数，并按照该函数的参数执行不同的服务器端代码。

Binder驱动：该对象也为Binder类的对象，客户端通过该对象访问远程服务。

客户端接口（调用asInterface方法将服务端的Binder对象转换成客户端所需的AIDL接口对象，如果服务器和客户端处于同一进程返回Stub对象本身，否则返回封装好的Stub类的内部代理类实例Proxy，并传入Binder驱动）：获得Binder驱动，调用其transact()发送消息至服务器