最近做项目需要使用进程间通信,大家知道应用层的进程间通信无非Broadcast,Activity,Service,Content Provider四大组件。Broadcast适用于一对多,我这里是一对一(子进程与主进程)的关系,且Broadcast性能较差,所以不用Broadcast。另外Content Provider主要用户本地持久化数据的通信,我这里主要是内存级别的数据,所以也不用Content Provider。Activity使用Intent进行进程间通信,使用的时候还需要start Activity,且不能持续通信,不能满足需求。剩下的只有Service了,而Service也恰恰是最合适的。
使用Service进行进程间通信,一种方法是start Service,这和start Activty一样,不用这种方法。另一种方法是bind service,这种可以持续通信,我们采用这种方式来进行进程间通信。
说到bind service进行进程间通信,大家都会想到AIDL(Android Interface Definition Language)和Messenger,那它们两个到底有什么异同,哪个更好用,更方便,效率更高呢,这是我接触到它们两个时的疑问,带着这个疑问,我稍稍的研究了一下它们两个,把研究的结果贴在这里,做个备份,以免下次再忘掉。
结论:
1. Messenger本质也是AIDL,只是进行了封装,开发的时候不用再写.aidl文件。
结合我自身的使用,因为不用去写.aidl文件,相比起来,Messenger使用起来十分简单。但前面也说了,Messenger本质上也是AIDL,故在底层进程间通信这一块,两者的效率应该是一样的。
2. 在service端,Messenger处理client端的请求是单线程的,而AIDL是多线程的。
使用AIDL的时候,service端每收到一个client端的请求时,就会启动一个线程(非主线程)去执行相应的操作。而Messenger,service收到的请求是放在Handler的MessageQueue里面,Handler大家都用过,它需要绑定一个Thread,然后不断poll message执行相关操作,这个过程是同步执行的。
3. client的方法,使用AIDL获取返回值是同步的,而Messenger是异步的。
Messenger只提供了一个方法进行进程间通信,就是send(Message msg)方法,发送的是一个Message,没有返回值,要拿到返回值,需要把client的Messenger作为msg.replyTo参数传递过去,service端处理完之后,在调用客户端的Messenger的send(Message msg)方法把返回值传递回client,这个过程是异步的,而AIDL你可以自己指定方法,指定返回值,它获取返回值是同步的。
其实,第二点是有办法解决的,在service端,Messenger的Handler可以只当作一个转发器,不处理请求,只转发请求到相应的处理线程(多是相应的HandlerThread),这样也可以达到异步的效果。
那我最后选用了什么呢?我选用了AIDL,主要是因为第三点Messenger无法满足需求,还有就是Messenger其实是封装了一下AIDL,我们也可以封装一下呀,既能实现Messenger那样简洁的效果,也能满足同步获取返回值的问题,这个后面再说