本期视频地址 ：https://www.bilibili.com/video/BV1zh4y1x7KE/
上期视频讲解了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
利用反射获取APP Context的类。这样我们就可以在任意地方初始化Sdk，不必受Context的限制。可以复用
-
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[https://github.com/linxu-link/CarAndroidCourse]上，在本视频的简介里可以找到相应的地址。
感谢您的观看，我们下期视频再见，拜拜。