AndroidIPC 框架分析Binder，Service，Service manager

AndroidIPC 框架分析Binder，Service，Service manager

我首先从宏观的角度观察Binder,Service,Service Manager，并阐述各自的概念。从Linux的概念空间中，Android 的设计Activity 托管在不同的的进程，Service 也都是托管在不同的进程，不同进程间的Activity,Service 之间要交换数据属于IPC。Binder 就是为了Activity 通讯而设计的一个轻量级的IPC 框架。在代码分析中，我发现Android 中只是把Binder 理解成进程间通讯的实现，有点狭隘，而是应该站在公共对象请求代理这个高度来理解Binder，Service 的概念，这样我们就会看到不一样的格局，从这个高度来理解设计意图，我们才会对Android 中的一些天才想法感到惊奇。从Android 的外特性概念空间中，我们看不到进程的概念，而是Activity，Service，AIDL，INTENT。一般的如果我作为设计者，在我们的根深蒂固的想法中，这些都是如下的C/S 架构，客户端和服务端直接通过Binder 交互数据，打开Binder 写入数据，通过Binder读取数据，通讯就可以完成了。
该注意到Android 的概念中，Binder 是一个很低层的概念，上面一层根本都看不到
Binder，而是Activity 跟一个Service 的对象直接通过方法调用，获取服务。
这个就是Android 提供给我们的外特性：在Android 中，要完成某个操作，所需要做的
就是请求某个有能力的服务对象去完成动作，而无需知道这个通讯是怎样工作的，以及服务
在哪里。所以Andoid 的IPC 在本质上属于对象请求代理架构，Android 的设计者用CORBA
的概念将自己包装了一下，实现了一个微型的轻量级CORBA 架构，这就是Andoid 的IPC
设计的意图所在，它并不是仅仅解决通讯，而是给出了一个架构，一种设计理念，这就是
Android 的闪光的地方。Android 的Binder 更多考虑了数据交换的便捷，并且只是解决本机
的进程间的通讯，所以不像CORBA 那样复杂，所以叫做轻量级。
所以要理解Android 的IPC 架构，就需要了解CORBA 的架构。而CORBA 的架构在本质上
可以使用下面图来表示：在服务端，多了一个代理器，更为抽象一点我们可以下图来表示。
分析和CORBA 的大体理论架构，我给出下面的Android 的对象代理结构。
在结构图中，我们可以较为清楚的把握Android 的ＩＰＣ包含了如下的概念：
设备上下文什（ContextObject）
设备上下文包含关于客服端，环境或者请求中没有作为参数传递个操作的上下文信息，
应用程序开发者用ContextObject 接口上定义的操作来创建和操作上下文。
Android 代理：这个是指代理对象
Binder Linux 内核提供的Binder 通讯机制
Android 的外特性空间是不需要知道服务在那里，只要通过代理对象完成请求，但是我
们要探究Android 是如何实现这个架构，首先要问的是在Client 端要完成云服务端的通讯，
首先应该知道服务在哪里？我们首先来看看Service Manger 管理了那些数据。Service
Manager 提供了add service,check service 两个重要的方法，并且维护了一个服务列表记录登
记的服务名称和句柄。
Service manager service 使用0 来标识自己。并且在初始化的时候，通过binder 设备使用
BINDER_SET_CONTEXT_MGR ioctl 将自己变成了CONTEXT_MGR。Svclist 中存储了服务
的名字和Handle，这个Handle 作为Client 端发起请求时的目标地址。服务通过add_service
方法将自己的名字和Binder 标识handle 登记在svclist 中。而服务请求者，通过check_service
方法，通过服务名字在service list 中获取到service 相关联的Binder 的标识handle,通过这个
Handle 作为请求包的目标地址发起请求。
我们理解了Service Manager 的工作就是登记功能，现在再回到ＩＰＣ上，客服端如何
建立连接的？我们首先回到通讯的本质：IPC。从一般的概念来讲，Android 设计者在Linux
内核中设计了一个叫做Binder 的设备文件，专门用来进行Android 的数据交换。所有从数据
流来看Java 对象从Java 的VM 空间进入到C++空间进行了一次转换，并利用C++空间的函
数将转换过的对象通过driver\binder 设备传递到服务进程，从而完成进程间的IPC。这个过
程可以用下图来表示。
这里数据流有几层转换过程。
（1） 从JVM 空间传到c++空间，这个是靠JNI 使用ENV 来完成对象的映射过程。
（2） 从c++空间传入内核Binder 设备，使用ProcessState 类完成工作。
（3） Service 从内核中Binder 设备读取数据。
Ａｎｄｒｏｉｄ设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层
概念空间中没有这些细节。Android 设计者是怎样做的呢？我们通过c++空间代码分析，看
到有如下空间概念包装(ProcessState@(ProcessState.cpp)
在ProcessState 类中包含了通讯细节，利用open_binder 打开Linux 设备dev\binder,
通过ioctrl 建立的基本的通讯框架。利用上层传递下来的servicehandle 来确定请求发送到那
个Service。通过分析我终于明白了Bnbinder，BpBinder 的命名含义，Bn-代表Native，而
Bp 代表Proxy。一旦理解到这个层次，ProcessState 就容易弄明白了。