IPC机制-Android中的IPC方式三-Binder连接池、选用合适的IPC方式

有人说，一个男人变老的两大标志是不断后退的发际线和不断增长的腰围；其实，一个人真正变老的标志是，他觉得人生一眼望得到头，不会再有改变，于是放弃了学习，放弃了提升自己

Binder连接池

就IPC机制系列中，我们介绍了不同的IPC方式，不同的IPC方式有不同的特点和适用场景。在该节中我们再次介绍一下AIDL，原因是AIDL是一种最常见的进程间通信方式，是日常开发中涉及进程间通信时的首选，所以我们需要额外强调一下它。

如何使用AIDL在IPC机制-Android中的IPC方式一-Bundle、文件共享、Messenger、AIDL中进行了介绍，这里再回顾一下大致的流程：首先，创建一个Service和一个AIDL接口；接着，创建一个类继承自AIDL接口中的Stub类并实现其抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑定服务端的Service，建立连接后就可以访问远程服务端的方法了。

上述过程就是典型的AIDL的使用流程。这本没什么问题，但是现在考虑一种情况：公司的项目越来越庞大了，现在有10个不同的业务模块都需要使用AIDL来进行进程间通信，那我们该怎么办呢？也许你会说：“就按照AIDL的实现方式一个个来嘛”，这也不是不可以，但是用这种方法的话，首先我们需要创建10个Service，这好像有点多哈！如果有100个地方需要用到AIDL呢？那你就得先创建100个Service咯？到这里，我们应该明白问题所在了。随着AIDL数量的增加，我们不能无限制地增加Service，Service是四大组件之一，本身就是一种系统资源。而且开启太多的Service会使得我们的应用看起来很重量级，因为正在运行的Service可以在应用详情页看到，当我们的应用详情显示有10个服务正在运行时，这看起来不是件好事。针对上述问题，需要减少Service的数量，将所有的AIDL放在同一个Service中去管理。

在这种模式下，整个工作机制是这样的：每个业务模块创建自己的AIDL接口并实现此接口，这个时候不同业务模块之间是不能有耦合的，所有实现细节我们要单独开来，然后向服务端提供自己的唯一标识和其对应的Binder对象；对于服务端来说，只需要一个Service就可以了，服务端提供一个queryBinder接口方法，这个接口方法能够根据业务模块的特征来返回相应的Binder对象给它们，不同的业务模块拿到所需的Binder对象后就可以进行远程方法调用了。由此可见，Binder连接池的主要作用就是将每个业务模块的Binder请求统一转发到远程Service中去执行，从而避免了重复创建Service的过程，它的工作原理如图：

通过上面的介绍，下面就Binder连接池的代码实现做一下说明。

首先，提供两个AIDL接口（ISecurityCenter和ICompute）来模拟上面提到的多个业务模块都要使用AIDL的情况，其中ISecurityCenter接口提供加解密功能，声明如下：

package com.zaenlove.androiddemo2.binderpool;
interface ISecurityCenter {
    String encrypt(String content);
    String decrypt(String password);
}

在ICompute接口提供计算加法的功能，声明如下：

package com.zaenlove.androiddemo2.binderpool;
interface ICompute{
    int add(int a, int b);
}

接着看一下上面两个AIDL接口的实现，代码如下：

SecurityCenterImpl：

public class SecurityCenterImpl extends ISecurityCenter.Stub {
private static final char SECRET_CODE = '^';
    @Override
    public String encrypt(String content) throws RemoteException {
        char[] chars = content.toCharArray();
        for(int i=0; i<chars.length; i++) {
            chars[i] ^= SECRET_CODE;
        }
        return new String(chars);
    }
    @Override
    public String decrypt(String password) throws RemoteException {
        return encrypt(password);
    }
}

ComputeImpl：

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

现在业务模块的AIDL接口定义和实现都已经完成了，注意这里并没有为每个模块的AIDL单独创建Service，接下来就是服务端和Binder连接池的工作了。

首先，为Binder连接池创建AIDL接口IBinderPool.aidl，代码如下所示：

1
2
3

interface IBinderPool{
    IBinder queryBinder(int binderCode);
}

接着，为Binder连接池创建远程Service并实现IBinderPool，下面是queryBinder的具体实现，可以看到请求转发的实现方法，当Binder连接池连接上远程服务时，会根据不同模块的标识即binderCode返回不同的Binder对象，通过这个Binder对象所执行的操作全部发生在远程服务端。

@Override
public IBinder queryBinder(int binderCode) throws RemoteException {
    IBinder binder = null;
    switch(binderCode) {
    case BINDER_SECURITY_CENTER: {
        binder = new SecurityCenterImpl();
        break;
    }
    case BINDER_COMPUTE: {
        binder = new ComputeImpl();
    }
    default:
        break;
    }
    return binder;
}

远程Service的实现代码如下所示：

public class BinderPoolService extends Service {
    private Binder mBinderPool = new BinderPool.BinderPoolImpl();
    @Override
    public IBinder onBind(Intent intent) {
        Log.e("---->", "onBind");
        return mBinderPool;
    }
    @Override
    public void onCreate() {
        super.onCreate();
    }
    @Override
    public void onDestroy() {
        super.onDestroy();
    }
}

下面还剩下Binder连接池的具体实现，在它的内部首先它要去绑定远程服务，绑定成功后，客户端就可以通过它的queryBinder方法去获取各自对应的Binder，拿到所需的Binder以后，不同业务模块就可以进行各自的操作了，Binder连接池的代码如下所示：

