本文代码：Github

先说说问题吧，AIDL需要一个客户端和一个服务端，服务端往往是一个service，但是这样就会有问题，当团队多了，模块多了，每个模块自己一个service，显然这样是很坑爹的。所以，引入Binder连接池。

一、实现思路

Binder连接池原理.png

对于每个AIDL接口，分别实现对应的Binder，统一一个service，然后每次bind service的时候，通过一个连接池来进行Binder分发，queryBinder里面通过请求的code来决定分配哪个Binder。这样，就可以避免随着项目模块的增多，service变多，每次有新模块接口增加的时候，只需要在queryBinder里的switch新加一个case判断即可，且能实现模块间的解耦和service与模块具体实现之间的解耦，一举两得。

二、从零开始实现Binder连接池

创建两个AIDL。

// IUser.aidl
package com.cm.mybinderpool;

interface IUser {
    boolean login(String username, String password);
}

// ICompute.aidl
package com.cm.mybinderpool;

interface ICompute {
    int add(int x, int y);
}

然后分别实现对应的Binder。

public class UserImpl extends IUser.Stub {
    @Override
    public boolean login(String username, String password) throws RemoteException {
        return true;
    }
}

public class ComputeImpl extends ICompute.Stub {
    @Override
    public int add(int x, int y) throws RemoteException {
        return x + y;
    }
}

现在还比较简单。接下来就是我们的BinderPool，先新建一个AIDL接口，里面只有一个queryBinder方法。

// IBinderPool.aidl
package com.cm.mybinderpool;

interface IBinderPool {
    IBinder queryBinder(int binderCode);
}

实现BinderPool。
首先，既然是个线程池，就应该是个单例模式。这里采用双重检查锁实现。单例获取的时候需要传入上下文context，主要是之后bind服务的时候，需要用到上下问信息。

private static volatile BinderPool sInstance;
private Context mContext;

private BinderPool(Context context) {
    mContext = context;
}

public static BinderPool getInstance(Context context) {
    if (sInstance == null) {
        synchronized (BinderPool.class) {
            if(sInstance == null) {
                sInstance = new BinderPool(context);
            }
        }
    }
    return sInstance;
}

实现binder分发，即IBinderPool的queryBinder接口，实现比较简单，就是switch-case判断。

//binder code
public static final int BINDER_USER = 0;
public static final int BINDER_COMPUTE = 1;

public static class BinderPoolImpl extends IBinderPool.Stub {
    @Override
    public IBinder queryBinder(int binderCode) throws RemoteException {
        switch (binderCode) {
            case BINDER_COMPUTE:
                return new ComputeImpl();
            case BINDER_USER:
                return new UserImpl();
            default:
                return null;
        }
    }
}

好了，接下来要创建对应的service了。这里返回IBinderPool的Binder。

public class BinderPoolService extends Service {
    public BinderPoolService() {
    }

    Binder binderPool = new BinderPool.BinderPoolImpl();

    @Override
    public IBinder onBind(Intent intent) {
        return binderPool;
    }
}

线程池作用除了进行binder的分发外，还有就是service的连接。
连接是在初始化的时候进行。

private BinderPool(Context context) {
    mContext = context;
    connectService();
}

connectService即完成连接。
这里会用到Java的CountDownLatch，CountDownLatch是通过一个计数器来实现的，计数器的初始值为线程的数量，每当一个线程完成了自己的任务后，计数器的值就会减1。当计数器值到达0时，它表示所有的线程已经完成了任务，然后在闭锁上等待的线程就可以恢复执行任务。与CountDownLatch的第一次交互是主线程等待其他线程。主线程必须在启动其他线程后立即调用CountDownLatch.await()方法。这样主线程的操作就会在这个方法上阻塞，其他线程完成后通知主线程，通过CountDownLatch.countDown()来使得值减1，因为binderservice回调之后主线程才能继续，所以这里用CountDownLatch来实现。

