Android IPC框架分析 Binder，Service，Service manager

核心提示：在结构图中，我们可以较为清楚的把握Android的IPC包含了如下的概念：设备上下文什(ContextObject)设备上下文包含关于客服端，Android IPC框架分析 Binder，Service，Service manager(2)，环境或者请求中没有作为参数传递个操作的上下文信息，应用程序开发者用Contex

在结构图中，我们可以较为清楚的把握Android的IPC包含了如下的概念：

设备上下文什(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上，客服端如何建立连接的?我们首先回到通讯的本质：IPC。从一般的概念来讲，Android设计者在Linux内核中设计了一个叫做Binder的设备文件，专门用来进行Android的数据交换。所有从数据流来看Java对象从Java的VM空间进入到C++空间进行了一次转换，并利用C++空间的函数将转换过的对象通过driverinder设备传递到服务进程，从而完成进程间的IPC。这个过程可以用下图来表示。

这里数据流有几层转换过程。

(1) 从JVM空间传到c++空间，这个是靠JNI使用ENV来完成对象的映射过程。