IPC小记Binder连接池

使用AIDL通信流程：
首先创建一个Service和一个AIDL接口，接着创建一个类继承AIDL接口中的Stub类并实现Stub中的抽象方法，在Service的onBind方法中返回这个类的对像，然后客户端就可以绑定服务端Service，建立连接后就可以访问远程服务端的方法了。
随着AIDL数量的增加我们不能无限制的增加Service，所以我们需要将所有的AIDL放在同一个Service去管理。
在这种模式下，整个工作机制是这样的：
每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节需要单独开，然后向服务端提供自己的唯一标示和相对应的Binder对像；对于服务器来说，只需要一个Service就可以了，服务端提供一个queryBinder接口，这个接口能够根据业务模块的特征来返回想对应的Binder对像给他们，不同的业务模块拿到所需Binder对像后就可以进行远程调用了。
选择合适的IPC
IPC方式根据不同的场景选择合适的方式

名称	优点	缺点	试用场景
Bundle	简单易用	只能传输Bundle支持的数据类型	四大组件间的进程间通信
文件共享	简单易用	不适合高并发场景，并且无法做到进程间的即时通信	无并发访问清醒，交换简单的数据实时性不高的场景
AIDL	功能强大，支持一对多并发通信，支持实时通信	使用稍复杂，需要处理好线程同步	一对多通信且有RPC需求
Messenger	功能一般，支持一对多串行通信，支持实时通信	不能很好地处理高并发情形不支持RPC，数据通过Message进行传输，因此只能传输Bundle支持的数据类型	低并发的一对多计时通信，无RPC需求，或者不需要返回结果的RPC需求
ContentProvider	在数据源访问方面功能强大，支持一对多并发数据共享，可通过Call方法扩展到其他操作	可以理解为受约束的AIDL，主要提供数据源的CRUD操作	一对多的进程间的数据共享
Socket	功能强大，可以通过网络传输字节流，支持一对多并发实时通信	实现稍微繁琐，不支持直接的RPC	网络数据交换