5. Binder机制的Java接口
通常,应用程序框架中基
于Java语言的Binder接口是通过JNI来调用基于C/C++语言的Binder运行库来为Java应用程序提供进程间通信服务的。在应用程序
中,Server被实现为Service的形式,并通过IServiceManager.addService接口来把这个Service添加到
Service
Manager中;Client也是通过IServiceManager.getService接口来获得Service接口,这样就可以使用这个
Service提供的功能了。
这里,我们以XXXService代表XXX的Service服务为例,把整个交互的过程分为如下几个部分来分析:初始化Framework层Binder框架
C/S获得ServiceManager的Java远程接口过程
XXXService的接口定义和启动过程,添加自己到SM中
Client获得XXXService的Java远程接口过程
Client通过Java远端接口使用XXXService提供的服务
5.1 Binder framework层的初始化
在java层工作前,需建立与Native层的关系,建立这个关系的函数是 android_util_Binder.cpp::register_android_os_Binder(),流程如下:初始化Java Binder类和Native层的关系:调用 int_register_android_os_Binder(env)找到Java层的Binder
通过gBinderOffsets对象保存和Binder类相关的某些在JNI层中使用的信息
注册Binder类中native函数的实现
初始化Java BinderInternal类和Native层的关系:调用 int_register_android_os_BinderInternal(env)根据BinderInternal的全路径(com/android/internal/os/BinderInternal)找到代表该类的jclass对象
通过gBinderInternal静态对象,保存BinderInternal类的一些信息:如methodID和filedID
注册BinderInternal类中native函数的实现
初始化 Java BinderProxy类和Native层的关系:调用 int_register_android_os_BinderProxy(env)通过gWeakReferenceOffsets来和WeakReference类交互,包括:获取WeakReference类get函数的methodID
通过gErrorOffsets来和Error类交互
通过gBinderProxyOffsets来和BinderProxy类交互,包括:获取BinderProxy的一些信息
通过gClassOffsets来和Class类交互
注册BinderProxy native函数的实现
初始化Java Parcel类和Native层的关系:调用 int_register_android_os_Parcel(env)
作用:初始化其实就是提前获取一些JNI层的使用信息,这样可以节省每次使用时获取这些信息的时间
5.2 Binder framework层构架总览
这里解释一下Java Binder, Java Internal, Java Proxy,以及IBinder的关系:系统定义了一个IBinder接口类以及DeathRecipient接口。IBinder接口类中定义了FLAG_ONEWAY标志,作用是实现非阻塞,只把请求发送到Binder驱动即可返回,不用等待服务端的结果。
Binder类和BinderProxy类分别实现了IBinder接口。Binder类作为服务端Bn的代表;BinderProxy类作为客户端Bp的代表
BinderInternal类仅供Binder架构使用,其内部有一个GcWatcher类,专门用于处理和Binder架构相关的垃圾回收
Java层同样提供一个用于承载通信数据的Parcel类
5.3 C/S获得ServiceManager的Java远程接口过程
我们要获取的ServiceManager的Java远程接口是一个ServiceManagerProxy对象的IServiceManager
接口,如上图。IServiceManager接口提供了getService()和addService()两个函数来管理Service。从
serviceManagerProxy的构造函数中发现,它需要一个BinderProxy对象的IBinder接口作为参数;所以得先获得
BinderProxy对象。
上图中,我们可以看到获取SM的Java远程接口ServiceManagerProxy的路径,是通过ServiceManager.getIServiceManager()来获取,而该函数又是通过ServiceManagerNative来获取。
我们先来分析getIServiceManager()
5.3.1 ServiceManager.getIServiceManager()
这个函数定义在frameworks/base/core/java/android/os/ServiceManager.java文件中,里面的核心代码:sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
return sServiceManager;
如果其静态成员变量sServiceManager尚未创建,首先要通过BinderInternal.getContextObject()来获得一个BinderProxy对象,再调用ServiceManagerNative.asInterface()来创建对应的ServiceManagerProxy对象
接下来通过BinderInternal.getContextObject() 和ServiceManagerNative.asInterface()两个部分来分析。
5.3.1.1 BinderInternal.getContextObject()
BinderInternal.getContextObject()这个函数定义在frameworks/base/core/java/com
/android/internal/os/BinderInternal.java文件中,调用了JNI层的
android_os_BinderInternal_getContextObject()。
android_os_BinderInternal_getContextObject()是一个JNI方法,在frameworks/base
/core/jni/android_util_Binder.cpp文件中,核心代码为:sp b = ProcessState::self()->getContextObject(NULL);ProcessState::self()->getContextObject(NULL)返回一个BpBinder对象,handle值为0,代码即可以写成:
sp b = new BpBinder(0);
return javaObjectForIBinder(env, b); 把这个BpBinder对象转换成一个BinderProxy对象object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor); 创建了一个BinderProxy对象
env->SetIntField(object, gBinderProxyOffsets.mObject,
(int)val.get());
把BpBinder对象和BinderProxy对象关联起来;BinderProxy.mObject成员记录了这个BpBinder对象的地址
最后,把BinderProxy返回到android_os_BinderInternal_getContextObject函数,再返回到ServiceManager.getIServiceManager()中,我们就获得一个BinderProxy对象了
在该函数中,有两个变量gBinderOffsets和gBinderProxyOffsets:
gBinderOffsets变量是用来记录”ppt 2.”左下角第二个类图中的Binder类的相关信息的,它是在注册Binder类的JNI方法的int_register_android_os_Binder函数初始化的
gBinderProxyOffsets是用来变量是用来记录”ppt
2.”右上角第一个图中的BinderProxy类的相关信息的,它是在注册BinderProxy类的JNI方法的
int_register_android_os_BinderProxy函数初始化的
核心代码:
在getIServiceManager()中的:sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
相当于:sServiceManager = ServiceManagerNative.asInterface(new BinderProxy());
5.3.1.2 ServiceManagerNative.java::asInterface()
接下来调用asInterface(),定义在frameworks/base/core/java/android/os/ServiceManagerNative.java 文件中:asInterface(IBinder
obj):obj是一个BpProxy对象或者BinderProxy对象(取决于这个申请SM的Java层远程接口的对象是Client还是
Server),构造一个和业务相关的Proxy对象。这里我们假设申请者是client,构造了ServiceManagerProxy对象
这样,在getIServiceManager()中:sServiceManager = ServiceManagerNative.asInterface(new BinderProxy()); 相当于:sServiceManager =new ServiceManagerProxy(new BinderProxy());
5.3.2 获得SM的Java远端接口整体流程
这样,申请者在Java层拥有了一个Service
Manager远程接口ServiceManagerProxy,这个ServiceManagerProxy对象在JNI层有一个handle值为0的
BpBinder对象与之通过gBinderProxyOffsets关联起来,整体流程如下:
5.4 Service启动过程
XXXService继承了IXXXService.Stub类,并通过本地方法实现了Stub类的业务函数,有了XXXService之后,我们就会把它的Server类SystemServer启动起来。
定义在frameworks/base/services/java/com/android/server/SystemServer.java
文件中,SystemServer对象是在系统启动时创建的,创建后会启动一个线程来创建XXXService,并把它添加到SM中去
在serverThread extends Thread中:ServiceManager.addService("XXX", new XXXService());
下面我们会进行new XXXService() 和 ServiceManager.addService()两部分的分析
5.4.1 new XXXService()
New
XXXService()会调用XXXService类的构造函数,而XXXService类继承于IXXXService.Stub类
(XXXNative),Stub类又继承于Binder类,因此会调用Binder类的构造函数,在这个构造函数里,又会调用init()来初始化这个
Binder对象
init()只做了一件事,就是创建一个JavaBBinderHolder对象,然后把这个对象的地址保存在Binder类的mObject成员变量中
那么结果为:获得了一个新的实例XXXService(); 且Java层的Binder对象把Native层的JavaBBinderHolder(就是BBinder)保存在变量mObject中
5.4.2 ServiceManager.addService()的实现
分析完了new XXXService(),再来看下ServiceManager.addService()的实现,核心代码:getIServiceManager().addService(name, service);
getIServiceManager()之前分析过,返回一个ServiceManagerProxy对象的IServiceManager接口,那么我们看ServiceManagerProxy.addService()的实现:获得Parcel类型的data和reply
data.writeStrongBinder(service)
调用mRemote.transact(ADD_SERVICE_TRANSACTION,data,reply,0);这里的mRemote就是BinderProxy对象,调用transact把封装好的请求数据发送出去
addService()最终会调用到Framework层的BinderProxy.transact();最后调用到Native层的
BpBinder::transact()进入到Binder驱动,然后驱动唤醒SM响应这个ADD_SERVICE_TRANSACTION请求,把自
己注册到SM中;
AMS在SM中注册服务流程图
XXXService注册服务的类图
5.5.1 Client获得XXXService的Java远程接口过程
Client是通过IServiceManager.getService()来获得XXXService的远程接口的;在client这边的
onCreate()中调用
IXXXService.Stub.asInterface(ServiceManager.getService(“XXX”));
先看ServiceManager.getService(“XXX”)
ServiceManager.getService(“XXX”)。实际是调用了ServiceManagerProxy.getService(),这个函数通过mRemote.transact执行操作;和前面一样mRemote是一个BinderProxy对象。
然后调用IBinder binder = reply.readStrongBinder();作用是:调用JNI层的
android_os_Parcel_readStrongBinder(),其作用是把Java语言的Parcel对象转换成C++语言的Parcel
对象parcel,并通过parcel->readStrongBinder函数来获得一个Binder引用的BpBinder对象
最后:return javaObjectForIBinder(env, parcel->readStrongBinder());
javaObjectForIBinder()之前介绍过,会创建一个BinderProxy对象。相当于: return
javaObjectForIBinder(env, new BpBinder(handle));
返回给上层getService()的binder对象
那么 XXXService =
IXXXService.Stub.asInterface(ServiceManager.getService("XXX"));
相当于:XXXService = IXXXService.Stub.asInterface(new BinderProxy()));
5.5.2 IXXXService.Stub.asInterface()
这个函数的核心代码为:android.os.IInterface iin = (android.os.IInterface)obj.queryLocalInterface(DESCRIPTOR);
if (((iin!=null)&&(iin instanceof android.os.IXXXService))) {
return ((android.os.IXXXService)iin);
}
return new android.os.IXXXService.Stub.Proxy(obj);
}
这里的obj是一个BinderProxy对象,它的queryLocalInterface返回null,于是调用下面语句获得XXXService的
远程接口: return new android.os.IXXXService.Stub.Proxy(obj);
相当于:return new android.os.IXXXService.Stub.Proxy(new BinderProxy());
这样就获得了XXXService的远程接口了,实质上是实现了IXXXService接口的IXXXService.Stub.Proxy对象
获得XXXService的类图
client使用XXXService框架图
5.6 framework层总结
Native层和Java层的关键点:native层中,client会有一个BpBinder引用,Server会有一个BBinder引用来实现通信;
Java层中,client会有一个BinderProxy对象,server会有一个JavaBBinder对象来负责通信,但实质的通信实现是基于native层,Native层又基于Binder驱动的
针对Java层C/S交互的5个步骤的总结:初始化Java层Binder框架,是为了减少在以后通信过程中初始化的时间
C/S获得ServiceManager的Java远程接口过程,实际上就是获得ServiceManagerProxy,为Java层提供C/S与SM通信的对象
XXXService的接口定义和启动过程,添加自己到SM中,实际上是为XXXService对象创建与SM通信的BinderProxy对象(就是步骤2),和创建为与client通信的JavaBBinder对象
Client获得XXXService的Java远程接口过程,实际上是为client创建与SM通信的BinderProxy对象(就是步骤2),和创建与XXXService通信的BinderPorxy对象
Client通过Java远端接口使用XXXService提供的服务,实际上是利用client的BinderProxy对象与XXXService的JavaBBinder对象通信,达到client使用服务的目的
虽然Binder机制的
代码层层嵌套,逻辑复杂,但Binder机制的实质就是实现不同进程间的通信,通过SM来管理跨进程的服务;理解这一点,就可以理清Binder的核心:
通信的实现最终都会由Binder的驱动实现,Native层和Java层的复杂构架,是出于2方面考虑:Native层的构架是为了提供统一的接口,并把业务层和逻辑层分开
Java层的构架是为应用层提供统一的接口,把内部实现封装起来,隔开了底层实现和上层应用