【视频文稿】车载Android应用开发与分析 - AIDL实践与封装(下)

本期视频地址 :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集合来保存它,如果使用ArrayListCopyOnWriteArrayList保存「客户端」的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具有以下优势:

  1. 它通过调用IInterface.asBinder()方法,根据底层的唯一Binder来识别每个注册的接口。
  2. 它给每个注册的接口附加了一个IBinder.DeathRecipient,这样如果接口所在的进程死亡了,它就可以从列表中清除掉。
  3. 它对底层接口列表进行了加锁处理,以应对多线程的并发调用,同时提供了一种线程安全的方式来遍历列表的快照,而不需要持有锁。

要使用这个类,需要创建一个实例,并调用它的register(E)和unregister(E)方法作为客户端注册和取消注册服务。要回调到注册的客户端,请使用beginBroadcast()、getBroadcastItem(int)和finishBroadcast()方法。

下面是一些使用RemoteCallbackList的代码示例:

    private RemoteCallbackList 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 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。例如,你可以这样写:


其中protectionLevel有以下几种:

  1. normal:默认值,表示低风险的权限,系统会自动授予请求的应用,无需用户同意。
  2. dangerous:表示高风险的权限,涉及用户私人数据或设备控制权,系统会向用户显示并确认是否授予请求的应用。
  3. signature:表示只有当请求的应用和声明权限的应用使用相同的证书签名时,系统才会授予的权限。
  4. signatureOrSystem:表示只有当请求的应用和声明权限的应用使用相同的证书签名,或者请求的应用位于系统映像的专用文件夹中时,系统才会授予的权限。

这个参数在 API 级别 23 中已弃用,建议使用 signature。

2)「服务端」AndroidManifest.xml的Service标签中指明需要的权限


    ...

此时,「客户端」无论是startService还是bindService都必须声明com.example.permission.BIND_MY_SERVICE权限。

3)最后,在「客户端」的清单文件中,添加一个标签,声明使用这个权限


  • 控制「客户端」AIDL接口的使用权限

除了控制连接Service的权限,多数时候我们还需要控制aidl接口的请求权限,避免「客户端」可以随意访问一些危险的aidl接口 1)在「服务端」AndroidManifest.xml中,自定义接口权限


2)定义一个新的AIDL接口

interface ICalculator {
 
  oneway void optionPermission1(int i);
 
 }

3)在「客户端」清单中注册权限,并调用远程接口


@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重连的具体实现
  • 减少「客户端」与「服务端」的不必要的通信次数,提高性能
  • 根据需要进行权限验证

根据以上原则,封装了以下实现。

【视频文稿】车载Android应用开发与分析 - AIDL实践与封装(下)_第1张图片

  • 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 {

            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 对象
             * 

* 是否需要设定为单例,由开发者自行决定。 * * @param context 上下文 * @param handler 用于处理服务端回调的 Handler * @param listener 用于监听服务端生命周期的 Listener * @return SdkASyncManager */ public static Sdk get(Context context, Handler handler, SdkServiceLifecycleListener 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 listener) { return new Sdk(null, null, listener); } public Sdk(@Nullable final Context context, @Nullable final Handler handler, @Nullable final SdkServiceLifecycleListener 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 getService(@NonNull Class serviceClass) { Log.i(TAG, "getService: "+serviceClass.getSimpleName()); SdkManagerBase manager; // 涉及 managerMap 的操作,需要加锁 synchronized (getLock()) { HashMap 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 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.
 * 

* 在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() { @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 mDurationData; public LiveData 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 getDurationData() { if (mDurationData == null) { mDurationData = new MutableLiveData<>(); } return mDurationData; } }

「2. 总结」

本期视频我们介绍了车载Android开发中最常用的跨进程通信方式-AIDL,当然除此以外还有ContentProvider也较为常用,总得来说AIDL有以下优缺点:

优点:

  • 可以实现跨进程通信,让不同应用之间可以共享数据和功能
  • 可以处理多线程并发请求,提高效率和性能
  • 可以自定义传输实例,灵活性高

缺点:

  • 使用过程比较复杂,需要创建多个文件和类
  • 传输数据有限制,只能使用AIDL支持的数据类型
  • 传输数据有开销,需要进行序列化和反序列化操作

通过近期这五节视频,我们基本就已经介绍完车载应用开发的全部基础技术要求了。车载应用多数时候都是在开发系统应用,所以从下期视频开始,我们将介绍常见系统应用的原理。

好,以上就是本视频的全部内容了。本视频的文字内容发布在我的个人微信公众号-『车载 Android』和我的个人博客中,视频中使用的 PPT 文件和源码发布在我的Github[https://github.com/linxu-link/CarAndroidCourse]上,在本视频的简介里可以找到相应的地址。

感谢您的观看,我们下期视频再见,拜拜。

你可能感兴趣的:(车载应用开发视频文案,android)