关于Binder的点点滴滴（一）--实现机制

http://www.linuxidc.com/Linux/2011-07/39271.htm 

Binder使用Client-Server 通信方式：一个进程作为Server提供服务，多个进程作为Client发起服务请求。要想 实现Client-Server通信据必须实现以下两点：一是server 必须有确定的访问接入点或者说地址来接受Client的请求，并且Client可以通过某种途径获知Server的地址；二是制定Command- Reply协议来传输数据。

思想：Binder使用了面向对象的思想来描述作为访问接入点的Binder及其在Client中的入口：Binder是一个实体位于 Server中的对象，该对象提供了一套方法用以实现对服务的请求，就象类的成员函数。遍布于client中的入口可以看成指向这个binder对象的 ‘指针’，一旦获得了这个‘指针’就可以调用该对象的方法访问server。Client通过Binder‘指针’调用其提供的方法。从通信的角度看，Client中的Binder也可以看作是Server Binder的‘代理’，在本地代表远端Server为Client提供服务。

Binder对象是一个可以跨进程引用的对象：面向对象思想将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法---它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。这个引用可以是强类型，也可以是弱类型，而且可以从一个进程传给其它进程，让大家都能访问同一Server，就象将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。形形色色的Binder对象以及星罗棋布的引用仿佛粘接各个应用程序的胶水，这也是Binder 在英文里的原意。

通信模型：Binder框架定义了四个角色：Server，Client，ServiceManager（SMgr）以及驱动。其中 Server，Client，SMgr运行于用户空间，驱动运行于内核空间。这四个角色的关系和互联网类似：Server是服务器，Client是客户终端，SMgr是域名服务器（DNS），驱动是路由器。

Binder驱动是通信的核心。他和硬件设备没有任何关系，只是实现方式和设备驱动程序是一样的：它工作于内核态，提供open()，mmap()，poll()，ioctl()等标准文件操作，以字符驱动设备中的misc设备注册在设备目录 /dev下，用户通过/dev/binder访问该它。驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。驱动和应用程序之间的接口协议主要由ioctl()接口实现。ioctl()能够一次调用实现先写后读以满足同步交互，不提供分别调用write()和 read()。

ServiceManager与实名Binder：和DNS类似，SMgr将字符形式的Binder名字转化成Client中对该Binder的引用，使Client能够通过Binder 名字获得对Server中Binder实体的引用。注册了名字的Binder叫实名Binder，就象每个网站除了有IP地址外都有自己的网址。 Server创建了Binder实体，为其取一个字符形式，可读易记的名字，将这个Binder连同名字以数据包的形式通过Binder驱动发送给 SMgr，通知SMgr注册一个名叫张三的Binder，它位于某个Server中。驱动为这个穿过进程边界的Binder创建位于内核中的实体节点以及SMgr对实体的引用，将名字及新建的引用传递给SMgr。SMgr收数据包后，从中取出名字和引用填入一张查找表中。{S:Server创建一个Binder实体并给它分配一个唯一标识，将其发送给SMgr，SMgr知晓哪个server里有一个叫什么的Binder并存储。“告知”过程由驱动处理。--- server与client的跨进程通信}

初始化跨进程通信：SMgr是一个进程，Server是另一个进程，Server向SMgr注册Binder必然会涉及进程间通信。当前 实现的是进程间通信却又要用到进程间通信，这就好象蛋可以孵出鸡前提却是要找只鸡来孵蛋。Binder的实现比较巧妙： 预先创造一只鸡来孵蛋。SMgr和其它进程同样采用Binder通信，SMgr是Server端，有自己的Binder实体，其它进程都是Client，需要通过这个 Binder的引用来实现Binder的注册，查询和获取。{S:对SMgr来说，其他进程都是client！！} SMgr提供的Binder比较特殊，它没有名字也不需要注册， 当一个进程使用 BINDER_SET_CONTEXT_MGR命令将自己注册成SMgr时Binder驱动会自动为它创建Binder实体（这就是那只预先造好的鸡）。其次 这个Binder的引用在所有Client中都固定为0而无须通过其它手段获得。 也就是说，一个Server若要向SMgr注册自己,Binder就必需通过0这个引用和SMgr的Binder通信。类比网络通信，0号引用就好比域名服务器的地址，你必须手工或动态配置好。要注意这里说的Client是相对SMgr而言的，一个应用程序是个提供服务的Server，但对SMgr来说它仍然是个Client。

Client 获得实名Binder的引用：Server向SMgr注册了Binder实体及其名字后，Client就可以通过名字获得该Binder的引用了。Client也利用保留的0号引用向SMgr请求访问某个Binder：我申请获得名字叫张三的Binder的引用。{client向SMgr请求指向server的引用（所有的通信都是由binder完成的，这里用到的是SMgr的Binder）}SMgr收到这个连接请求，从请求数据包里获得Binder的名字，在查找表里找到该名字对应的条目，从条目中取出Binder的引用，将该引用作为回复发送给发起请求的Client。 从面向对象的角度，这个 Binder对象现在有了两个引用：一个位于SMgr中，一个位于发起请求的Client中。{S:SMgr有一个编号为0的Binder，每个server都有一个拥有唯一标识的Binder}如果接下来有更多的Client请求该Binder，系统中就会有更多的引用指向该Binder，就象java里一个对象存在多个引用一样。而且类似的这些指向Binder的引用是强类型，从而确保只要有引用 Binder实体就不会被释放掉。通过以上过程可以看出，SMgr象个火车票代售点，收集了所有火车的车票，可以通过它购买到乘坐各趟火车的票，即得到某个Binder的引用。

匿名Binder：并不是所有Binder都需要注册给SMgr广而告之的。 Server端可以通过已经建立的Binder连接将创建的Binder实体传给 Client，当然这条已经建立的Binder连接必须是通过实名Binder实现。由于这个Binder没有向SMgr注册名字，所以是个匿名 Binder。Client将会收到这个匿名Binder的引用，通过这个引用向位于Server中的实体发送请求。 匿名Binder为通信双方建立一条私密通道，只要Server没有把匿名Binder发给别的进程，别的进程就无法通过穷举或猜测等任何方式获得该Binder的引用，向该Binder发送请求。