Messenger与AIDL的异同
最近做项目需要使用进程间通信，大家知道应用层的进程间通信无非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那样简洁的效果，也能满足同步获取返回值的问题，这个后面再说