public class BinderPool {
    private Context mContext;
    private CountDownLatch mConnectBinderPoolCountDownLatch;
    private static volatile BinderPool mInstance;
    private IBinderPool mBinderPool;
    public static final int BINDER_SECURITY_CENTER = 1;
    public static final int BINDER_COMPUTE = 0;
    public static final int BINDER_NONE = -1;
    private BinderPool(Context context) {
        mContext = context.getApplicationContext();
        connectBinderPoolService();
    }
    public static BinderPool getInstance(Context context){
        if(mInstance == null) {
            synchronized(BinderPool.class) {
                if(mInstance == null) {
                    mInstance = new BinderPool(context);
                }
            }
        }
        return mInstance;
    }
    private synchronized void connectBinderPoolService() {
        mConnectBinderPoolCountDownLatch = new CountDownLatch(1);
        Intent service = new Intent(mContext, BinderPoolService.class);
        mContext.bindService(service, mBinderPoolConnection, Context.BIND_AUTO_CREATE);
        try {
            mConnectBinderPoolCountDownLatch.await();
        }catch(InterruptedException e){
            e.printStackTrace();
        }
    }
    public IBinder queryBinder(int binderCode) {
        IBinder binder = null;
        try {
            if(mBinderPool != null) {
                binder = mBinderPool.queryBinder(binderCode);
            }
        } catch (RemoteException e) {
            e.printStackTrace();
        }
        return binder;
    }
    private ServiceConnection mBinderPoolConnection = new ServiceConnection(){
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            mBinderPool = IBinderPool.Stub.asInterface(service);
            try {
                mBinderPool.asBinder().linkToDeath(mBinderPoolDeathRecipient, 0);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
            mConnectBinderPoolCountDownLatch.countDown();
        }
        @Override
        public void onServiceDisconnected(ComponentName name) {
            //ignored.
        }
    };
    private IBinder.DeathRecipient mBinderPoolDeathRecipient = new IBinder.DeathRecipient() {
        @Override
        public void binderDied() {
            Log.e("---->", "binder died.");
            mBinderPool.asBinder().unlinkToDeath(mBinderPoolDeathRecipient, 0);
            mBinderPool = null;
            connectBinderPoolService();
        }
    };
    public static class BinderPoolImpl extends IBinderPool.Stub {
        @Override
        public IBinder queryBinder(int binderCode) throws RemoteException {
            IBinder binder = null;
            switch(binderCode) {
            case BINDER_SECURITY_CENTER: {
                binder = new SecurityCenterImpl();
                break;
            }
            case BINDER_COMPUTE: {
                binder = new ComputeImpl();
            }
            default:
                break;
            }
            return binder;
        }
    }
}

Binder连接池的具体实现就已经分析完了，针对上面的例子，我们只需要创建一个Service即可完成多个AIDL接口的工作，下面来验证一下效果。新建一个Activity，在线程中执行如下操作：

protected void doWork() {
    BinderPool binderPool = BinderPool.getInstance(BinderPoolActivity.this);
    IBinder securityBinder = binderPool.queryBinder(BinderPool.BINDER_SECURITY_CENTER);
    mSecurityCenter = SecurityCenterImpl.asInterface(securityBinder);
    Log.e("---->","visit ISecurityCenter...");
    String msg = "hello world 中国";
    Log.e("---->","Content: "+msg);
    try {
        String password = mSecurityCenter.encrypt(msg);
        Log.e("---->","encrypt: "+password);
        Log.e("---->","decrypt: "+mSecurityCenter.decrypt(password));
    } catch (RemoteException e) {
        e.printStackTrace();
    }
    Log.e("---->","visit ICompute...");
    IBinder computeBinder = binderPool.queryBinder(BinderPool.BINDER_COMPUTE);
    mCompute = ComputeImpl.asInterface(computeBinder);
    try {
        Log.e("---->","8 + 8 = "+mCompute.add(8, 8));
    } catch (RemoteException e) {
        e.printStackTrace();
    }
}

运行程序，查看log：

这里需要额外说明一下，为什么要在线程中去执行呢？

这是因为在Binder连接池的实现中，我们通过CountDownLatch将bindService这一异步操作转换成了同步操作，这就意味着它有可能是耗时的，然后就是Binder方法的调用过程也可能是耗时的，因此不建议放在主线程去执行。注意到BinderPool是一个单例实现，因此在同一个进程中只会初始化一次，所以如果我们提前初始化BinderPool，那么可以优化程序的体验，比如我们可以放在Application中提前对BinderPool进行初始化，虽然这不能保证当我们调用BinderPool时它一定是初始化好的，但是在大多数情况下，这种初始化工作（绑定远程服务）的时间开销（如果BinderPool没有提前初始化完成的话）是可以接受的。另外，BinderPool中有断线重连的机制，当远程服务意外的终止时，BinderPool会重新建立连接，这个时候如果业务模块中的Binder调用出现了异常，也需要手动去重新获取最新的Binder对象，这个是需要注意的。

有了BinderPool可以大大方便日常的开发工作，比如如果有一个新的业务模块需要添加新的AIDL，那么在它实现了自己的AIDL接口后，只需要修改BinderPoolImpl中的queryBinder方法，给自己添加一个新的binderCode并返回对应的Binder对象即可，不需要做其他修改，也不需要创建新的Service。由此可见，BinderPool能够极大地提高AIDL的开发效率，并且可以避免大量的Service创建，因此，建议在AIDL开发工作中引入BinderPool机制。