【视频文稿】车载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<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有以下几种:

  1. normal:默认值,表示低风险的权限,系统会自动授予请求的应用,无需用户同意。
  2. dangerous:表示高风险的权限,涉及用户私人数据或设备控制权,系统会向用户显示并确认是否授予请求的应用。
  3. signature:表示只有当请求的应用和声明权限的应用使用相同的证书签名时,系统才会授予的权限。
  4. 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.
  • 在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 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]上,在本视频的简介里可以找到相应的地址。

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

目录
相关文章
|
1月前
|
搜索推荐 Android开发 iOS开发
安卓与iOS系统的用户界面设计对比分析
本文通过对安卓和iOS两大操作系统的用户界面设计进行对比分析,探讨它们在设计理念、交互方式、视觉风格等方面的差异及各自特点,旨在帮助读者更好地理解和评估不同系统的用户体验。
23 1
|
1月前
|
调度 数据库 Android开发
构建高效Android应用:Kotlin协程的实践与优化
在Android开发领域,Kotlin以其简洁的语法和平台友好性成为了开发的首选语言。其中,Kotlin协程作为处理异步任务的强大工具,它通过提供轻量级的线程管理机制,使得开发者能够在不阻塞主线程的情况下执行后台任务,从而提升应用性能和用户体验。本文将深入探讨Kotlin协程的核心概念,并通过实例演示如何在实际的Android应用中有效地使用协程进行网络请求、数据库操作以及UI的流畅更新。同时,我们还将讨论协程的调试技巧和常见问题的解决方法,以帮助开发者避免常见的陷阱,构建更加健壮和高效的Android应用。
36 4
|
1月前
|
移动开发 Java Android开发
构建高效Android应用:Kotlin协程的实践之路
【2月更文挑战第31天】 在移动开发领域,性能优化和流畅的用户体验一直是开发者追求的目标。随着Kotlin语言的流行,其异步编程解决方案——协程(Coroutines),为Android应用带来了革命性的并发处理能力。本文将深入探讨Kotlin协程的核心概念、设计原理以及在Android应用中的实际应用案例,旨在帮助开发者掌握这一强大的工具,从而提升应用的性能和响应能力。
|
1月前
|
移动开发 调度 Android开发
构建高效Android应用:探究Kotlin协程的优势与实践
【2月更文挑战第30天】 在移动开发领域,尤其是针对Android平台,性能优化和应用流畅度始终是开发者关注的重点。近年来,Kotlin语言凭借其简洁性和功能性成为Android开发的热门选择。其中,Kotlin协程作为一种轻量级的线程管理解决方案,为异步编程提供了强大支持,使得编写非阻塞性代码变得更加容易。本文将深入分析Kotlin协程的核心优势,并通过实际案例展示如何有效利用协程提升Android应用的性能和响应速度。
|
1月前
|
数据库 Android开发 开发者
构建高性能微服务架构:从理论到实践构建高效Android应用:探究Kotlin协程的优势
【2月更文挑战第16天】 在当今快速迭代和竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性和独立部署能力而受到企业的青睐。本文将深入探讨如何构建一个高性能的微服务系统,涵盖从理论基础到具体实现的各个方面。我们将重点讨论服务拆分策略、通信机制、数据一致性以及性能优化等关键主题,为读者提供一个清晰、实用的指南,以便在复杂多变的业务环境中构建和维护健壮的微服务体系结构。 【2月更文挑战第16天】 在移动开发领域,性能优化和流畅的用户体验是至关重要的。随着技术的不断进步,Kotlin作为一种现代编程语言,在Android开发中被广泛采用,尤其是其协程特性为异步编程带来了革命性的改进。本文旨在深入
|
2月前
|
Android开发 数据安全/隐私保护 iOS开发
安卓与iOS系统的发展趋势与比较分析
【2月更文挑战第6天】 在移动互联网时代,安卓和iOS系统作为两大主流移动操作系统,各自呈现出不同的发展趋势。本文将从技术角度出发,对安卓和iOS系统的发展方向、特点及未来趋势进行比较分析,以期为读者提供更深入的了解和思考。
38 4
|
26天前
|
Java Android开发 开发者
构建高效Android应用:Kotlin协程的实践与优化
在响应式编程范式日益盛行的今天,Kotlin协程作为一种轻量级的线程管理解决方案,为Android开发带来了性能和效率的双重提升。本文旨在探讨Kotlin协程的核心概念、实践方法及其在Android应用中的优化策略,帮助开发者构建更加流畅和高效的应用程序。通过深入分析协程的原理与应用场景,结合实际案例,本文将指导读者如何优雅地解决异步任务处理,避免阻塞UI线程,从而优化用户体验。
|
5天前
|
存储 Java Android开发
Android系统 设置第三方应用为默认Launcher实现和原理分析
Android系统 设置第三方应用为默认Launcher实现和原理分析
18 0
|
1天前
|
安全 数据处理 Android开发
构建高效Android应用:Kotlin协程的实践之路
【4月更文挑战第26天】 在面对现代Android开发时,性能优化和流畅的用户体验成为了开发者们追求的目标。Kotlin作为一种现代化的编程语言,通过其协程特性为Android应用带来了前所未有的并发处理能力。本文将深入探讨如何利用Kotlin协程提升Android应用的响应性和效率,同时保持代码的简洁性。我们将从协程的基础概念出发,逐步揭示如何在实际应用中运用这些强大的工具,以及它们如何改善应用架构和用户交互体验。
|
4天前
|
调度 Android开发 开发者
构建高效Android应用:探究Kotlin协程的优势与实践
【4月更文挑战第24天】随着移动开发技术的不断演进,提升应用性能和用户体验已成为开发者的核心任务。在Android平台上,Kotlin语言凭借其简洁性和功能性成为主流选择之一。特别是Kotlin的协程功能,它为异步编程提供了一种轻量级的解决方案,使得处理并发任务更加高效和简洁。本文将深入探讨Kotlin协程在Android开发中的应用,通过实际案例分析协程如何优化应用性能,以及如何在项目中实现协程。