android|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的使用流程。
【android|IPC方式(ContentProvider、Socket、Binder连接池)--《Android开发艺术探索》阅读笔记——第二章part4】这本来也没什么问题,但是现在考虑一种情况;公司的项目越来越庞大了,现在有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的过程,它的工作原理如图所示。
android|IPC方式(ContentProvider、Socket、Binder连接池)--《Android开发艺术探索》阅读笔记——第二章part4
文章图片


通过上面的理论介绍,也许还有点不好理解,下面对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 staticfinalchar 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{privatestatic final StringTAG = "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方式




android|IPC方式(ContentProvider、Socket、Binder连接池)--《Android开发艺术探索》阅读笔记——第二章part4
文章图片






另外,

android|IPC方式(ContentProvider、Socket、Binder连接池)--《Android开发艺术探索》阅读笔记——第二章part4
文章图片





    推荐阅读