本技术博文计划分为三个系列:
一、AIDL的基础,http://blog.youkuaiyun.com/wangqiubo2010/article/details/78601666。
二、AIDL之Messenger,http://blog.youkuaiyun.com/wangqiubo2010/article/details/78615047.。
三、AIDL终极篇之AIDL架构设计。
本文为AIDL设计的终极篇,AIDL架构设计。
在设计这个架构设计之前,思考一个问题:随着项目越来越大,如果请求的服务器中的服务类型越来越多,按照普通的设计有两种办法。
第一,服务器所执行的方法全部放在一个或者少量几个类中,这里有个问题就是,多种不同类型的请求全部塞在一个类中,并且类越来越庞大,这和职责分离完全背离。
第二,建立无数个service,每个service实现一种类型服务,也即是每种类型都生成一个IBinder,并且会有无数个链接,这样的设计服务器迟早会被拖垮。
针对以上问题,现在就是对AIDL的设计架构进行改进。
AIDL新设计架构图如下:
对本架构进行解析:
服务端架构解析:
1、IBinder1、IBinder2、IBinder3…,这些都是根据各种功能类型实现的每个Stub。
2、AIDLPoolService(IBinder管理器)。
AIDLPoolService其实就是客户端需要连接的服务,但是本服务提供给客户端的IBinder其实是一个IBinder管理器,本管理器只有一个方法queryBinder,这个方法就是根据ID来分发查询所需要类型的IBinder,入上面的IBinder1、IBinder2等。
服务器这样的设计就能解决以上2个问题。
第一,IBinder1、IBinder2、IBinder3…,无论你有多少种类型的功能,都可以无限增加,既解决了职责分离问题,又实现了动态增加功能。
第二,本架构连接服务器只会请求一次,请求成功之后,后续只要传一个IBinder的ID就可以查询到所需求的IBinder,则客户端获取到之后就可以直接调用服务器的方法。
客户端架构解析:
1、client1、client2、client3……,就是客户端每个功能模块了。
2、AIDLPoolClient,封装了对Service的连接,有一个IBinder查询器,client1、client2、client3……只要传个ID过去就可以直接获取到所需求的IBinder。
以上架构代码如下:
//AIDLPoolService(IBinder管理器)。
package com.example.myservice;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.support.annotation.Nullable;
/**
* Created by wangqiubo on 2017/5/17.
*/
public class AidlPoolService extends Service{
@Nullable
@Override
public IBinder onBind(Intent intent) {
return aidlPool;
}
private static IBinder aidlPool = new AidlPoolImpl();
}
//AidlPoolImpl.java
package com.example.myservice;
import android.os.Debug;
import android.os.IBinder;
import android.os.RemoteException;
import com.example.wangqiubo.myaidl.IAidlPool;
/**
* Created by wangqiubo on 2017/5/17.
*/
public class AidlPoolImpl extends IAidlPool.Stub {
public static final int BOOK_BINDER_ID = 0;
public static final int USER_BINDER_ID = 1;
IBinder mBinder = null;
@Override
public IBinder queryBinder(