private CountDownLatch mConnectBinderPoolCountDownLatch;
private IBinderPool mBinderPool;

private void connectService() {
    mConnectBinderPoolCountDownLatch = new CountDownLatch(1);
    Intent intent = new Intent(mContext, BinderPoolService.class);
    mContext.bindService(intent, conn, Context.BIND_AUTO_CREATE);
    try {
        mConnectBinderPoolCountDownLatch.await();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
}

ServiceConnection conn = new ServiceConnection() {
    @Override
    public void onServiceConnected(ComponentName componentName, IBinder iBinder) {
        mBinderPool = IBinderPool.Stub.asInterface(iBinder);
        mConnectBinderPoolCountDownLatch.countDown();
    }

    @Override
    public void onServiceDisconnected(ComponentName componentName) {

    }
};

这里再为Binder设置一下死亡监听。在服务连接成功之后，得到binder，利用iBinder.linkToDeath(mBinderPoolDeathRecipient, 0)，当连接池发现服务断开的时候，需要重新去连接服务，保持长连接。

private IBinder.DeathRecipient mBinderPoolDeathRecipient = new IBinder.DeathRecipient() {
    @Override
    public void binderDied() {
        mBinderPool.asBinder().unlinkToDeath(mBinderPoolDeathRecipient, 0);
        mBinderPool = null;
        connectService();
    }
};

然后，我们要在BinderPool中提供最重要的分发接口出去。

public IBinder queryBinder(int code) {
    if(mBinderPool == null) {
        return null;
    }
    try {
        return mBinderPool.queryBinder(code);
    } catch (RemoteException e){
        e.printStackTrace();
    }
    return null;
}

这里去掉用了service的queryBinder方法，然后具体实现还是在BinderPool当中，这样使用过程全部和BinderPool类打交道而不和service打交道了。

好了，这样就实现了我们的Binder连接池了，现在我们来使用一下它。
在我们的MainActivity中，调用的时候是一个耗时操作，所以需要另开一个线程进行，否则会阻塞UI线程，造成ANR。怎么开线程就不说了，直接线程具体调用的方法。

private void testBinderPool() {
    BinderPool mBinderPool = BinderPool.getInstance(MainActivity.this);
    //测试ICompute
    IBinder mComputeBinder = mBinderPool.queryBinder(BinderPool.BINDER_COMPUTE);
    ICompute mCompute = ICompute.Stub.asInterface(mComputeBinder);
    try {
        Log.i("chenming", "1+2 = " + mCompute.add(1, 2));
    } catch (RemoteException e) {
        e.printStackTrace();
    }
    
    //测试IUser
    IBinder mUserBinder = mBinderPool.queryBinder(BinderPool.BINDER_USER);
    IUser mUser = IUser.Stub.asInterface(mUserBinder);
    try {
        Log.i("chenming", "login " + mUser.login("user", "psd"));
    } catch (RemoteException e) {
        e.printStackTrace();
    }
}

运行一下，可以看见运行结果log。

05-30 16:38:28.964 32108 32132 I chenming: 1+2 = 3
05-30 16:38:28.965 32108 32132 I chenming: login true

三、回顾

整个过程其实客户端都是和BinderPool进行打交道的，BinderPool是个单例，主要是由于访问过程是个并发的过程，如果有两个BinderPool实例的话会出现非常多不可控的问题。BinderPool与Service打交道，BinderPool给客户端其实只提供了两个接口，一个是getInstance用以获取实例，一个是queryBinder进行binder分发。

getInstance的时候，如果实例还未初始化，则马上new一个实例，同时也开始了service的连接，连接service之后，保持连接状态，所以需要去监听Binder的死亡。

连接成功后，获取到对应IBinderPool的Binder实例。这个Binder类的具体实现还是在BinderPool当中。

下次要新模块添加AIDL的时候就很简单了，修改BinderPool里面增加一个code，然后在queryBinder中添加一个case分路进行实例化即可。