Activity的启动流程分析与总结

参考文献：刘望舒《Android进阶解密》

前言

​ 看了数篇分析Activity启动流程的文章，但是自从看了《Android进阶解密》关于Activity启动流程的分析，我就放弃了自己撸一遍的念头。因为书里关于这部分的分析比较详细。这里记录一下书中关于Activity的启动流程。加深一下印象，便于以后温习查看。
Activity的启动过程分为两种，一种是根Activity的启动过程，可以认为是初次点击桌面的应用图标，启动Manifest中注册的作为应用的启动页面的Activity。根Activity的启动过程也可以理解为应用程序的启动过程。另一种就是普通Activity的启动过程，也就是根Activity以外的Activity的启动过程。这两种Activity的启动过程有重叠的部分，但是根Activity一般理解为应用程序的启动过程，更具有指导意义。因此本文就根Activity的启动过程进行分析。

谈到Activity的启动流程就绕不开ActivityManagerService(简称AMS)，它主要负责四大组件的启动、切换、调度以及进程的管理，是Android中最核心的服务，参与了所有应用程序的启动管理。Activity的启动流程围绕AMS，可以大致分为3个部分：

• Launcher请求AMS的过程
• AMS到ApplicationThread的调用过程
• ActivityThread启动Activity的过程

下面就针对这3个部分逐一进行分析。

1.Launcher请求AMS的过程

该过程的时序图如下：

当我们点击桌面的应用快捷图标时，就会调用Launcher的startActivitySafely方法：

public boolean startActivitySafely(View v, Intent intent, ItemInfo item) {
   
    ...
    // Prepare intent
    // 注释1
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    ...
            // Could be launching some bookkeeping activity
        	// 注释2
            startActivity(intent, optsBundle);
    ...
}

对于不太需要关注的代码省略了，主要是走调用流程，对关键代码进行分析，在注释1处将Flag设置为Intent.FLAG_ACTIVITY_NEW_TASK，这样根Activity会在新的任务栈中启动。在注释2处调用startActivity方法，这个方法在Activity中实现，Activity中startActivity方法有好几种重载方式，但它们最终都会调用startActivityForResult方法：

public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
            @Nullable Bundle options) {
   
    	// 注释1
        if (mParent == null) {
   
            options = transferSpringboardActivityOptions(options);
            // 注释2
            Instrumentation.ActivityResult ar =
                mInstrumentation.execStartActivity(
                    this, mMainThread.getApplicationThread(), mToken, this,
                    intent, requestCode, options);
            ...
        } else {
   
            ...
        }
    }

注释1处的mParent是Activity类型的，表示当前Activity的父类，因为目前根Activity还没有创建出来，因此mParent==null成立，执行注释2处的逻辑，调用Instrumentation的execStartActivity方法，Instrumentation主要是用来监控应用程序和系统的交互，execStartActivity方法代码如下：

public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
   
        ...
        try {
   
            intent.migrateExtraStreamToClipData();
            intent.prepareToLeaveProcess(who);
            // 注释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;
    }

核心逻辑就是注释1的代码，首先调用ActivityManager的getService方法来获取AMS的代理对象，接着调用startActivity方法。我们先进入ActivityManager的getService方法：

public static IActivityManager getService() {
   
        return IActivityManagerSingleton.get();
    }

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

getService方法调用了IActivityManagerSingleton的get方法，看一下Singleton代码

public abstract class Singleton<T> {
   
    private T mInstance;

    protected abstract T create();

    public final T get() {
   
        synchronized (this) {
   
            if (mInstance == null) {
   
                mInstance = create();
            }
            return mInstance;
        }
    }
}

不难发现IActivityManagerSingleton的get方法，会调用create方法，在注释1处得到IBinder类型的AMS引用，接着在注释2处将它转化成IActivityManager类型的对象，即AMS的代理对象，这段代码采用的是AIDL，IActivityManager.java类是由AIDL工具在编译时自动生成的。AMS继承IActivityManager.Stub类并实现相关方法。通过这个代理对象和AMS(AMS所在的进程为SystemServer系统服务进程)进行跨进程通信，如果你对Binder机制有一定的认识，这里就比较好理解。如果还不太熟悉Binder机制，强烈建议一定要补一下，要不然分析源码总会一知半解的。需要注意的Android8.0之前并没有采用AIDL，是用AMS的代理对象ActivityManagerProxy来与AMS进行跨进程通信的。Android8.0去除了ActivityManagerNative的内部类ActivityManagerProxy，代替它的是IActivityManager，它就是AMS的代理对象。经过上面的分析，我们知道execActivity方法最终调用的是AMS的startActivity方法。补充一句，这里就由Launcher进程经过一系列调用到了SystemServer进程，可以简单概括为下图：

2.AMS到ApplicationThread的调用过程

Launcher请求AMS后，代码逻辑进入AMS中，接着是AMS到ApplicationThread的调用流程，时序图如下：

AMS的startActivity方法如下：

@Override
public final int startActivity(IApplicationThread caller, String callingPackage,
         Intent intent, String resolvedType, IBinder resultTo, String resultWho, 
         int requestCode, int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
   
	return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
            resultWho, requestCode, startFlags, profilerInfo, bOptions,
            UserHandle.getCallingUserId());
}

AMS的startActivity方法中返回了startActivityAsUser方法，可以发现startActivityAsUser方法比startActivity方法多了一个参数UserHandle.getCallingUserId(),这个方法会获得调用者的UserId,AMS根据这个UserId来确定调用者的权限。下面进入startActivityAsUser方法：

@Override
public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
       Intent intent, String resolvedType, IBinder resultTo, String resultWho, 
       int requestCode,int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, 
       int userId) {
   
    // 注释1
    // 判断调用者进程是否被隔离
    enforceNotIsolatedCaller("startActivity");
    // 注释2
    // 检查调用者的权限
    userId = mUserController.handleIncomingUser(Binder.getCallingPid(),
             Binder.getCallingUid(),userId, false, ALLOW_FULL_ONLY, 
             "startActivity", null);
    // TODO: Switch to user app stacks here.
	return