本期视频地址 ：www.bilibili.com/video/BV1zh…
上期视频讲解了AIDL的简单运用，以及5个可能在运用AIDL进程会遇到的问题，本期视频咱们继续把余下的5个的问题讲完。
「1. AIDL 进阶」
问题 6：「服务端」向「客户端」建议回调
在上一节的示例中，咱们都是在介绍「客户端」怎么向「服务端」发送恳求。实践开发中，也会呈现「服务端」需求主动向「客户端」建议恳求的状况。这时咱们就需求在「服务端」保存一个「客户端」的 Binder 实例，在需求时「服务端」就能够经过这个 Binder 来向「客户端」宣布恳求。
具体操作如下：
1）新建一个ICalculatorListener.aidl文件，并界说需求的办法。
// ICalculatorListener.aidl
package com.wj.sdk.listener;
interface ICalculatorListener {
void callback(String result);
}
2）在ICalculator.aidl中界说相应的注册、免除注册的办法。
package com.wj.sdk;
// 引进这个listener
import com.wj.sdk.listener.ICalculatorListener;
interface ICalculator {
...
oneway void registerListener(ICalculatorListener listener);
oneway void unregisterListener(ICalculatorListener listener);
}
由于一个「服务端」可能会一起衔接多个「客户端」，所以关于「客户端」注册过来的 Binder 实例，咱们需求运用一个List调集来保存它，假如运用ArrayList或CopyOnWriteArrayList保存「客户端」的Binder实例，需求在「客户端」与「服务端」的衔接断开时，将保存的Binder铲除。假如调用已经免除衔接的Binder，会抛出DeadObjectException。
假如需求在「服务端」监听「客户端」是否断开衔接，能够运用linkToDeath完成，如下所示：
@Override
public void registerListener(final ICalculatorListener listener) throws RemoteException {
final Binder binder = listener.asBinder();
Binder.DeathRecipient deathRecipient = new DeathRecipient() {
@Override
public void binderDied() {
// 从调集中移除存在的Binder实例。
}
};
binder.linkToDeath(deathRecipient, 0);
}
不过，在这里咱们推荐运用RemoteCallbackList来保存「客户端」的Binder实例。
问题 7：防止DeadObjectException
RemoteCallbackList是一个类，它用于办理一组已注册的IInterface回调，并在它们的进程消失时主动从列表中整理它们。RemoteCallbackList一般用于执行从Service到其客户端的回调，完成跨进程通讯。
RemoteCallbackList具有以下优势：
- 它经过调用IInterface.asBinder()办法，依据底层的仅有Binder来辨认每个注册的接口。
- 它给每个注册的接口附加了一个IBinder.DeathRecipient，这样假如接口所在的进程死亡了，它就能够从列表中铲除去。
- 它对底层接口列表进行了加锁处理，以应对多线程的并发调用，一起供给了一种线程安全的方法来遍历列表的快照，而不需求持有锁。
要运用这个类，需求创立一个实例，并调用它的register(E)和unregister(E)办法作为客户端注册和撤销注册服务。要回调到注册的客户端，请运用beginBroadcast()、getBroadcastItem(int)和finishBroadcast()办法。
下面是一些运用RemoteCallbackList的代码示例：
private RemoteCallbackList<ICalculatorListener> mCallbackList = new RemoteCallbackList<>();
@Override
public void registerListener(final ICalculatorListener listener) throws RemoteException {
Log.i(TAG, "registerListener: " + Thread.currentThread().getName());
mCallbackList.register(listener);
}
@Override
public void unregisterListener(final ICalculatorListener listener) throws RemoteException {
Log.i(TAG, "unregisterListener: " + Thread.currentThread().getName());
mCallbackList.unregister(listener);
}
然后咱们就能够经过RemoteCallbackList中保存的「客户端」Binder向客户端建议恳求。
// 向客户端发送音讯
private synchronized void notifyToClient() {
Log.i(TAG, "notifyToClient");
int n = mCallbackList.beginBroadcast();
for (int i = 0; i < n; i++) {
try {
mCallbackList.getBroadcastItem(i).callback(i + "--");
} catch (RemoteException e) {
e.printStackTrace();
}
}
mCallbackList.finishBroadcast();
}
问题 8：服务端存在多个 Binder
上面示例中，咱们只界说了一个 Binder 实例即 ICalculator ，当「客户端」需求与「服务端」进行多种不同的事务交互时，就需求在「服务端」完成多个不同的Binder实例，此刻咱们能够引进BinderPool机制来优化这种场景。
BinderPool是一个用于办理和分发Binder的机制，它能够让不同的模块之间经过一个一致的Service进行Binder通讯，客户端经过一个Binder衔接到服务端，然后依据不同的事务需求，获取到对应的Binder实例，从而完成跨进程通讯。这样能够削减客户端和服务端之间的衔接数，进步功用和稳定性。
BinderPool的具体用法如下：
1）界说一个AIDL接口，用于描绘BinderPool的功用。
包括一个queryBinder办法，用于依据不同的type回来不同的Binder实例。
package com.wj.sdk;
interface ICalculator {
...
Binder queryBinder(int type);
}
2）完成这个AIDL接口，在queryBinder办法中依据code回来对应的Binder实例。
这些Binder实例一般是其他AIDL接口的完成类。为了防止每次恳求，都会创立一个Binder实例，咱们能够将这些创立好的Binder实例缓存在列表中，运用时直接取出即可。
private final SparseArray<IBinder> mCache = new SparseArray<>();
@Override
public IBinder queryBinder(final int type) throws RemoteException {
IBinder binder = mCache.get(type);
if (binder != null) {
return binder;
}
switch (type) {
case 1:
binder = new MyHavc();
break;
case 2:
binder = new MyVehicle();
break;
}
mCache.put(type, binder);
return binder;
}
3）创立一个Service类，承继自Service，重写onBind办法，回来上一步中完成的BinderPool实例。
@Override
public IBinder onBind(Intent intent) {
if (mCalculatorBinder == null) {
mCalculatorBinder = new CalculatorBinder(this);
}
return mCalculatorBinder;
}
4）「客户端」，先经过bindService办法绑定到这个Service，并获取到 BinderPool 实例，然后调用 queryBinder 办法获取到需求的Binder实例，再调用其办法来完成功用。
// 其它办法省掉
public static final int TYPE_HAVC = 1;
public static final int TYPE_VEHICLE = 2;
// 问题7 - Binder衔接池
private void callBinderPool() {
try {
IBinder binder = mCalculator.queryBinder(TYPE_HAVC);
IHvac hvac = IHvac.Stub.asInterface(binder);
// Hvac 供给的aidl接口
hvac.basicTypes(1, 2, true, 3.0f, 4.0, "5");
binder = mCalculator.queryBinder(TYPE_VEHICLE);
IVehicle vehicle = IVehicle.Stub.asInterface(binder);
// Vehicle 供给的aidl接口
vehicle.basicTypes(1, 2, true, 3.0f, 4.0, "5");
} catch (RemoteException exception) {
Log.i(TAG, "callBinderPool: " + exception);
}
}
问题 9：AIDL的权限操控
- 操控「客户端」的绑定权限
在对外露出AIDL接口时，咱们并不期望一切的「客户端」都能够衔接到Service中，那么咱们能够自界说权限，约束具有指定权限的运用才能够绑定到「服务端」。
1）在「服务端」AndroidManifest.xml中，自界说一个权限
在Service的清单文件中，增加一个android:permission属性，指定一个自界说的权限名称。这样，只有拥有这个权限的客户端才能绑定到这个Service。例如，你能够这样写：
<permission
android:name="com.example.permission.BIND_MY_SERVICE"
android:protectionLevel="signature" />
其间protectionLevel有以下几种：
- normal：默认值，表明低危险的权限，体系会主动颁发恳求的运用，无需用户赞同。
- dangerous：表明高危险的权限，触及用户私家数据或设备操控权，体系会向用户显现并承认是否颁发恳求的运用。
- signature：表明只有当恳求的运用和声明权限的运用运用相同的证书签名时，体系才会颁发的权限。
- signatureOrSystem：表明只有当恳求的运用和声明权限的运用运用相同的证书签名，或许恳求的运用坐落体系映像的专用文件夹中时，体系才会颁发的权限。
这个参数在 API 等级 23 中已弃用，建议运用 signature。
2）「服务端」AndroidManifest.xml的Service标签中指明需求的权限
<service android:name=".MyService"
android:permission="com.example.permission.BIND_MY_SERVICE">
...
</service>
此刻，「客户端」无论是startService还是bindService都必须声明com.example.permission.BIND_MY_SERVICE权限。
3）最终，在「客户端」的清单文件中，增加一个标签，声明运用这个权限
<uses-permission android:name="com.example.permission.BIND_MY_SERVICE" />
- 操控「客户端」AIDL接口的运用权限
除了操控衔接Service的权限，大都时分咱们还需求操控aidl接口的恳求权限，防止「客户端」能够随意拜访一些危险的aidl接口 1）在「服务端」AndroidManifest.xml中，自界说接口权限
<permission android:name="com.example.aidl.ServerService2"
android:protectionLevel="signature" />
2）界说一个新的AIDL接口
interface ICalculator {
oneway void optionPermission1(int i);
}
3）在「客户端」清单中注册权限，并调用长途接口
<uses-permission android:name="com.example.aidl.ServerService2"/>
@RequiresPermission(PERMISSION_CAR_CONTROL_AUDIO_VOLUME)
private void callPermission() {
try {
if (checkPermission()) {
Log.i(TAG, "callPermission: 有权限");
mCalculator.optionPermission(1);
} else {
Log.i(TAG, "callPermission: 没有权限");
}
} catch (RemoteException exception) {
Log.i(TAG, "callPermission: " + exception);
}
}
/**
* 检查运用本身是否有权限
* @return true 有权限，false 没有权限
*/
private boolean checkPermission() {
return checkSelfPermission(PERMISSION_CAR_CONTROL_AUDIO_VOLUME) == PackageManager.PERMISSION_GRANTED;
}
public static final String PERMISSION_CAR_CONTROL_AUDIO_VOLUME = "car.permission.CAR_CONTROL_AUDIO_VOLUME";
4）在「服务端」完成这个接口，并检查调用方是否获得相应的权限
@Override
public void optionPermission(final int i) throws RemoteException {
// 在oneway 接口中Binder.getCallingPid() 一直为 0
Log.i(TAG, "optionPermission: calling pid " + Binder.getCallingPid() + "; calling uid" + Binder.getCallingUid());
// 办法一：检查权限,假如没有权限，抛出SecurityException
mContext.enforceCallingPermission("car.permission.CAR_CONTROL_AUDIO_VOLUME", "没有权限");
// 办法二：检查权限，假如没有权限，回来false
boolean checked = mContext.checkCallingPermission("car.permission.CAR_CONTROL_AUDIO_VOLUME") == PackageManager.PERMISSION_GRANTED;
Log.e(TAG, "optionPermission: " + checked);
}
Binder.getCallingPid()和Binder.getCallingUid()都是用来获取调用者（即发送Binder恳求的进程）的信息的。区别在于：
-
Binder.getCallingPid()办法回来调用者的进程ID，它是一个int类型的值，能够用来区分不同的进程。这个办法是从API 1就存在的，能够在任何版本的Android上运用。 -
Binder.getCallingUid()办法回来调用者的用户ID，它是一个int类型的值，能够用来区分不同的用户或运用。这个办法是从API 1就存在的，能够在任何版本的Android上运用。
这两个办法都只能在Binder的办法中调用，否则会回来当前进程或许用户的ID。它们能够用来检查调用者是否拥有某些权限，或许进行一些安全验证。
checkCallingPermission()和 enforceCallingPermission()都能够用于权限检查，区别在于
- int checkCallingPermission(String permission)：检查调用者是否有指定的权限。假如没有调用者或许调用者不是 IPC，则回来-1，假如IPC调用者有指定的权限则回来 0 。
- void enforceCallingPermission：检查调用者是否有指定的权限，假如没有或许没有调用者或许调用者不是 IPC，则抛出 SecurityException 反常。
除了上面的办法，还有以下一些较为常用的用于检查AIDL接口的办法。
-
int checkPermission(String permission, int pid, int uid)：检查指定的进程和用户ID是否有指定的权限。
-
int checkCallingOrSelfPermission(String permission)：检查调用者或许本身是否有指定的权限，假如没有调用者，则相当于 checkSelfPermission。这个办法要慎重运用，由于它可能会颁发短少权限的恶意运用拜访受维护的资源。
-
int checkSelfPermission(String permission)：检查本身是否有指定的权限，这是运行时动态检查的方法，一般用于恳求危险权限。
-
void enforcePermission(String permission, int pid, int uid, @Nullable String message)：检查指定的进程和用户 ID 是否有指定的权限，假如没有，则抛出 SecurityException 反常。
-
void enforceCallingOrSelfPermission(String permission, @Nullable String message)：检查调用者或许本身是否有指定的权限，假如没有，则抛出 SecurityException 反常。假如没有调用者，则相当于 enforcePermission。这个办法要慎重运用，由于它可能会颁发短少权限的恶意运用拜访受维护的资源。
问题 10： 封装 AIDL SDK
「服务端」在对外供给事务能力时，不可能要求每个调用方自己编写AIDL并完成Service的绑定逻辑，所以咱们必须将AIDL封装成SDK供给给外部运用。在封装SDK时一般需求恪守以下准则：
- 简化「客户端」的调用本钱
- 隐藏Service重连机制，使调用方无需关怀Service重连的具体完成
- 削减「客户端」与「服务端」的不用要的通讯次数，进步功用
- 依据需求进行权限验证
依据以上准则，封装了以下完成。
-
SdkBase
SdkBase 是一个抽象类，它的作用是为了让子类能够更方便地完成与服务端的衔接，内部完成了Service重连机制。并对外露出connect()、disconnect()、isConnected()等办法。是能够复用的模板类 。
-
SdkAppGlobal
-
SdkManagerBase
SdkManagerBase 是一个抽象类。在本示例中，SdkManagerBase 的子类有 AudioSdkManager、InfoSdkManager 等。
完成部分代码过多，请阅览github检查具体完成。
运用时，需求承继SdkBase，本示例的完成就是Sdk。
-
Sdk
Sdk 承继自SdkBase，是一个办理类，用于对「客户端」供给一致的入口。展现怎么运用SdkBase。
/**
* Sdk 是一个办理类，用于办理服务端的各种功用，包括音频、信息等。
*
* @author linxu_link
* @version 1.0
*/
public class Sdk extends SdkBase<ISdk> {
public static final String PERMISSION_AUDIO = "com.wj.standardsdk.permission.AUDIO";
private static final String SERVICE_PACKAGE = "com.wj.standardserver";
private static final String SERVICE_CLASS = "com.wj.standardserver.StandardService";
private static final String SERVICE_ACTION = "android.intent.action.STANDARD_SERVICE";
public static final int SERVICE_AUDIO = 0x1001;
public static final int SERVICE_INFO = 0x1002;
private static final long SERVICE_BIND_RETRY_INTERVAL_MS = 500;
private static final long SERVICE_BIND_MAX_RETRY = 100;
/**
* 创立一个 Manager 对象
* <p>
* 是否需求设定为单例，由开发者自行决定。
*
* @param context 上下文
* @param handler 用于处理服务端回调的 Handler
* @param listener 用于监听服务端生命周期的 Listener
* @return SdkASyncManager
*/
public static Sdk get(Context context, Handler handler, SdkServiceLifecycleListener<Sdk> listener) {
return new Sdk(context, handler, listener);
}
public static Sdk get() {
return new Sdk(null, null, null);
}
public static Sdk get(Context context) {
return new Sdk(context, null, null);
}
public static Sdk get(Handler handler) {
return new Sdk(null, handler, null);
}
public static Sdk get(SdkServiceLifecycleListener<Sdk> listener) {
return new Sdk(null, null, listener);
}
public Sdk(@Nullable final Context context, @Nullable final Handler handler, @Nullable final SdkServiceLifecycleListener<Sdk> listener) {
super(context, handler, listener);
}
@Override
protected String getServicePackage() {
return SERVICE_PACKAGE;
}
@Override
protected String getServiceClassName() {
return SERVICE_CLASS;
}
@Override
protected String getServiceAction() {
return SERVICE_ACTION;
}
@Override
protected ISdk asInterface(final IBinder binder) {
return ISdk.Stub.asInterface(binder);
}
@Override
protected boolean needStartService() {
return false;
}
@Override
protected String getLogTag() {
return TAG;
}
@Override
protected long getConnectionRetryCount() {
return SERVICE_BIND_MAX_RETRY;
}
@Override
protected long getConnectionRetryInterval() {
return SERVICE_BIND_RETRY_INTERVAL_MS;
}
public static final String TAG = "CAR.SERVICE";
public <T extends SdkManagerBase> T getService(@NonNull Class<T> serviceClass) {
Log.i(TAG, "getService: "+serviceClass.getSimpleName());
SdkManagerBase manager;
// 触及 managerMap 的操作，需求加锁
synchronized (getLock()) {
HashMap<Integer, SdkManagerBase> managerMap = getManagerCache();
if (mService == null) {
Log.w(TAG, "getService not working while car service not ready");
return null;
}
int serviceType = getSystemServiceType(serviceClass);
manager = managerMap.get(serviceType);
if (manager == null) {
try {
IBinder binder = mService.getService(serviceType);
if (binder == null) {
Log.w(TAG, "getService could not get binder for service:" + serviceType);
return null;
}
manager = createCarManagerLocked(serviceType, binder);
if (manager == null) {
Log.w(TAG, "getService could not create manager for service:" + serviceType);
return null;
}
managerMap.put(serviceType, manager);
} catch (RemoteException e) {
handleRemoteExceptionFromService(e);
}
}
}
return (T) manager;
}
private int getSystemServiceType(@NonNull Class<?> serviceClass) {
switch (serviceClass.getSimpleName()) {
case "AudioManager":
return SERVICE_AUDIO;
case "InfoManager":
return SERVICE_INFO;
default:
return -1;
}
}
@Nullable
private SdkManagerBase createCarManagerLocked(int serviceType, IBinder binder) {
SdkManagerBase manager = null;
switch (serviceType) {
case SERVICE_AUDIO:
manager = new AudioManager(this, binder);
break;
case SERVICE_INFO:
manager = new InfoManager(this, binder);
break;
default:
// Experimental or non-existing
break;
}
return manager;
}
}
-
AudioManager
承继自SdkManagerBase。展现怎么运用SdkManagerBase。
/**
* 一个运用示例：音频办理类
* @author linxu_link
* @version 1.0
*/
public class AudioManager extends SdkManagerBase {
private final IAudio mService;
private final CopyOnWriteArrayList<AudioCallback> mCallbacks;
public AudioManager(SdkBase sdk, IBinder binder) {
super(sdk);
mService = IAudio.Stub.asInterface(binder);
mCallbacks = new CopyOnWriteArrayList<>();
}
private final IAudioCallback.Stub mCallbackImpl = new IAudioCallback.Stub() {
@Override
public void onAudioData(byte[] data, int length) throws RemoteException {
for (AudioCallback callback : mCallbacks) {
callback.onAudioData(data, length);
}
}
};
// 提示需求权限
@RequiresPermission(Sdk.PERMISSION_AUDIO)
public void play() {
try {
mService.play();
} catch (RemoteException e) {
Log.e(TAG, "play: " + e);
handleRemoteExceptionFromService(e);
}
}
public long getDuration() {
try {
return mService.getDuration();
} catch (RemoteException e) {
return handleRemoteExceptionFromService(e, 0);
}
}
public void registerAudioCallback(AudioCallback callback) {
Objects.requireNonNull(callback);
if (mCallbacks.isEmpty()) {
registerCallback();
}
mCallbacks.add(callback);
}
public void unregisterAudioCallback(AudioCallback callback) {
Objects.requireNonNull(callback);
if (mCallbacks.remove(callback) && mCallbacks.isEmpty()) {
unregisterCallback();
}
}
/************* 内部办法 *************/
/**
* 向服务端注册回调
*/
private void registerCallback() {
try {
mService.registerAuidoCallback(mCallbackImpl);
} catch (RemoteException e) {
Log.e(TAG, "registerAudioCallback: " + e);
handleRemoteExceptionFromService(e);
}
}
/**
* 撤销注册回调
*/
private void unregisterCallback() {
try {
mService.unregisterAudioCallback(mCallbackImpl);
} catch (RemoteException e) {
Log.e(TAG, "unregisterAudioCallback: " + e);
handleRemoteExceptionFromService(e);
}
}
@Override
protected void onDisconnected() {
}
public abstract static class AudioCallback {
public void onAudioData(byte[] data, int length) {
}
}
}
-
AudioDataLoader
模仿MVVM架构中Model层的封装，用于展现「客户端」怎么对SDK进行二次封装。
/**
* 用于加载音频数据的DataLoader.
* <p>
* 在MVVM架构中属于 Model 层的组成部分之一.
*
* @author linxu_link
* @version 1.0
*/
public class AudioDataLoader {
private Sdk mSdk;
private AudioManager mAudioManager;
// 同步锁。将异步的Service的衔接，改为同步的。
private CountDownLatch mAudioManagerReady;
public AudioDataLoader() {
mAudioManagerReady = new CountDownLatch(1);
mSdk = Sdk.get(new SdkBase.SdkServiceLifecycleListener<Sdk>() {
@Override
public void onLifecycleChanged(@NonNull final Sdk sdk, final boolean ready) {
if (ready) {
mAudioManager = sdk.getService(AudioManager.class);
mAudioManager.registerAudioCallback(mAudioCallback);
mAudioManagerReady.countDown();
} else {
if (mAudioManagerReady.getCount() <= 0) {
mAudioManagerReady = new CountDownLatch(1);
}
mAudioManager = null;
// 重新衔接
sdk.connect();
}
}
});
}
private final AudioManager.AudioCallback mAudioCallback = new AudioManager.AudioCallback() {
@Override
public void onAudioData(final byte[] data, final int length) {
}
};
public void play() {
// 实践应该放入线程池中执行
new Thread(() -> {
try {
mAudioManagerReady.await();
} catch (InterruptedException e) {
return;
}
mAudioManager.play();
Log.i("TAG", "play 执行结束");
}).start();
}
private MutableLiveData<Long> mDurationData;
public LiveData<Long> getDuration() {
// 实践应该放入线程池中执行
new Thread(() -> {
try {
mAudioManagerReady.await();
} catch (InterruptedException e) {
getDurationData().postValue(0L);
}
getDurationData().postValue(mAudioManager.getDuration());
}).start();
return getDurationData();
}
public void release() {
mAudioManager.unregisterAudioCallback(mAudioCallback);
mSdk.disconnect();
mSdk = null;
mAudioManager = null;
}
private MutableLiveData<Long> getDurationData() {
if (mDurationData == null) {
mDurationData = new MutableLiveData<>();
}
return mDurationData;
}
}
「2. 总结」
本期视频咱们介绍了车载Android开发中最常用的跨进程通讯方法-AIDL，当然除此以外还有ContentProvider也较为常用，总得来说AIDL有以下优缺陷：
长处：
- 能够完成跨进程通讯，让不同运用之间能够同享数据和功用
- 能够处理多线程并发恳求，进步功率和功用
- 能够自界说传输实例，灵活性高
缺陷：
-
运用进程比较复杂，需求创立多个文件和类
-
传输数据有约束，只能运用AIDL支撑的数据类型
-
传输数据有开支，需求进行序列化和反序列化操作
经过近期这五节视频，咱们基本就已经介绍完车载运用开发的悉数根底技术要求了。车载运用大都时分都是在开发体系运用，所以从下期视频开端，咱们将介绍常见体系运用的原理。
好，以上就是本视频的悉数内容了。本视频的文字内容发布在我的个人微信公众号-『车载 Android』和我的个人博客中，视频中运用的 PPT 文件和源码发布在我的Github[github.com/linxu-link/…
感谢您的观看，咱们下期视频再见，拜拜。
