【视频文稿】车载Android应用开发与分析 – AIDL实践与封装（下）-六虎

本期视频地址：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

利用反射获取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[github.com/linxu-link/…

感谢您的观看，咱们下期视频再见，拜拜。

【视频文稿】车载Android应用开发与分析 – AIDL实践与封装（下）

「1. AIDL 进阶」

问题 6：「服务端」向「客户端」建议回调

问题 7：防止DeadObjectException

问题 8：服务端存在多个 Binder

问题 9：AIDL的权限操控

问题 10： 封装 AIDL SDK

「2. 总结」

相关文章

Flutter runApp 到渲染上屏

Metal每日分享，UV去雾滤镜效果

完蛋，我被offer包围了｜秋招自救指南

初学安卓framework系列 四 (系统中的那些进程)

作者信息

问题 10：封装 AIDL SDK

初学安卓framework系列四 (系统中的那些进程)