AIDL 在 AMS 中的使用

前面跟着书本整理过 AMS 相关的源码 Android 进阶解密阅读笔记7，不过那时对 AIDL 的使用还不理解，后面我就去看了 Binder 机制还有 AIDL 相关的内容，现在在回过头来看看 AMS 具体怎么使用的。

public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, String resultWho, Intent intent, int requestCode, Bundle options, UserHandle user) {
    //在 API 29 里启动 Activity 已经不归 AMS 负责了，而是交给了 ATMS 
    int result = ActivityTaskManager.getService().startActivityAsUser(whoThread, who.getBasePackageName(), intent,intent.resolveTypeIfNeeded(who.getContentResolver()),
token, resultWho,requestCode, 0, null, options, user.getIdentifier());
}

这里我看的是 API 29 的源码，虽然不再是 ActivityManagerService 负责，但主体逻辑还是不变，只不过现在分工更加细致明确而已。原本是分析 AMS 的，这里就拿 ActivityTaskManagerService 来分析吧。

public static IActivityTaskManager getService() {
    return IActivityTaskManagerSingleton.get();
}
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton = new Singleton<IActivityTaskManager>() {
    @Override
    protected IActivityTaskManager create() {
        final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
        return IActivityTaskManager.Stub.asInterface(b);
    }
}

相对于 ActivityManager，同样衍生出一个 ActivityTaskManager，并提供了 getService 方法用于获取 IActivityTaskManager。IActivityTaskManager 一看就是个接口，从源码上看，它是个 aidl 文件。那这么一来，它会生成相对应的 IActivityTaskManager.java 文件，并在内部还有 Stub，Proxy 这样的内部类。

所以在上面的 create 方法中，首先通过 ServiceManager 获取到 activity_task 服务，返回的 IBinder 类型 b 其实就是在系统服务进程中的 ATMS 服务的 Binder 实体，再通过 IActivityTaskManager.Stub 进行了转化成接口引用，这样应用进程就能用了。

不过使用 AIDL 是需要我们做两个工作的，1.定义接口上面已经提到，就是 IActivityTaskManager。2.实例化静态内部类 Stub。其实 ActivityTaskManagerService 继承了 IActivityTaskManager.Stub 也就是为了实现接口定义的方法，所以实例化对象就是系统服务进程启动时创建的。

所以 ATMS 家族包括 IActivityTaskManager 接口，IActivityTaskManager.Stub 及其子类 ActivityTaskManagerService，还有我们表面上看不到的 IActivityTaskManager.Proxy。这样就得出了和书中一样的结论了。

虽然启动 Activity 不再交给 AMS 了，但 AMS 在其他功能还是有用的，并且其实现及使用过程和 ATMS 几乎没有区别，我理解的 ATMS 其实像是 AMS 分出来的一部分，专门提供 Activity 相关的服务吧。