使用AIDL
Messenger是以串行的方式处理客户端发来的消息,如果大量的消息同时发送到服务端,服务端仍然只能一个个处理,如果有大量的并发请求,那么用Messenger就不太合适了。同时,Messenger的作用主要是为了传递消息,很多时候我们可能需要跨进程调用服务端的方法,这种情形用Messenger就无法做到了,但是我们可以使用AIDL来实现跨进程的方法调用。AIDL也是Messenger的底层实现,因此Messenger本质上也是AIDL,只不过系统为我们做了封装,从而方便上层的调用而已。这里先介绍使用AIDL来进行进程间通信的流程,分为服务端和客户端两个方面。
服务端
服务端首先要创建一个Service用来监听客户端的连接请求,然后创建一个AIDL文件,将暴露给客户端的接口在这个AIDL文件中声明,最后在Service中实现这个AIDL接口即可。
客户端
客户端所要做事情就稍微简单一些,首先需要绑定服务端的Service,绑定成功后,将服务端返回的Binder对象转成AIDL接口所属的类型,接着就可以调用AIDL中的方法了。
AIDL接口的创建
首先看AIDL接口的创建,如下所示,我们创建了一个后缀为AIDL的文件,在里面声明了一个接口和两个接口方法。
1 | // IBookManager.aidl |
在AlDL文件中,并不是所有的数据类型都是可以使用的,那么到底AIDL文件支持哪些数据类型呢?如下所示:
- 基本数据类型(int、long、char、boolean、double等);
- String和CharSequence;
- List:只支持ArrayList,里面每个元素都必须能够被AIDL支持;
- Map:只支持HashMap,里面的每个元素都必须被AIDL支持,包括key和value;
- Parcelable:所有实现了Parcelable接口的对象;
- AIDL:所有的AIDL接口本身也可以在AIDL文件中使用。
以上6种数据类型就是AIDL所支持的所有类型,其中自定义的Parcelable对象和AIDL对象比须要显式import进来,不管它们是否和当前的AIDL文件位于同一个包内。比如IBookManager.aidl这个文件,里面用到了Book这个类,这个类实现了Parcelable接口,遵守AIDL的规范,我们需要显式地import。AIDL中会大量使用到Parcelable,至于如何使用Parcelable接口来序列化对象可参照之前的文章。
另外一个需要注意的地方是,如果AIDL文件中用到了自定义的Parcelable对象,那么必须新建一个和它同名的AIDL文件,并在其中声明它为Parcelable 类型。在上面的IBookManager.aidl中,我们用到Book这个类,所以,我们必须要创建Book.aidl,然后在里面添加如下内容:
1 | // Book.aidl |
我们需要注意,AIDL中每个实现了Parcelable接口的类都需要按照上面那种方式去创建相应的AIDL文件并声明那个类为parcelable。除此之外,AIDL中除了基本数据类型,其它类型的参数必须标上方向:in、out或者inout,in表示输入型参数,out表示输出型参数,inout表示输入输出型参数。我们要根据实际需要去指定参数类型,不能一概使用out或者inout,因为这在底层实现是有开销的。最后,AIDL接口中只支持方法,不支持声明静态常量,这一点区别于传统的接口。
为了方便AIDL的开发,建议把所有和AIDL相关的类和文件全部放入同一个包中,这样做的好处是,当客户端是另外一个应用时,我们可以直接把整个包复制到客户端工程,对于本例来说,就是要把aidl这个包和包中的文件原封不动地复制到客户端中。如果AIDL相关的文件位于不同的包中时,那么就需要把这些包一一复制到客户端工程中。AIDL的包结构在服务端和客户端要保持一致,否则运行会出错,这是因为客户端需要反序列化服务端中和AIDL接口相关的所有类,如果类的完整路径不一样的话,就无法成功反序列化,程序也就无法正常运行。为了方便演示,本示例都是在同一个工程中进行的,但是要理解,一个工程和两个工程的多进程本质是一样的,两个工程的情况,除了需要复制AIDL接口所相关的包到客户端,其它完全一样。
远程服务端Service的实现
上面讲了如何定义AIDL接口,接下来我们实现这个接口,先创建一个Service,称为BookManagerService,代码如下:
1 | public class BookManagerService extends Service { |
上面是一个服务端Service的典型实现,首先在onCreate中初始化添加了两本图书的信息,然后创建了一个Binder对象并在onBind中返回它,这个对象继承自IBookManager.Stub并且实现了它内部的AIDL方法,这个过程在Binder一节已经介绍过了。这里主要看getBookList和addBook这两个AIDL方法的实现,实现过程也比较简单,注意这里采用了CopyOnWriteArrayList,这个CopyOnWriteArrayList支持并发读/写。在前面我们提到,AIDL方法是在服务端的Binder线程池中执行的,因此当多个客户端同时连接的时候,会存在多个线程同时访问的情形,所以我们要在AIDL方法中处理线程同步,而我们直接使用CopyOnWriteArayList来进行自动的线程同步。
前面我们提到,AIDL中能够使用的List只有ArrayList,但是我们这里却使用了CopyOnWriteArrayList(注意它不是继承ArrayList),为什么能够正常工作呢?这是因为AIDL中所支持的是抽象的List,而List只是一个接口,因此虽然服务端返回的是CopyOnWriteArrayList,但是在Binder中会按照List的规范去访问数据并最终形成一个新的ArrayList传递给客户端。所以,我们在服务端采用CopyOnWriteArrayList是完全可以的。和此类似的还有ConcurrentHashMap,可以体会一下这种转换情形。然后我们需要在XML中注册这个Service,如下所示。注意BookManagerService是运行在独立进程中的,它和客户端的Activity不在同一个进程中,这样就构成了进程间通信的场景。
1 | <service |
客户端的实现
客户端的实现就比较简单了,首先要绑定远程服务,绑定成功后将服务端返回的Binder对象转换成AIDL接口,然后就可以通过这个接口去调用服务端的远程方法,代码如下:
1 | public class BookManagerActivity extends AppCompatActivity { |
绑定成功后,会通过bookManager去调用getBookList方法,然后打印出所获取的图书信息,需要注意的是,服务端的方法可能需要很久才会执行完毕,这个时候下面的代码就会导致ANR,这一点需要注意,后面再介绍这种情况,目前之所以要这样写是为了更好地了解AIDL的实现步骤。
接着在XML中注册此Activity,运行程序,log如下所示:
1 | I/BookManagerActivity: query book list, list type:java.util.ArrayList |
可以发现,虽然我们服务端返回的是CopyOnWriteArrayList类型,但是客户端收到的仍然是ArrayList类型,这也证实了我们前面所做的分析。第二行log表明客户端成功地得到了服务端的图书列表信息。
这就是一次完整的使用AIDL进行IPC的过程,下面继续介绍AIDL中常见的一些难点。
我们接着再调用一下另外一个接口addBook,我们在客户端给服务端添加一本书,然后再获取一次,看程序是否能够正常工作。在onServiceConnected中做如下改动:
1 | public void onServiceConnected(ComponentName name, IBinder service) { |
运行后log如下:
1 | I/BookManagerActivity: query book list:[[bookId:1, bookName:Android], [bookId:2, bookName:IOS]] |
我们成功向服务端添加了一本书。
现在我们考虑一种情况,假设有一种需求:用户不想时不时地去查询图书列表了,太累了,于是,他去问图书馆,“当有新书时能不能把书的信息告诉我呢?”。这就是一种典型的观察者模式,每个感兴趣的用户都观察新书,当新书到的时候,图书馆就通知每一个对这本书感兴趣的用户,这种模式在实际开发中用得很多,下面我们就来模拟这种情形。首先,我们需要提供一个AIDL接口,每个用户都需要实现这个接口并且向图书馆申请新书的提醒功能,当然用户也可以随时取消这种提醒。之所以选择AIDL接口而不是普通接口,是因为AIDL中无法使用普通接口。这里我们创建一个IOnNewBookArrivedListener.aidl文件,我们所期望的情况是:当服务端有新书到来时,就会通知每一个已经申请提醒功能的用户。从程序上来说就是调用所有IOnNewBookArivedListener对象中的onNewBookArived方法,并把新书的对象通过参数传递给客户端,内容如下所示。
1 | package com.example.wy521angel.ipctest; |
除了要新增加一个AIDL接口,还需要在原有的接口中添加两个新方法,代码如下所示。
1 | // IBookManager.aidl |
接着,服务端中Service的实现也要稍微修改一下,主要是Service中IBookManager.Stub的实现,我们在IBookManager新加了两个方法,所以在IBookManager.Stub中也要实现这两个方法。同时,在BookManagerService中还开启了一个线程,每隔5秒向书库增加一本新书并通知所有感兴趣的用户,代码如下:
1 | public class BookManagerService extends Service { |
最后,我们还需要修改一下客户端的代码,主要有两方面,首先客户端要注册IOnNewBookArrivedListener到远程服务端,这样当有新书时服务端才能通知客户端,同时我们要在Activity退出时解除这个注册;另一方面,当有新书时,服务端会回调客户端的IOnNewBookArrivedListener对象中的onNewBookArrived方法,但是这个方法是在客户端的Binder线程池中执行的,因此,为了便于进行UI操作,我们需要有一个Handler可以将其切换到客户端的主线程中去执行,这个原理在Binder中已经做了分析了。客户端的代码修改如下:
1 | public class BookManagerActivity extends Activity { |
运行程序,log如下:
1 | D/BMS: registerListener, size: 1 |
每隔5s新书推送是成功的。
从上面的代码我们可以看出,当BookManagerActivity关闭时,我们会在onDestory中去解除已经注册到服务端的listener,这就相当于我们不想再接收图书馆的新书提醒了,所以我们可以随时取消这个提醒服务。按back键退出BookManagerActivity,下面是打印出的log:
1 | I/BookManagerActivity: unregister listener:com.example.wy521angel.ipctest.aidl.BookManagerActivity$3@52f2be8 |
从上面的log可以看出,程序没有像我们所预期的那样执行。在解注册的过程中,服务端竟然无法找到我们之前注册的那个listener,在客户端我们注册和解注册时传递的是同一个listener。最终,服务端由于无法找到要解除的listener而解注册失败。这当然不是我们想要的结果。其实,这是必然的,这种解注册的处理方式在日常开发过程中时常使用到,但是放到多进程中却无法奏效,因为Binder会把客户端传递过来的对象重新转化并生成一个新的对象。虽然在注册和解注册过程中使用的是同一个客户端对象,但是通过Binder传递到服务端后,会产生两个全新的对象。别忘了对象是不能跨进程直接传输的,对象的跨进程传输本质上都是反序列化的过程,这就是为什么AIDL中的自定义对象都必须要实现Parcelable接口的原因。那么我们要怎么做才能实现解注册功能呢?答案是用RemoteCallbackList。
RemoteCallbackList 是系统专门提供的用于删除跨进程listener的接口。RemoteCallbackList是一个泛型,支持管理任意的AIDL接口,这点从它的声明可以看出来,因为所有的AIDL接口都继承自IInterface接口。
1 | public class RemoteCallbackList < E extends IInterface> |
它的工作原理很简单,在它的内部有一个Map结构专门用来保存所有的AIDL回调,这个Map的key是IBinder类型,value是Callback类型,如下所示:
1 | ArrayMap<IBinder,Callback> mCallbacks = new ArrayList<IBinder,Callback>(); |
其中Callback中封装了真正的远程listener。当客户端注册listener时,它会把这个listener的信息存入mCallbacks中,其中key和value分别通过下面的方式获得:
1 | IBinder key = listener.asBinder(); |
虽然说多次跨进程传输客户端的同一个对象会在服务端生成不同的对象,但是这些新生成的对象有一个共同点,那就是它们底层的Binder对象是同一个,利用这个特性,就可以实现上面我们无法实现的功能。当客户端解注册的时候,我们只要遍历服务端所有的listener,找到那个和解注册listener具有相同Binder对象的服务端listener并把它删掉即可,这就是RemoteCallbackList为我们做的事情。同时RemoteCallbackList还有一个很有用的功能,就是当客户端进程终止后,它能够自动移除客户端注册的listener。另外,RemoteCallbackList内部自动实现了线程同步的功能,所以使用它进行注册和解注册时,不需要做额外的线程同步工作。 下面使用它来完成解注册。
RemoteCallbackList使用起来很简单,我们要对BookManagerService做一些修改,首先创建一个RemoteCallbackList对象来替代之前的CopyOnWriteArrayList:
1 | private RemoteCallbackList<IOnNewBookArrivedListener>mListenerList = new RemoteCallbackList<IOnNewBookArrivedListener>(); |
然后修改registerListener 和unregisterListener这两个接口的实现,如下所示:
1 |
|
接下来我们修改onNewBookArrived方法,当有新书的时候,通知所有已注册的listener:
1 | private void onNewBookArrived(Book book) throws RemoteException{ |
BookManagerService的修改已经完毕,为了验证程序功能,还需要添加一些log,在注册和解注册后分别打印出所有listener的数量,如果程序正常工作的话,那么注册之后listener总数量是1,解注册之后总数量应该是0,运行程序,log如下:
1 | D/BMS: registerListener, current size:1 |
很显然,用RemoteCallbackList的确可以完成跨进程的解注册功能。
注意使用RemoteCallbackList时,我们无法向list那样操作他,因为它并不是一个list,遍历RemoteCallbackList,必须要按照下面的方式进行,其中beginBroadcast和finishBroadcast必须配对使用,哪怕我们仅仅是想要获取RemoteCallbackList中的元素个数,这是要注意的地方。
1 | final int N = mListenerList.beginBroadcast(); |
我们知道,客户端调用远程服务的方法,被调用的方法运行在服务端的Binder线程池中,同时客户端线程会被挂起,这个时候如果服务端方法执行比较耗时,就会导致客户端线程长时间地阻塞在这里,而如果这个客户端线程是UI线程的话,就会导致客户端ANR,这当然不是我们想要看到的。因此,如果我们明确知道某个远程方法是耗时的,那么就要避免在客户端的UI线程中去访问远程方法。由于客户端的onServiceConnected和 onServiceDisconnected方法都运行在UI线程中,所以也不可以在它们里面直接调用服务端的耗时方法,这点要尤其注意。另外,由于服务端的方法本身就运行在服务端的Binder线程池中,所以服务端方法本身就可以执行大量耗时操作,这个时候切记不要在服务端方法中开线程执行异步任务,除非你明确知道自己在干什么,否则不建议这么做。下面我们稍微改造一下服务端的getBookList方法,假定这个方法是耗时的,服务端实现如下:
1 |
|
然后在客户端中放一个按钮,单击它的时候就会调用服务端的getBookList方法,可以预知,连续单击几次,客户端就ANR了。避免这个ANR很简单,我们把方法的调用放在非UI线程中就可以了,如下所示:
1 | public void onButton1Click(View view) { |
同理,当远程服务端需要调用客户端的listener中的方法时,被调用的方法也运行在Binder线程池中,只不过是在客户端的线程池。所以,我们同样不可以在服务端中调用客户端的耗时方法。比如针对BookManagerService的onNewBookArrived方法,它的内部调用了客户端的IOnNewBookArrivedListener中的onNewBookArrived 方法,如果这个方法在客户端中是比较耗时的,请保证BookManagerService的onNewBookArrived方法运行在非UI线程中,否则将导致服务端无响应。
另外,由于客户端的IOnNewBookArrivedListener中的onNewBookArrived方法运行在客户端的Binder线程池中,所有不能在它里面去访问UI相关的内容,如果要访问UI,要切换到主线程,用Handler来实现。
为了程序的健壮性,我们还需要做一件事。Binder如果意外死亡,这时我们需要重新连接服务。有两种方法,第一种方法是给Binder设置DeathRecipient监听,当Binder死亡时,会在binderDied方法中回调,我们就可以在这个方法中重新连接远程服务,这种方法在之前有介绍。另一种方法就是在onServiceDisconnected中重连远程服务。这两种方法我们可以随意选择一种来使用,两者的区别在于onServiceDisconnected是在客户端的UI线程中被回调,而binderDied在客户端的Binder线程池中被回调。也就是说,在binderDied方法中我们不能访问UI,这就是二者的区别。
最后介绍的是在AIDL中如何使用权限验证功能。默认情况下,远程服务任何人都可以进行连接,但这应该不是我们要看到的,所以必须给服务加入权限验证功能,权限验证失败则无法调用服务中的方法。在AIDL中进行权限验证,介绍两种常用的方法:
第一种方法,我们可以在onBind中进行验证,验证不通过返回为null,这样验证失败的客户端直接无法绑定服务,至于验证的方式可以有多种,比如使用permission验证。使用这种验证方式,我们首先要在AndroidMenifest中声明所需的权限,比如:
1 | <permission android:name="com.example.wy521angel.ipctest.permission.ACCESS_BOOK_SERVICE" |
定义了权限以后,然后在BookManagerService的onBind方法中做权限验证,如下所示:
1 | public IBinder onBind(Intent intent) { |
一个应用来绑定服务时,会验证这个应用的权限,如果它没有使用这个权限,onBind方法就会直接返回null,最终结果是这个应用无法绑定到我们的服务,这样就达到了权限验证的效果,这种方法同样适用于Messenger中。
如果我们自己内部的应用想要绑定到我们的服务中,只需要在它的AndroidMenifest文件中采用如下方式使用permission即可:
1 | <uses-permission android:name="com.example.wy521angel.ipctest.permission.ACCESS_BOOK_SERVICE"/> |
注意:服务端和客户端如果是两个工程,则在Service的onBind方法中无法验证客户端的权限。原因是onBind方法并不是一个Binder调用,它运行在服务端的UI线程中,故在onBind中只能验证服务端的权限,然而这是没有意义的。推荐使用下面的第二种方法,在onTransact方法中对客户端进行权限验证。
第二种方法,我们可以在服务端的onTranact方法中进行权限验证,如果验证失败就直接返回false,这样服务端就不会终止执行AIDL中的方法从而达到保护服务端的效果。至于具体的验证方式有很多,可以使用permission验证,具体实现方式和第一种方法一样。还可以采用Uid和Pid来做验证,通过getCallingUid和getCallingPid可以拿到客户端所属应用的Uid和Pid,通过这两个参数我们可以做一些验证工作,比如验证包名。下面的代码中,既验证了permission,又验证了包名。一个应用如果想远程调用服务中的方法,首先要使用我们自定义权限“com.example.wy521angel.ipctest.permission.ACCESS_BOOK_SERVICE”,其次包名必须以“com.example.wy521angel”开始,否则调用服务端的方法会失败。
1 | public boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException { |
上面介绍了两种AIDL中常用的权限验证方法,但是肯定还有其它方法可以做权限验证,比如为Service指定android:permission属性等。
参考资料:
《Android 开发艺术探索》任玉刚 第2章 2.4.4 使用AIDL