### 2.5 Binder连接池
上面我们介绍了不同的IPC方式，我们知道，不同的IPC方式有不同的特点和适用场景，当然这个问题会在2.6节进行介绍，在本节中要再次介绍一下ADIL，**原因是AIDL是一种最常用的进程间通信方式，是日常开发中涉及进程间通信时的首选**，所以我们需要额外强调一下它。
如何使用AIDL在上面的一节中已经进行了介绍，这里在回顾一下大致流程：**首先创建一个Service和一个AIDL接口，接着创建一个类继承自AIDL接口中的Stub类并实现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的过程**，它的工作原理如图2-10所示。
:-: 
图2-10 Binder连接池的工作原理
通过上面的理论介绍，也许还有点不好理解，下面对Binder连接池的代码实现做一下说明。
首先，为了说明问题，我们提供了**两个AIDL接口（ISecurityCenter和ICompute）来模拟上面提到的多个业务模块都要使用AIDL的情况**，其中**ISecurityCenter接口提供加解密功能**，声明如下：
~~~
package com.ryg.chapter_2.binderpool;
interface ISecurityCenter {
String encrypt(String content);
String decrypt(String password);
}
~~~
而**ICompute接口提供计算加法的功能**，声明如下：
~~~
package com.ryg.chapter_2.binderpool;
interface ICompute {
int add(int a, int b);
}
~~~
虽然说上面两个接口的功能都比较简单，但是用于分析Binder连接池的工作原理已经足够了，读者可以写出更复杂的例子。
接着看一下上面两个AIDL接口的实现，也比较简单，代码如下：
**SecurityCenterImpl.java**
~~~
package com.ryg.chapter_2.binderpool;
import android.os.RemoteException;
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;//相当于chars[i] = chars[i]^SECRET_CODE
}
return new String(chars);
}
@Override
public String decrypt(String password) throws RemoteException {
return encrypt(password);
}
}
~~~
**ComputeImpl.java**
~~~
package com.ryg.chapter_2.binderpool;
import android.os.RemoteException;
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`**，代码如下所示。
~~~
package com.ryg.chapter_2.binderpool;
interface IBinderPool {
/**
* @param binderCode, the unique token of specific Binder<br/>
* @return specific Binder who's token is binderCode.
*/
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 ();
break;
}
default:
break;
}
return binder;
}
~~~
**远程Service的实现**就比较简单了，代码如下所示。
**BinderPoolService.java**
~~~
package com.ryg.chapter_2.binderpool;
public class BinderPoolService extends Service {
private static final String TAG = "BinderPoolService";
/**
* 在服务端创建一个连接池，BinderPoolImpl是BinderPool的内部类，
* 它继承了IBinderPool.Stub，并实现了queryBinder方法。
*/
private Binder mBinderPool = new BinderPool.BinderPoolImpl ();
@Override
public void onCreate() {
super.onCreate ();
}
@Override
public IBinder onBind(Intent intent) {
Log.d (TAG, "onBind");
return mBinderPool;//返回连接池对象
}
@Override
public void onDestroy() {
super.onDestroy ();
}
}
~~~
下面还剩下**Binder连接池的具体实现**，在它的**内部首先它要去绑定远程服务，绑定成功后，客户端就可以通过它的queryBinder方法去获取各自对应的Binder，拿到所需的Binder以后，不同业务模块就可以进行各自的操作了**，Binder连接池的代码如下所示。
**BinderPool.java**
~~~
package com.ryg.chapter_2.binderpool;
import java.util.concurrent.CountDownLatch;
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_SECURITY_CENTER = 1;
private Context mContext;
private IBinderPool mBinderPool;
private static volatile BinderPool sInstance;
private CountDownLatch mConnectBinderPoolCountDownLatch;
private BinderPool(Context context) {
mContext = context.getApplicationContext ();
connectBinderPoolService ();
}
//返回BinderPool的实例，如果没有的话就创建，有的话就直接返回。
public static BinderPool getInsance(Context context) {
if (sInstance == null) {
synchronized (BinderPool.class) {
if (sInstance == null) {
sInstance = new BinderPool (context);
}
}
}
return sInstance;
}
//连接BinderPoolService服务器。 CountDownLatch将bindService这一异步操作转换成了同步操作
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 ();
}
}
/**
* query binder by binderCode from binder pool
*
* @param binderCode the unique token of binder
* @return binder who's token is binderCode<br>
* return null when not found or BinderPoolService died.
*/
public IBinder queryBinder(int binderCode) {
IBinder binder = null;
try {
/*这个mBinderPool是一个BinderPool.BinderPoolImpl对象。
对于客户端来说调用的是BinderPool的queryBinder方法，
而BinderPool的queryBinder方法又调用了BinderPool.BinderPoolImpl对象的queryBinder方法。
mBinderPool这个对象是服务端返回给BinderPool的，对客户端是隐藏的，客户端只知道BinderPool，
mBinderPool是服务端和连接池的桥梁，
BinderPool是客户端和连接池的桥梁*/
if (mBinderPool != null) {
binder = mBinderPool.queryBinder (binderCode);
}
} catch (RemoteException e) {
e.printStackTrace ();
}
return binder;
}
//连接服务器的时候用的，里面有连接成功和连接断开后的操作。
private ServiceConnection mBinderPoolConnection = new ServiceConnection () {
@Override
public void onServiceDisconnected(ComponentName name) {
// ignored.
}
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
/*
* 将服务器端的Binder转换成客户端所需的AIDL接口对象：
* 服务端返回的是BinderPool连接池，而不是单纯的一个Binder对象。
* */
mBinderPool = IBinderPool.Stub.asInterface (service);
try {
//设置死亡代理：
mBinderPool.asBinder ().linkToDeath (mBinderPoolDeathRecipient, 0);
} catch (RemoteException e) {
e.printStackTrace ();
}
mConnectBinderPoolCountDownLatch.countDown ();
}
};
//设置死亡代理：
private IBinder.DeathRecipient mBinderPoolDeathRecipient = new IBinder.DeathRecipient () {
@Override
public void binderDied() {
Log.w (TAG, "binder died.");
mBinderPool.asBinder ().unlinkToDeath (mBinderPoolDeathRecipient, 0);
mBinderPool = null;
connectBinderPoolService ();
}
};
/*
* （1）这个是我们的Binder连接池，它源于IBinderPool.aidl这个AIDL，它里面包含一个queryBinder方法，
* 我们的Binder连接池是放在服务端用，
* 所以在服务端需要有这样一个BinderPoolImpl的实例，并且它是一个Binder：
* private Binder mBinderPool = new BinderPool.BinderPoolImpl();
* （2）那怎么用呢？
* 我们当前所在的类BinderPool.java就是用来绑定服务端的客户端，
* 在BinderPool绑定服务端的时候，服务端会将mBinderPool返回给客户端也就是我们这个类，
* 然后我们可以根据服务端返回的这个Binder来转换成客户端所需的AIDL接口对象，还是叫mBinderPool，
* 然后我们这个类中就可以调用mBinderPool中的方法：
* binder = mBinderPool.queryBinder(binderCode);
* （3）那另外的两个AIDL呢？ICompute.aidl和ISecurityCenter.aidl呢？
* 由于另外的两个AIDL的使用都是和服务端相关联的，是服务端的queryBinder方法将它们的Binder返回给客户端的，
* 客户端接到这两个AIDL的Binder以后，依旧是通过转换成AIDL接口对象来使用这两个AIDL中的方法的。
* */
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_SECURITY_CENTER: {
binder = new SecurityCenterImpl ();
break;
}
case BINDER_COMPUTE: {
binder = new ComputeImpl ();
break;
}
default:
break;
}
return binder;
}
}
}
~~~
Binder连接池的具体实现就分析完了，它的好处是显然易见的，针对上面的例子，我们**只需要创建一个Service即可完成多个AIDL接口的工**作，下面我们来验证一下效果。新创建一个Activity，在线程中执行如下操作：
~~~
package com.ryg.chapter_2.binderpool;
//这里是客户端
public class BinderPoolActivity extends Activity {
private static final String TAG = "BinderPoolActivity";
private ISecurityCenter mSecurityCenter;
private ICompute mCompute;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_binder_pool);
//在线程中去执行：另开启一个线程执行，因为在binder连接池的实现中，通过CountDownLatch将bindeService
//异步操作转换成了同步操作，意味着有可能是耗时的而且binder方法的调用过程可能也是耗时的
new Thread(new Runnable() {
@Override
public void run() {
doWork();
}
}).start();
}
private void doWork() {
// 首先获取一个BinderPool的实例：这里是带了上下文的，避免创建多个。
BinderPool binderPool = BinderPool.getInsance(BinderPoolActivity.this);
/*
* 然后根据客户端编号bindercode查询Binder，返回的是对应的客户端的Binder。
* 在binderPool.queryBinder中，是根据在绑定服务端过程中返回的BinderPoolImpl的Binder，
* 这个BinderPoolImpl就是继承了IBinderPool的，所以也实现了其中的queryBinder的。
* 这样返回的才是真正对应的securityBinder。
* */
IBinder securityBinder = binderPool
.queryBinder(BinderPool.BINDER_SECURITY_CENTER);
//查到对应的Binder以后，就可以根据这个Binder来转换成客户端所需的AIDL接口对象：
mSecurityCenter = (ISecurityCenter) SecurityCenterImpl
.asInterface(securityBinder);
Log.d(TAG, "visit ISecurityCenter");
String msg = "helloworld-安卓";
System.out.println("content:" + msg);
try {
//有了接口对象，自然就可以调用对象中的方法了：
String password = mSecurityCenter.encrypt(msg);
System.out.println("encrypt:" + password);
System.out.println("decrypt:" + mSecurityCenter.decrypt(password));
} catch (RemoteException e) {
e.printStackTrace();
}
//下面这是另一个AIDL模块，使用方法和上面是一样的。
Log.d(TAG, "visit ICompute");
IBinder computeBinder = binderPool
.queryBinder(BinderPool.BINDER_COMPUTE);
mCompute = ComputeImpl.asInterface(computeBinder);
try {
System.out.println("3+5=" + mCompute.add(3, 5));
} catch (RemoteException e) {
e.printStackTrace();
}
}
}
~~~
在上述代码中，我们先后调用了ISecurityCenter和ICompute这两个AIDL接口中的方法，看一下log，很显然，工作正常。
```
D/BinderPoolActivity(20270): visit ISecurityCenter
I/System.out(20270): content:helloworld-安卓
I/System.out(20270): encrypt:6;221)1,2:s寗匍
I/System.out(20270): decrypt:helloworld-安卓
D/BinderPoolActivity(20270): visit ICompute
I/System.out(20270): 3+5=8
```
这里需要额外说明一下，**为什么要在线程中去执行呢？**
这是因为**在Binder连接池的实现中，我们通过CountDownLatch将bindService这一异步操作转换成了同步操作，这就意味着它有可能是耗时的**，然后就是**Binder方法的调用过程也可能是耗时的，因此不建议放在主线程去执行**。
注意到**BinderPool是一个单例实现，因此在同一个进程中只会初始化一次**，所以如果我们**提前初始化BinderPool，那么可以优化程序的体验**，比如我们**可以放在Application中提前对BinderPool进行初始化**，虽然这不能保证当我们调用BinderPool时它一定是初始化好的，但是在大多数情况下，这种初始化工作（绑定远程服务）的时间开销（如果BinderPool没有提前初始化完成的话）是可以接受的。
另外，**BinderPool中有断线重连的机制，当远程服务意外终止时，BinderPool会重新建立连接，这个时候如果业务模块中的Binder调用出现了异常，也需要手动去重新获取最新的Binder对象，这个是需要注意的**。
有了BinderPool可以大大方便日常的开发工作，比如**如果有一个新的业务模块需要添加新的AIDL，那么在它实现了自己的AIDL接口后，只需要修改BinderPoolImpl中的queryBinder方法，给自己添加一个新的binderCode（比如上面的`BINDER_SECURITY_CENTER`和`BINDER_COMPUTE`）并返回对应的Binder对象即可，不需要做其他修改，也不需要创建新的Service**。由此可见，BinderPool能够极大地提高AIDL的开发效率，并且可以避免大量的Service创建，因此，建议在AIDL开发工作中引入BinderPool机制。
- 前言
- 第1章 Activity的生命周期和启动模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情况下的生命周期分析
- 1.1.2 异常情况下的生命周期分析
- 1.2 Activity的启动模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配规则
- 第2章 IPC机制
- 2.1 Android IPC简介
- 2.2 Android中的多进程模式
- 2.2.1 开启多进程模式
- 2.2.2 多进程模式的运行机制
- 2.3 IPC基础概念介绍
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder连接池
- 2.6 选用合适的IPC方式
- 第3章 View的事件体系
- 3.1 View基础知识
- 3.1.1 什么是View
- 3.1.2 View的位置参数
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑动
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用动画
- 3.2.3 改变布局参数
- 3.2.4 各种滑动方式的对比
- 3.3 弹性滑动
- 3.3.1 使用Scroller7
- 3.3.2 通过动画
- 3.3.3 使用延时策略
- 3.4 View的事件分发机制
- 3.4.1 点击事件的传递规则
- 3.4.2 事件分发的源码解析
- 3.5 View的滑动冲突
- 3.5.1 常见的滑动冲突场景
- 3.5.2 滑动冲突的处理规则
- 3.5.3 滑动冲突的解决方式
- 第4章 View的工作原理
- 4.1 初识ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的对应关系
- 4.3 View的工作流程
- 4.3.1 measure过程
- 4.3.2 layout过程
- 4.3.3 draw过程
- 4.4 自定义View
- 4.4.1 自定义View的分类
- 4.4.2 自定义View须知
- 4.4.3 自定义View示例
- 4.4.4 自定义View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的应用
- 5.1.1 RemoteViews在通知栏上的应用
- 5.1.2 RemoteViews在桌面小部件上的应用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的内部机制
- 5.3 RemoteViews的意义
- 第6章 Android的Drawable
- 6.1 Drawable简介
- 6.2 Drawable的分类
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定义Drawable
- 第7章 Android动画深入分析
- 7.1 View动画
- 7.1.1 View动画的种类
- 7.1.2 自定义View动画
- 7.1.3 帧动画
- 7.2 View动画的特殊使用场景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切换效果
- 7.3 属性动画
- 7.3.1 使用属性动画
- 7.3.2 理解插值器和估值器 /
- 7.3.3 属性动画的监听器
- 7.3.4 对任意属性做动画
- 7.3.5 属性动画的工作原理
- 7.4 使用动画的注意事项
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的内部机制
- 8.2.1 Window的添加过程
- 8.2.2 Window的删除过程
- 8.2.3 Window的更新过程
- 8.3 Window的创建过程
- 8.3.1 Activity的Window创建过程
- 8.3.2 Dialog的Window创建过程
- 8.3.3 Toast的Window创建过程
- 第9章 四大组件的工作过程
- 9.1 四大组件的运行状态
- 9.2 Activity的工作过程
- 9.3 Service的工作过程
- 9.3.1 Service的启动过程
- 9.3.2 Service的绑定过程
- 9.4 BroadcastReceiver的工作过程
- 9.4.1 广播的注册过程
- 9.4.2 广播的发送和接收过程
- 9.5 ContentProvider的工作过程
- 第10章 Android的消息机制
- 10.1 Android的消息机制概述
- 10.2 Android的消息机制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息队列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主线程的消息循环
- 第11章 Android的线程和线程池
- 11.1 主线程和子线程
- 11.2 Android中的线程形态
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的线程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 线程池的分类
- 第12章 Bitmap的加载和Cache
- 12.1 Bitmap的高效加载
- 12.2 Android中的缓存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的实现446
- 12.3 ImageLoader的使用
- 12.3.1 照片墙效果
- 12.3.2 优化列表的卡顿现象
- 第13章 综合技术
- 13.1 使用CrashHandler来获取应用的crash信息
- 13.2 使用multidex来解决方法数越界
- 13.3 Android的动态加载技术
- 13.4 反编译初步
- 13.4.1 使用dex2jar和jd-gui反编译apk
- 13.4.2 使用apktool对apk进行二次打包
- 第14章 JNI和NDK编程
- 14.1 JNI的开发流程
- 14.2 NDK的开发流程
- 14.3 JNI的数据类型和类型签名
- 14.4 JNI调用Java方法的流程
- 第15章 Android性能优化
- 15.1 Android的性能优化方法
- 15.1.1 布局优化
- 15.1.2 绘制优化
- 15.1.3 内存泄露优化
- 15.1.4 响应速度优化和ANR日志分析
- 15.1.5 ListView和Bitmap优化
- 15.1.6 线程优化
- 15.1.7 一些性能优化建议
- 15.2 内存泄露分析之MAT工具
- 15.3 提高程序的可维护性