命题
当service经常被远程调用时,我们常常用到aidl来定一个接口供service和client来使用,这个其实就是使用Binder机制的IPC通信。当client bind service成功之后,系统AM会调用回调函数onServiceConnected将service的IBinder传递给client, client再通过调用aidl生成的asInterface()方法获得service的调用接口,此时一个bind过程结束了,我们在client端就可以远程调用service的方法了。例如
public void onServiceConnected(ComponentName className, IBinder service) { mSecondaryService = ISecondary.Stub.asInterface(service); }
我们再看aidl生成的asInterface()的定义
public static com.example.Android.apis.app.ISecondary asInterface(android.os.IBinder obj) { if ((obj==null)) { return null; } android.os.IInterface iin = (android.os.IInterface)obj.queryLocalInterface(DESCRIPTOR); if (((iin!=null)&&(iin instanceof com.example.android.apis.app.ISecondary))) { return ((com.example.android.apis.app.ISecondary)iin); } return new com.example.android.apis.app.ISecondary.Stub.Proxy(obj); }
首先,asInterface()会去query传入的IBinder对象是否有LocalInterface,这里的LocalInterface是指传入的IBinder是service本身的引用还是代理。
1.当asInterface的输入的IBinder为server的引用(Binder类型)时,则直接返回该引用,那么此时调用server的方法不为IPC通信,而是直接的函数调用;
2.当asInterface的输入的IBinder为server的代理(BinderProxy类型)时,则需要创建该server的代理并返回,此时调用server的方法为IPC通信。
那么以上两种情况发生的条件是什么呢?这里我们先给出答案,然后再深入到代码中去研究2种不同的情况。
1.当client和service处在相同进程中的话,asInterface的输入的IBinder为server的引用时;
2.当client和service处在不同进程中的话,asInterface的输入的IBinder为server的代理。
在研究上述实现代码之前,我们先介绍一下IBinder作为参数使用IPC进程间传递时的状态变化,其实这个就是我们本篇文章的核心内容,理解了这个机制,我们就会很容易理解我们上述的那个命题的原理了。
模型
IBinder作为参数在IPC通信中进行传递,可能会使某些人困惑,IBinder不就是IPC通信的媒介吗?怎么还会被作为参数来传递呢,这样理解就有点狭隘了,拿native层的IPC来说,client从SM(service manager)中获取service端的Interface,这个Interface同时也是IBinder类型,当C/S两端需要双工通信时,即所谓的Service端需要反过来调用Client端的方法时,就需要client通过前述的那个Interface将Client端的IBinder传递给Service。
拿Java应用层的Service来说更是如此,如本文的这个命题,下面我们会分析,首先来介绍原理性的知识。
Binder IPC通信中,Binder是通信的媒介,Parcel是通信的内容。方法远程调用过程中,其参数都被打包成Parcel的形式来传递的。IBinder对象也不例外,我们看一下Parcel类中的writeStrongBinder()(由于java层和native层的方法是相对应的,java层只是native的封装,因此我们只需要看native的即可),
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flatten_binder(ProcessState::self(), val, this);
}