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

核心提示：(2) 从c++空间传入内核Binder设备，使用ProcessState类完成工作，Android IPC框架分析 Binder，Service，Service manager(3)，(3) Service从内核中Binder设备读取数据，Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程，我们看

(2) 从c++空间传入内核Binder设备，使用ProcessState类完成工作。

(3) Service从内核中Binder设备读取数据。

Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层概念空间中没有这些细节。Android设计者是怎样做的呢?我们通过c++空间代码分析，看到有如下空间概念包装(ProcessState@(ProcessState.cpp)

在ProcessState类中包含了通讯细节，利用open_binder打开Linux设备devinder,通过ioctrl建立的基本的通讯框架。利用上层传递下来的servicehandle来确定请求发送到那个Service。通过分析我终于明白了Bnbinder，BpBinder的命名含义，Bn-代表Native，而Bp代表Proxy。一旦理解到这个层次，ProcessState就容易弄明白了。

下面我们看JVM概念空间中对这些概念的包装。为了通篇理解设备上下文，我们需要将Android VM概念空间中的设备上下文和C++空间总的设备上下文连接起来进行研究。

为了在上层使用统一的接口，在JVM层面有两个东西。在Android中，为了简化管理框架，引入了ServiceManger这个服务。所有的服务都是从ServiceManager开始的，只用通过Service Manager获取到某个特定的服务标识构建代理IBinder。在Android的设计中利用Service Manager是默认的Handle为0，只要设置请求包的目标句柄为0，就是发给Service Manager这个Service的。在做服务请求时，Android建立一个新的Service Manager Proxy。Service Manager Proxy使用ContexObject作为Binder和Service Manager Service(服务端)进行通讯。

我们看到Android代码一般的获取Service建立本地代理的用法如下：

IXXX mIxxx=IXXXInterface.Stub.asInterface(ServiceManager.getService("xxx"));

例如：使用输入法服务：

IInputMethodManager mImm=

IInputMethodManager.Stub.asInterface(ServiceManager.getService("input_method"));

这些服务代理获取过程分解如下：

(1) 通过调用GetContextObject调用获取设备上下对象。注意在AndroidJVM概念空间的ContextObject只是 与Service Manger Service通讯的代理Binder有对应关系。这个跟c++概念空间的GetContextObject意义是不一样的。