利用AIDL方式能很方便地进行客户端和服务端的跨进程通信。但是，我们想一下，如果按照我们之前的使用方法，必须满足一个AIDL接口对应一个service，那么问题来了，假如我们的应用，有很多业务场景，而每一个业务场景都需要和服务端通讯，那么我们也要为每一个模块创建特定的aidl文件，那么服务端service也会产生很多个，显然，如果aidl接口变多，那么service也会跟着变多，我们不可能无限制或者大量的增加service，因为service 本身就是一种系统资源，太多的service 让我们的应用看起来很复杂，那么我们该怎么做呢？在任玉刚著的《Android 开发艺术探索》一书中，给出了一个Binder连接池的概念，即利用一个Binder连接池来管理所有Binder，服务端只需要管理这个Bindere连接池即可，这样就能实现一个service管理多个Binder，为不同的模块返回不同的Binder，以实现进程间通讯。所以，本文将讲述如何实现Binder连接池。
通过这一张图起始很好的反映了多个aidl 在一个service 下管理的运作方式。每一个业务模块都创建自己的AIDL 文件，并实现。向服务端提供唯一的标识和自身的binder对象；对于服务端来说，只需要一个service，并且向客户端提供 queryBinder 的方法，客户端去根据唯一的标识查询不同的Binder 对象，这样不同的客户端就可以使用不同的Binder 对象去进行IPC 操作了。避免重复多次创建service.
为了说明情况，通过代码demo 的形式来进行演示。
创建两个aidl
IComputeAdd.aidl
interface IComputeAdd {
int add(int a, int b);
}
IComputeSub.aidl
interface IComputeSub {
int sub(int a, int b);
}
分别实现其对应的 实现类:
public class ComputeAddImpl extends IComputeAdd.Stub {
@Override
public int add(int a, int b) throws RemoteException {
return a+b;
}
}
public class ComputeSubImpl extends IComputeSub.Stub {
@Override
public int sub(int a, int b) throws RemoteException {
return a-b;
}
}现在各个业务的模块和需求代码都已经搞定了，我们并没有对应不同的逻辑去创建对应的service，现在我们需要提供一个用来查询binder 的AIDL，专门用来进行binder 的查询工作。
IBinderPool.aidl
interface IBinderPool {
IBinder queryBinder(int binderCode);
}
接着创建这个IBinderPool 的查询方法
从上面可以看到，使用了不同Binder 的标识去创建不同的Binder 对象。
然后实现这个AIDL 对象的service 方法，是用来查询所有binder 统一管理的service
public class BinderPoolService extends Service {
private Binder mBinderPool = new BinderPool.BinderPoolImpl(); // 动态选择Binder
@Nullable
@Override
public IBinder onBind(Intent intent) {
return mBinderPool;
}
}
接下来就是Binder 连接池的具体实现：
public class BinderPool {
// 编译器每次都需要从主存中读取
private IBinderPool mBinderPool;
private Context mContext;
private CountDownLatch mCountDownLatch; // 同步机制
public static volatile BinderPool sInstance;
public static final int BINDER_COMPUTE_ADD = 0;
public static final int BINDER_COMPUTE_SUB = 1;
// 单例
public static BinderPool getInstance(Context context) {
if (sInstance == null) {
synchronized (BinderPool.class) {
if (sInstance == null) {
sInstance = new BinderPool(context);
}
}
}
return sInstance;
}
private BinderPool(Context context) {
mContext = context.getApplicationContext();
connectBinderPoolService();
}
// 连接服务池
private synchronized void connectBinderPoolService() {
mCountDownLatch = new CountDownLatch(1); // 只保持一个绑定服务
Intent service = new Intent(mContext, BinderPoolService.class);
mContext.bindService(service, mBinderPoolConnection, Context.BIND_AUTO_CREATE);
try {
mCountDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// 失效重联机制, 当Binder死亡时, 重新连接
private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
@Override public void binderDied() {
Log.e("zx - debug:", "Binder失效");
mBinderPool.asBinder().unlinkToDeath(mDeathRecipient, 0);
mBinderPool = null;
connectBinderPoolService();
}
};
// Binder的服务连接
private ServiceConnection mBinderPoolConnection = new ServiceConnection() {
@Override public void onServiceConnected(ComponentName name, IBinder service) {
mBinderPool = IBinderPool.Stub.asInterface(service);
try {
Log.d("zx - debug:", "onServiceConnected");
mBinderPool.asBinder().linkToDeath(mDeathRecipient, 0);
} catch (RemoteException e) {
e.printStackTrace();
}
mCountDownLatch.countDown();
}
@Override public void onServiceDisconnected(ComponentName name) {
}
};
/**
* 查询Binder
*
* @param binderCode binder代码
* @return Binder
*/
public IBinder queryBinder(int binderCode) {
IBinder binder = null;
try {
if (mBinderPool != null) {
binder = mBinderPool.queryBinder(binderCode);
}
} catch (RemoteException e) {
e.printStackTrace();
}
return binder;
}
/**
* Binder池实现
*/
public static class BinderPoolImpl extends IBinderPool.Stub {
@Override
public IBinder queryBinder(int binderCode) throws RemoteException {
IBinder binder = null;
switch (binderCode) {
case BINDER_COMPUTE_ADD:
binder = new ComputeAddImpl();
break;
case BINDER_COMPUTE_SUB:
binder = new ComputeSubImpl();
break;
default:
break;
}
return binder;
}
}
}其中每一个的方法的含义已经在代码中进行了注释。
额外需要说明的是 connectBinderPoolService 中 mCountDownLatch.await(); 方法
这个方法主要用于客户端与服务端建立连接，在方法内部出现了CountDownLatch类，这个类是用于线程同步的，由于bindService()是异步操作，所以如果要确保客户端在执行其他操作之前已经绑定好服务端，就应该先实现线程同步(所以在系统 bindService 完成后回调serviceConnection 的时候进行countDown)。 这里简单提一下这个类：
CountDownLatch 类有三个主要方法：
(1)构造方法 CountDownLatch(int num)：这里传递一个num值，为countdownlatch内部的计时器赋值。
(2)countdown():每当调用一次这个方法，countdownlatch实例内部计时器数值 - 1。
(3)await():让当前线程等待，如果内部计时器变为0，那么唤醒当前线程。
另外 注意到，ServiceConnection方法内部执行了mBinderPool = IBinderPool.Stub.asInterface(service)方法，这里的mBinderPool实际上是IBinderPool的一个代理对象，即此时客户端获得了服务端Binder连接池的一个代理对象。
学习到这里，在记录一下asBinder 和 asInterface 的区别。
asBinder ：
顾名思义，用于返回当前 Binder对象。在 Stub类 里面（也就是本进程）直接就是 Binder本地对象，
@Override
public android.os.IBinder asBinder() {
return this;
}在 Proxy类 里面返回的是远程代理对象(Binder代理对象)
@Override
public android.os.IBinder asBinder() {
return mRemote;
}asInterface ：
用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的（如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象）
下面进行客户端的调用：
public void onClickAdd(View v){
new Thread(new Runnable() {
@Override public void run() {
addResult();
}
}).start();
}
private void addResult(){
BinderPool binderPool = BinderPool.getInstance(getApplicationContext());
IBinder computeBinderAdd = binderPool.queryBinder(BinderPool.BINDER_COMPUTE_ADD);
mComputeAdd = ComputeAddImpl.asInterface(computeBinderAdd);
try {
int res = mComputeAdd.add(5,3);
Message msg = new Message();
msg.what = BinderPool.BINDER_COMPUTE_ADD;
msg.arg1 = res;
mHadler.sendMessage(msg);
} catch (RemoteException e) {
e.printStackTrace();
}
}这里看一下加的方法，减法类似，不赘述了。最终通过BInder 池进行 query 动态返回Binder对象，执行不同对象的方法。