Android 源码分析 -- Binder机制

首先来看一张Android Binder系统运行的时序图:

 

(此图来自于google搜图)

       从时序图上来看，整个Android Binder系统还是有些复杂的，但是仔细分析可能会发现整个Android Binder运行机制似乎与某种常见的系统架构类似，是的，那就是我们经常会见到的基于RPC机制的C/S架构了。

　　为了便于对比和解释Android Binder的原理，我们先从一个比较熟悉的场景分析: 对于一个基于RPC（远程过程调用）的C/S系统，我们将其抽象并简化，基本上由”server”,”client”,”service_manager”,”rpc-api”,”service-info”(代表每个提供service的server的信息)这5部分构成。

       另一方面，对于大量基于RPC的network-server，我们发现其中有相当一部分的功能和组件是独立于具体的服务功能而保持不变的。比如”多路事件分发”，”并发控制”，”内存管理”，”session管理”……于是，为了避免一次又一次地”reinvent the wheel”,许多network-server framework就诞生了。比如: ACE,boost.asio,libevent……在这些框架的基础之上，我们只需要实现特定于具体服务处理逻辑的组件，然后与框架拼装起来即可。

       如果你熟悉network-server开发，或者对其有所了解，基于上面的描述，应该能了解整个基于RPC的网络服务器的基本框架了。

       说了这么多，它跟Binder有什么关系呢？我们先来看一张图。

 

 

       图中的"------"表示虚线两端的组件是等价的，看了这个图，应该对Android-Binder这个并不太容易理解的组件有一个清晰的认识了吧:)

       Binder作为Android系统的核心基础组件，用于简化Android中底层服务的开发，以及服务之间的数据通信。因为这些服务都运行在同一台Android机器上，而且这些服务之间的关系类似于一种C/S架构，所以这个时候需要的不是RPC框架，而是IPC框架。而Android系统中的Binder框架正是提供这种功能的IPC框架。

       看了这个图，有的人可能会有想到: RPC 的client端是基于ip:port来定位到具体的server端，那么Binder框架中，client端又是基于什么机制来定位server端呢?答案是: “handler”。过程是这样的:

　　1) 对于service_manager，它的handler是固定的且值为0。

　　2) 当其它的service注册到service_manager中时，service_manager会为它分配一个唯一的handler值，并建立一个“service_name ßàhandler”的一一映射关系。

　　3)  当一个client需要访问一个具体的service时，它会将所需要访问的service的service_name传递给service_manager，然后service_manager会依据这个service_name在所管理的服务中查找到对应的handler。

　　4)  此后，client与server之间就可以基于这个”handler”作为通信之间的标识，基于Android的Binder设置进行通信，这一点类似于当client获取到了server端的ip:port之后，基于socket来与服务端进行通信。

 

　　后续的文章中会继续对Android Binder进行深入分析，错漏之处敬请指正。

转自http://www.cnblogs.com/xwroyal/archive/2012/01/15/2322733.html