ActivityManagerService源码探索

Activity可以说是我们开发Android最早接触的内容了，那么系统是怎样创建、维护Activity的，整个应用中的Activity是怎样管理的，这些工作系统都交给了ActivityManagerService来完成，简称AMS。

AMS的好朋友们

AMS全称ActivityManagerService，顾名思义它和Activity的关系一定不浅，那么要了解AMS，从Activity入手一定没错。 在Instrumentation类中，有一个execStartActivity方法，在Activity的启动过程中会调用到它，而这个过程就有AMS的参与。

//Instrumentation源码节选
public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
        IApplicationThread whoThread = (IApplicationThread) contextThread;
    // ...省略部分...
    try {
        intent.migrateExtraStreamToClipData();
        intent.prepareToLeaveProcess(who);
        // 使用ActivityManager调用getService()获取AMS 注释点：1
        int result = ActivityManager.getService().startActivity(whoThread, who.getBasePackageName(), intent,
            intent.resolveTypeIfNeeded(who.getContentResolver()),
            token, target != null ? target.mEmbeddedID : null,
            requestCode, 0, null, options);
        checkStartActivityResult(result, intent);
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
    return null;
}
    
// ActivityManager源码节选
public static IActivityManager getService() {
    return IActivityManagerSingleton.get();
}

private static final Singleton<IActivityManager> IActivityManagerSingleton =
    new Singleton<IActivityManager>() {
        @Override
        protected IActivityManager create() {
            // 注释点：2
            final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
            // 注释点：3
            final IActivityManager am = IActivityManager.Stub.asInterface(b);
            return am;
        }
};
    
    

注释点1ActivityManager中的getService返回的是IActivityManager类型内容，而ServiceManager获取的Service也就是AMS；注释3它是以AIDL的方式获取的，那么我们可以合理推测出来，AMS是继承于IActivityManager.Stub类的。

同时以上的内容也是外部获取AMS的方式，通过ActivityManager.getService()来获取AMS对象。注释2也能看到，AMS是由ServiceManager获取的，而ServiceManager内部缓存了不同的Service对象，根据Service名称来存取，AMS也会缓存在其中。

AMS的好朋友就非ActivityManager莫属了，聪明的朋友光看名字都猜出了大概；实际上在Android7的源码中，AMS不只有ActivityManager陪伴，还有ActivityManagerNative和ActivityManagerProxy一起配合，只是在Android8之后由AIDL简化了这个过程，感兴趣的朋友可以找到源码看下这块。

为什么不直接使用AMS而要通过另外一个类来使用它，这个问题和AMS的启动有关，我们接着往下看。

AMS的启动过程

AMS是一个作为Service来提供服务的对象，前面也提到了，它的使用是外界通过ActivityManager来进行的，而ActivityManager中getService()是一个静态方法，那么也就是说AMS启动的时间点会比较靠前。

前面ActivityManager源码中我们看到了，其内部的getService()是通过ServiceManager来获取AMS的，而ServiceManager的内部是有缓存各类Service的，那么我们找到存入AMS的逻辑，也就找到了AMS启动的线索。

// AMS源码节选
public void setSystemProcess() {
    try {
        ServiceManager.addService(Context.ACTIVITY_SERVICE, this, /* allowIsolated= */ true,
        DUMP_FLAG_PRIORITY_CRITICAL | DUMP_FLAG_PRIORITY_NORMAL | DUMP_FLAG_PROTO);
    }
}

在AMS内部找到setSystemProcess()方法，它的内部就是ServiceManager加入AMS的逻辑，那么我们再跟随着setSystemProcess()往上查找，紧接着就是SystemService，看名字就能认出它，这是系统服务类，我们再往内部探索一下。

// SystemService
private void startBootstrapServices() {
    
    // ...省略部分...

    // Activity manager runs the show.
    traceBeginAndSlog("StartActivityManager");
    mActivityManagerService = mSystemServiceManager.startService(ActivityManagerService.Lifecycle.class).getService();
    // 注释1
    mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
    // 注释2
    mActivityManagerService.setInstaller(installer);
    traceEnd();

    // ...省略部分...

    // Set up the Application instance for the system process and get started.
    traceBeginAndSlog("SetSystemProcess");
    // AMS内部将自身存入ServiceManager
    mActivityManagerService.setSystemProcess();
    traceEnd();

    // ...省略部分...
}

