IPC方式（ContentProvider、Socket、Binder连接池）--《Android开发艺术探索》阅读笔记——第二章part4

一、ContentProvider

书中省略很多，建议阅读此系列文章：https://blog.csdn.net/harvic880925/article/details/44521461

二、Socket

建议阅读Socket详解：https://blog.csdn.net/carson_ho/article/details/53366856

三、Binder连接池

在本节中要再次介绍一下AIdL，原因是AIDL是一种最常用的进程间通信方式，是日常开发中涉及进程间通信时的首选，所以我们需要额外强调一下.

如何使用AIDL在上面的一节中已经进行了介绍，这里在回顾一下大致流程：首先创建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类并实现Stub中的抽象方法，在Service的onBind方法中返回这个类的对象，然后客户端就可以绑

定服务端Service，建立连接后就可以访问远程服务端的方法了。上述过程就是典型的AIDL的使用流程。

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

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

通过上面的理论介绍，也许还有点不好理解，下面对Binder连接池的代码实现做一说明。首先，为了说明问题，我们提供了两个AIDL接口（ISecurityCenter和ICompute）来模拟上面提到的多个业务模块都要使用AIDL的情况，其中ISecurityCenter接口提供解密功能，声明如下：

interface ISecurityCenter {
    String encrypt(String content);
    String decrypt(String password);
}

而ICompute提供了计算加法的功能：

interface ICompute {
    int add(int a,int b);
}

接下来我们来看一下两个AIDL的实现：

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);
    }
}

public class ComputeImpl extends ICompute.Stub {

    @Override
    public int add(int a, int b) throws RemoteException {
        return a + b;
    }
}

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

interface IBinderPool {

    IBinder queryBinder(int binderCode);
}

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

public static class BinderPoolImpl extends IBinderPool.Stub{

        public BinderPoolImpl(){
            super();
        }

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

远程service的实现比较简单，如下：

public class BinderPoolService extends Service{

    private  static final String  TAG = "BinderPoolService";

    private Binder mBinderPool = new BinderPool.BinderPoolImpl();

    @Override
    public void onCreate() {
        super.onCreate();
    }

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

    @Override
    public void onDestroy() {
        super.onDestroy();
    }
}

下面还剩下Binder连接池的具体实现了，在他的内部首先他要去绑定远程服务，绑定成功后，客户端就课堂通过他的queryBinder方法来获取对应的Binder，拿到所需的Binder之后，不同业务模块就可以各自操作了。（其实这里可以不用封装BinderPool，就正常在客户端BindService即可，然后调用服务，即通过code获取对用Binder。只不过这里封装BinderPool后，客户端使用会很简洁。）

public class BinderPool {

    private static final String TAG = "BinderPool";
    public static final int BINDER_NONE = -1;
    public static final int BINDER_COMPUTE = 0;
    public static final int BINDER_SECURUITY_CENTER = 1;

    private Context mContext;
    private IBinderPool mIBinderPool;
    private static volatile BinderPool sInstance;
    private CountDownLatch mConnectBinderPoolCopuntDownLacth;

    private BinderPool(Context context) {
        mContext = context.getApplicationContext();
        connectBinderPoolService();
    }

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

    private synchronized void connectBinderPoolService() {
        mConnectBinderPoolCopuntDownLacth = new CountDownLatch(1);
        Intent service = new Intent(mContext, BinderPoolService.class);
        mContext.bindService(service, mBinderPoolConnection, Context.BIND_AUTO_CREATE);
        try {
            mConnectBinderPoolCopuntDownLacth.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public IBinder queryBinder(int binderCode) {
        IBinder binder = null;
        try {
            if (mIBinderPool != null) {
                binder = mIBinderPool.queryBinder(binderCode);
            }
        } catch (RemoteException e) {
            e.printStackTrace();
        }
        return binder;
    }

    private ServiceConnection mBinderPoolConnection  = 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();
            }
            mConnectBinderPoolCopuntDownLacth.countDown();
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

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

    public static class BinderPoolImpl extends IBinderPool.Stub{

        public BinderPoolImpl(){
            super();
        }

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

Binder连接池就具体的分析完了，他的好处显而易见，针对上面的例子，我们只需要创建一个Service就可以完成多个AIDL的工作，我们现在可以来验证一下他的功能，新创建一个Activity，在线程中执行如下的操作：

public class BinderActivity extends AppCompatActivity{

    private ISecurityCenter mSecurityCenter;
    private ICompute mCompute;

    @Override
    protected void onCreate( Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_binder);

        new Thread(new Runnable() {
            @Override
            public void run() {
                dowork();
            }
        }).start();
    }

    private void dowork() {
        BinderPool binderPool = BinderPool.getInstance(BinderActivity.this);
        IBinder securityBinder = binderPool.queryBinder(BinderPool.BINDER_SECURUITY_CENTER);
        mSecurityCenter = SecurityCenterImpl.asInterface(securityBinder);
        String msg = "Android";
        try {
            String password = mSecurityCenter.encrypt(msg);
            System.out.print(mSecurityCenter.decrypt(password));
        } catch (RemoteException e) {
            e.printStackTrace();
        }

        IBinder computeBinder =  binderPool.queryBinder(BinderPool.BINDER_COMPUTE);
        mCompute = ComputeImpl.asInterface(computeBinder);
        try {
            System.out.print(mCompute.add(3,5));
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }
}

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

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

注：以上是书中对Binder连接池的详解。在认识Binder连接池之前，我所在的项目，也是有AIDL接口，刚好我就做了其中两个，当时就直接写两个对应的Service，结果后来被Reviewer建议用一个Service就可以，具体做法是：在Service的onBinder()返回Binder时，根据intent（bindService传递过来的）中携带的action区分是想要得到哪一个AIDL的Binder，并维护一个map，key就是action，value是Binder。这个很简单，也可以考虑使用。

四、选择合适的IPC方式

另外，