Android 核心分析 之六 -----IPC框架分析 Binder，Service，Se...

我首先从宏观的角度观察 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就容易弄明白了。

 

     下面咱们看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意义是不同的。

注意看看关键的代码

 

    BinderInternal.getContextObject（）    @BinderInteral.java

    NATIVE JNI:getContextObject()   @android_util_Binder.cpp

Android_util_getConextObject            @android_util_Binder.cpp

     ProcessState::self()->getCotextObject(0)  @processState.cpp

      getStrongProxyForHandle(0)  @

         NEW BpBinder(0)

 

注意ProcessState::self()->getCotextObject(0) @processtate.cpp，就是该函数在进程空间创建 了ProcessState对象，打开了Binder设备dev/binder,而且传递了参数0，这个0表明了与Service Manager这个服务绑定。

（2） 经过调用ServiceManager.asInterface（ContextObject）创建一个代理ServiceManger。

     mRemote= ContextObject(Binder)

    这样就创建起来ServiceManagerProxy通信框架。

 (3)客户端经过调用ServiceManager的getService的方法创建一个相关的代理Binder。

 

              ServiceMangerProxy.remote.transact(GET_SERVICE)

                   IBinder=ret.ReadStrongBinder() -》这个就是JVM空间的代理Binder

                      JNI Navite: android_os_Parcel_readStrongBinder()    @android_util_binder.cpp

                            Parcel->readStrongBinder()  @pacel.cpp

                                      unflatten_binder  @pacel.cpp

                                                getStrongProxyForHandle(flat_handle)

                                                          NEW BpBinder(flat_handle)-》这个就是底层c++空间新建的代理Binder。

整个创建过程能够使用以下的示意图来表示：

 

 

 

 

      Activity为了创建一个IPC，须要创建两个链接：访问Servicemanager Service的链接，IXXX具体XXX Service的代理对象与XXXService的链接。这两个链接对应c++空间ProcessState中BpBinder。对IXXX的操做最后就 是对BpBinder的操做。因为咱们在写一个Service时，在一个Package中写了Service Native部分和Service Proxy部分，而Native和Proxy都实现相同的接口：IXXX Interface,可是一个在服务端，一个在客服端。客户端调用的方式是使用remote->transact方法向Service发出请求，而 在服务端的OnTransact中则是处理这些请求。因此在Android Client空间就看到这个效果：只须要调用代理对象方法就达到了对远程服务的调用目的，实际上这个调用路径好长好长。

 

        咱们其实还一部分没有研究，就是同一个进程之间的对象传递与远程传递是区别的。同一个进程间专递服务地和对象，就没有代理BpBinder产生，而只是对象的直接应用了。应用程序并不知道数据是在同一进程间传递仍是不一样进程间传递，这个只有内核中的Binder知道，因此内核Binder驱动能够将Binder对象数据类型从BINDER_TYPE_BINDER修改成BINDER_TYPE_HANDLE或者BINDER_TYPE_WEAK_HANDLE做为引用传递。