好家伙，它直接明牌了。SystemServiceManager对象非常直接的调用了startService()，而它启动的就是我们一直探寻的AMS，AMS启动后直接调用了两个方法，看看都做了哪些操作。

注释1：AMS内部维护了SystemServiceManager的对象引用，会使用它来进行一些通知和状态获取，这里先不展开了。

注释2：设置Installer的对象引用，这是SystemManager的子类，管理应用的安装逻辑

关于SystemService的启动，看到网上的解析需要追溯到Zygote，Zygote在启动Binder保证进程间通信能力后，就会调用SystemService的main方法，之后SystemService就会调用自身的run()，接着就到了上面提到的**startBootstrapServices()**了。

AMS的内容

说过了AMS的前世和情缘，接下来就要好好看看AMS的今生了。那么AMS除了启动Activity外，还承担了哪些重要的工作。

进程检查

AMS在运行应用程序之前会检查程序需要运行的进程，对应进程已经存在的情况下，就会直接运行应用进程；但是当进程不存在时，Service会通知Zygote来启动对应的进程，之后再启动对应的应用程序。

AMS组成

AMS中有很多组成内容，和Activity有关的就包含了ActivityRecord、TaskRecord、ActivityStack。这三个内容各自维护了和Activity有关的内容，我们详细来看看。

• ActivityRecord

/**
 * An entry in the history stack, representing an activity.
 */
final class ActivityRecord extends ConfigurationContainer implements AppWindowContainerListener {

    final ActivityManagerService service; // owner
    
    final ActivityInfo info; // all about me
    
    final String launchedFromPackage; // always the package who started the activity.
    
    final String taskAffinity; // Activity预想进入的栈
    
    private TaskRecord task;        // 当前Activity所在的TaskRecord
    
    ProcessRecord app;      // 应用进程Record
    
    private ActivityState mState;    // 当前Activity的状态

    // ...内容...
}

ActivityRecord主要用来存储一些和Activity有关的信息，一些常用的内容包括service表示AMS的引用、ActivityInfo主要是描述AndroidManifest中注册Activity时的声明内容；

可以看到ActivityRecord中是会保存它所在栈对应的TaskRecord对象的引用的，那么我们接着来看TaskRecord

• TaskRecord

class TaskRecord extends ConfigurationContainer implements TaskWindowContainerListener {

    final int taskId;       // Unique identifier for this task.

    final ArrayList<ActivityRecord> mActivities;    // Task内部ActivityRecord集合

    private ActivityStack mStack;   // 当前所在的栈对象

    final ActivityManagerService mService;  // AMS应用

TaskRecord中又保存了ActivityStack对象，也就是栈对象；而我们知道，应用在运行中是会维护Activity栈的，我们再来看下ActivityStack的内容，尝试梳理一下它们的关系。

• ActivityStack

class ActivityStack<T extends StackWindowController> extends ConfigurationContainer
        implements StackWindowListener {
    
    // Activity的各种状态
    enum ActivityState {
        INITIALIZING,
        RESUMED,
        PAUSING,
        PAUSED,
        STOPPING,
        STOPPED,
        FINISHING,
        DESTROYING,
        DESTROYED
    }

    private final ArrayList<TaskRecord> mTaskHistory = new ArrayList<>();

    final ArrayList<ActivityRecord> mLRUActivities = new ArrayList<>();

可以看到ActivityStack中保存了TaskRecord的集合；同时还保存了一份ActivityRecord，并且根据命名来看，这份集合的保存方式是按照LRU算法来维护的，这一点比较我们的Recent Activity来说是一致的。

到了这里，AMS的相关内容就梳理了一遍了，还有更多的内容在源码中，感兴趣的朋友可以深入的阅读。

这次了解了访问AMS的路径，AMS创建的过程，以及AMS中一些主要的内容；而ASM的主要工作也就是对应Activity的一系列操作了，在最初阅读源码时也接触过了Activity的启动过程，这里面就是主要就是AMS处理的工作。