典型的AIDL使用流程：首先创建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类并实现Stub中的抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑定服务端Service，建立连接后就可以访问远程服务端的方法了。
一：为什么需要Binder线程池
产生原因：因为当有多个不同的业务块都要使用AIDL来进行通信，则需要创建多个Service，没创建一个Service就需要消耗系统资源。
解决思路：将所有的AIDL放在一个Service中处理。
二、使用
主要作用：将每个业务的AIDL请求统一转发给一个Service，避免Service的重建。
假设有两个AIDL：
创建BinderPool连接池
1.单例模式：整个App只能创建一个对象
2.创建IBinderPool的静态类：重写接口
3.创建该类时候，自动连接Service
4.创建queryBinder()方法，能够调用IBinderPool的queryBinder()（因为服务器返回的Binder在BinderPool中）
public class BinderPool {
//客户端通过标识符，获取相对应的Binder
private static final StringTAG ="BinderPool";
public static final int BINDER_NONE = -1;
public static final int BINDER_SECURITY =0;
public static final int BINDER_COMPTURE =1;
private static BinderPoolsBinderPool;
private static ContextmContext;
private IBinderPoolmIBinderPool;
private static volatile BinderPoolsInstance;
private CountDownLatchmConnectBinderPoolCountDownLatch;
/*单例模式，在整个app中只会产生一个对象*/
private BinderPool(Context context) {
mContext = context.getApplicationContext();
// connectService();
connnectBinderPoolService();
}
public static BinderPoolgetInstance(Context context) {
synchronized (BinderPool.class) {
if (sBinderPool ==null) {
sBinderPool =new BinderPool(context);
}
}
return sBinderPool;
}
private synchronized void connnectBinderPoolService() {
mConnectBinderPoolCountDownLatch =new CountDownLatch(1);
Intent intent =new Intent(mContext, BinderPoolService.class);
mContext.bindService(intent, mBinderPoolConnection, Context.BIND_AUTO_CREATE);
try {
mConnectBinderPoolCountDownLatch.await();
}catch (InterruptedException e) {
e.printStackTrace();
}
}
/*因为客户端没法收到从Service发送过来的Binder，利用该方法来执行Binder的方法*/
public IBinderqueryBinder(int binderCode) {
IBinder binder =null;
if (mIBinderPool !=null) {
try {
binder =mIBinderPool.queryBinder(binderCode);
}catch (RemoteException e) {
e.printStackTrace();
}
}
return binder;
}
private ServiceConnectionmBinderPoolConnection =new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
mIBinderPool = IBinderPool.Stub.asInterface(service);
try {
mIBinderPool.asBinder().linkToDeath(mBinderPoolDeathRecipient, 0);
}catch (RemoteException e) {
e.printStackTrace();
}
mConnectBinderPoolCountDownLatch.countDown();
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
private IBinder.DeathRecipientmBinderPoolDeathRecipient =new IBinder.DeathRecipient() {
@Override
public void binderDied() {
Log.w("BinderPool", "binder died.");
mIBinderPool.asBinder().unlinkToDeath(mBinderPoolDeathRecipient, 0);
mIBinderPool =null;
}
};
/*继承IBinderPool接口，重写方法*/
public static class BinderPoolImplextends IBinderPool.Stub {
public BinderPoolImpl() {
super();
}
@Override
public IBinderqueryBinder(int binderCode)throws RemoteException {
IBinder binder;
switch (binderCode) {
case BINDER_COMPTURE:
binder =new ComputeImpl();
break;
case BINDER_SECURITY:
binder =new SecurityConterImpl();
break;
default:
binder =null;
break;
}
return binder;
}
}
}
总结:IPC方式的优缺点和适用场景
Bundle：优点->简单易用 ; 缺点->只能传输Bundle支持的数据类型 ; 适用场景->四大组件间的进程通信。
文件共享：优点->简单易用 ; 缺点->不适合高并发场景，并且无法做到进程间的即时通信 ; 适用场景->无并发访问情形，交换简单的数据实时性不高的场景。
AIDL：优点->功能强大，支持一对多并发通信，支持实时通信 ; 缺点->使用稍复杂，需要处理好线程同步 ; 适用场景->一对多通信且有RPC（Remote Procedure Call Protocol）需求。
Messenger：优点->功能一般，支持一对多串行通信，支持实时通信 ; 缺点->不能很好处理高并发情形，不支持PRC，数据通过Message进行传输，因此只能传输Bundle支持的数据类型 ; 适用场景->低并发的一对多即时通信，无PRC需求，或者无须要返回结果的RPC需求。
ContentProvider：优点->在数据源访问方面功能强大，支持一对多并发数据共享，可通过Call方法扩展其他的操作 ; 缺点->可理解为受约束的AIDL，主要提供数据源的CRUD操作; 适用场景->一对多进程间的数据共享。
SoCket：优点->功能强大，可以通过网络传输字节流，支持一对多并发实时通信，支持实时通信 ; 缺点->实现细节稍微有点繁琐，不支持直接的RPC ; 适用场景->网络数据交换。