Binder机制全解（一）Binder通信模型

      Binder是Android系统提供的一种IPC（进程间通信）机制，它的英文翻译是“粘合剂”，正如其名，它可以将系统各个进程粘合在一起，这样我们就可以使用其他进程提供的各种服务，整个系统仿佛运行于同一个程序之中。Android系统的四大组件，ActivityManagerService，PackageManagerService等系统服务无一不与Binder挂钩，它是系统间各个组件通信的桥梁。

    我们知道， Android系统是基于Linux内核开发的， Linux内核提供了丰富的进程间通信机制， 如管道（Pipe ）、 信号（Signal ）、 消息队列（Message ）、 共享内存（Share Memory ）和插口（Socket)等。 既然有这么多传统的进程间通信机制， 那么Android为什么不使用这些原有的技术，而是要开发一种新的叫Binder的进程间通信机制呢。主要有两个方面的原因：一是：性能方面，在移动设备上（性能受限制的设备，比如要省电），广泛地使用跨进程通信对通信机制的性能有严格的要求，Binder相对出传统的Socket方式，更加高效。Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，共享内存方式一次内存拷贝都不需要，但是它一般要结合其他的进程问通信机制来同步信息，实现方式又比较复杂。二是：安全方面，传统的进程通信方式对于通信双方的身份并没有做出严格的验证，比如Socket通信ip地址是客户端手动填入，很容易进行伪造，而Binder机制从协议本身就支持对通信双方做身份校检，因而大大提升了安全性。

     Binder基于Client/Server架构的通信模式，一个进程作为Server（服务端）提供多种服务，如媒体播放、各种传感器、窗口管理，网络连接等服务；多个进程作为Client（客户端）向Server发起服务请求，获得所需要的服务。同 一 个Server进程可以同时运行多个组件来向Client进程提供服务， 这些组件称为Service组件 ； 同 一 个Client进程也可以同时向多个Service组件请求服务， 每 一 个请求都对应有 一 个Client组件， 或者称为Service代理对象。要实现这种通信模式，主要涉及到Client 、 Service 、 Service Manager和Binder驱动程序四个角色，下面是这几个角色的通信交互图。

整个通信过程可分为4个步骤：

1：注册成为ServiceManager

    首先要有一个进程向驱动提出申请成为Service管理者，因为，Service组件在启动时 ， 会将自己注册到 一 个

Service Manager组件中， 以便Client组件可以通过Service Manager组件找到它，并且在一个系统中，只能有一个组件成为

Service Manager。因此， 我们将Service Manager组件称为Binder进程间通信机制的上下文管理者，同时由于它也需要与

普通的Server进程和Client进程通信， 我们也将它看作是 一 个Service组件， 只不过它是 一 个特殊的Service组件。

2：向SM注册服务

    提供Seivice的组件，要想被其他的进程的Client组件找到并且使用，就必须先通过驱动向SM注册服务。Seivice组件首先给

自己的服务取一个字符串形式的名字，然后将名字及新建的服务引用打包，通过驱动传递给SM。SM收到数据包后，从中取出

名字和引用填入一张查找表中，这样，Client组件就可以通过名字向SM获取这个服务，这就象每个网站除了有IP地址外还有

自己的网址。

3：向SM获取服务

    Seivice向SM注册了引用及其名字后，Client就可以通过名字获得该Seivice的引用了，Client通过驱动向SM发送获取服务的

请求，SM收到这个连接请求，从请求数据包里获得服务的名字，在查找表里找到该名字对应的条目，从条目中取出服务的引

用，将该引用作为回复发送给发起请求的Client。

4：Client使用服务

  当Client组件获取了这个Service的引用后，就可以通过这个引用来和Service进行交互，比如，当调用这个引用的方法，

远程进程中的方法就会执行，当然他们之间的交互也是通过驱动作为中转的。

   上面的交互过程中，多次提到了Service引用这个概念，那么这个Service的引用是什么呢，它是提供服务进程中原始的Service地址引用吗？答案是否定的，这其中隐藏了很多复杂的细节，它是通过驱动转换之后的引用对象，这其中的细节将在下一节中再详细说明。