每日一题：Activity启动流程分析-六虎

在android面试中，咱们常会遇到Framework面试相关问题，而今天要共享的便是Activity发动流程剖析

其首要调查的是程序员对activity 的发动进程，以及发动进程中各大类的联系。

问题正解：

Activity的发动进程一般有两种情况：第一种，activity地点的进程没有创立，那么这个进程就会涉及到App进程的创立，咱们能够在《Android app进程是怎样发动的》的章节去得到具体阐明，在这儿就不赘述了；第二种，App进程存在，那么对应的Activity发动流程将是下面剖析的要点。

下文会剖析整个activity 发动的流程，一同剖析一下它的生命周期的切换进程，最终再剖析一下办理activity的几个类的根本情况。

1.Activity发动流程

平时咱们开发的运用都是展示在Android体系桌面上，这个体系桌面其实也是一个Android运用，它叫Launcher。所以本文经过源码层面从Launcher调用ATMS，ATMS再经过AMS发送socket恳求给zygote，由zygote fork出app进程，然后再经过反射调用ActivityThread 的main函数，开端运转app进程的代码。在ActivityThread main函数中，会履行AMS的 attachApplication办法，将Application的binder赋值给AMS，然后再由AMS经过这个IBinder去调用ApplicationThread的bindApplication函数履行application的生命周期,紧接着AMS再直线ATMS的attachApplication办法，从而发动Activity并履行Activity的相关生命周期。

下文咱们将要点对Activity发动流程进行剖析。（文中源码根据Android 11 ）。

1.1 Launcher 调用Activity的进程

在这个阶段，Launcher仅仅一个app，当用户点击Launcher上app icon的时分就会履行Launcher中的代码，在这个流程里边，Launcher首要会经过Instrumentation类跨进程调用ATMS（android 10之前是AMS）的代码去发动Activity，具体的其他细节不是咱们重视的要点，有感爱好的同学能够自行查看源码进行了解。咱们将剖析的要点放到ATMS发动Activity的流程里边来。

从上图，流程图能够看到，ActivityTaskManagerService是经过ActivityStarter来发动Activity，为什么存在ActivityStarter类呢？

1.1.1 ActivityStarter类的阐明

ActivityStarter它是一个用于解释怎么发动一个Activity的操控器，用来装备actiivty的各种了解并加载发动 Activity 的类，此类记载一切逻辑，用于确定怎么将意图和标志转换为Activity以及关联的使命和堆栈。

在ActivityStarter中包含了一个静态内部类Request，这个类或许十分恰当的阐明ActivityStarter的作用。它的部分代码如下：

static class Request {
   ...
    IApplicationThread caller;
    Intent intent;
    NeededUriGrants intentGrants;
    // A copy of the original requested intent, in case for ephemeral app launch.
    Intent ephemeralIntent;
    String resolvedType;
    ActivityInfo activityInfo;
    ResolveInfo resolveInfo;
    IVoiceInteractionSession voiceSession;
    IVoiceInteractor voiceInteractor;
    IBinder resultTo;
    String resultWho;
    int requestCode;
    int callingPid = DEFAULT_CALLING_PID;
    int callingUid = DEFAULT_CALLING_UID;
    String callingPackage;
    @Nullable String callingFeatureId;
    int realCallingPid = DEFAULT_REAL_CALLING_PID;
    int realCallingUid = DEFAULT_REAL_CALLING_UID;
    int startFlags;
    SafeActivityOptions activityOptions;
    boolean ignoreTargetSecurity;
    boolean componentSpecified;
    boolean avoidMoveToFront;
    ActivityRecord[] outActivity;
    Task inTask;
    String reason;
    ProfilerInfo profilerInfo;
    Configuration globalConfig;
    int userId;
    WaitResult waitResult;
    int filterCallingUid;
    PendingIntentRecord originatingPendingIntent;
    boolean allowBackgroundActivityStart;
   ...
}

上面的代码咱们不能发现，这个类里边有十分多的参数，而这些参数就包含了发动activity的相关信息和被发动Activity的相关信息。咱们不难知道，在发动activity之前把一切信息都预备全，这个作业就需求交给ActivityStarter类来做。别的，ActivityA发动ActivityB时，代码是这样的：startActivity(new Intent(ActivityA.this,ActivityB.class))，参数信息只要三个Intent，context和ActivityB.class，这些信息就会在ActivtyStarter类中被封装成为一个request，有了这些信息，才能去进行发动的下一步作业。

咱们一同来看一下图29-1中的step 4 executeRequest的代码：

private int executeRequest(Request request) {
    ActivityInfo aInfo = request.activityInfo;
    ResolveInfo rInfo = request.resolveInfo;
    String resultWho = request.resultWho;
    Task inTask = request.inTask;
    
    ActivityRecord sourceRecord = null;//code 1
    ActivityRecord resultRecord = null;//code 2
    
    if (resultTo != null) {
      sourceRecord = mRootWindowContainer.isInAnyStack(resultTo); //code 3
       ......
      if (sourceRecord != null) {
        if (requestCode >= 0 && !sourceRecord.finishing) {
          resultRecord = sourceRecord;
         }
       }
     }
     ......
    //code 4
    final ActivityRecord r = new ActivityRecord(mService,callerApp, callingPid, 
           callingUid, callingPackage, callingFeatureId, intent, resolvedType, 
        aInfo,mService.getGlobalConfiguration(), resultRecord, resultWho, 
        requestCode,request.componentSpecified, voiceSession != null, 
        mSupervisor, checkedOptions, sourceRecord);
    //code 5
    mLastStartActivityResult = startActivityUnchecked(r, sourceRecord, voiceSession,
        request.voiceInteractor, startFlags, true /* doResume */, checkedOptions,
        inTask,restrictedBgActivity, intentGrants);
}

1)上面代码中code 1 &code 2 界说了两个ActivityRecord；

2）code3处初始化sourceRecord，这个sourceRecord，便是构建了当时发动Activity的activity在AMS中的ActivtyRecord。比方ActivityA发动ActivityB，那么这个ActivityRecord便是ActivityA 在AMS中的存在形式。当然这也便是说要在发动新Activity之前要知道sourceReord是谁。

3）code4 new了一个ActivityRecord，它便是要被发动的Activity。

4）code5 调了startActivityUnchecked()办法，履行下一步的生命周期流程的调度。

1.1.2 ActivityStartController类

这个类相对较简略，看名字知道它是一个ActivityStart的操控器，这个类首要是接纳Activity发动的各种恳求，并将这些恳求封装成为一个能够被ActivityStarter处理的活动。所以，ActivityStarter方针的产生，是由ActivityStartController供给的。一同，它还会负责处理环绕活动发动流程开端的环节的逻辑，如图29-1中的第5步，当app中有一系列的activity处于pending需求发动的时分，这个时分就会调用doPendingActivityLaunches办法，处理一切的pending的activity。

void doPendingActivityLaunches(boolean doResume) {
  //循环获取一切的pending情况的Activity，并履行发动逻辑
    while (!mPendingActivityLaunches.isEmpty()) {
        final PendingActivityLaunch pal = mPendingActivityLaunches.remove(0);
        final boolean resume = doResume && mPendingActivityLaunches.isEmpty();
        final ActivityStarter starter = obtainStarter(null /* intent */,
                "pendingActivityLaunch");
        try {
            starter.startResolvedActivity(pal.r, pal.sourceRecord, null, null, 
            pal.startFlags, resume, pal.r.pendingOptions, null, pal.intentGrants);
        } catch (Exception e) {
            Slog.e(TAG, "Exception during pending activity launch pal=" + pal, e);
            pal.sendErrorResult(e.getMessage());
        }
    }
}

经过上面的代码，咱们不难发现在图29-1中的第5步，所走的代码，其实便是将一切要发动而没有发动的Activity们进行共同的发动办理，仅仅真实发动的进程依旧交由AcitivityStarter的startResolvedActivity去完结。

1.1.3 发动期间的黑白屏现象

在app发动的时分，在AcitivityStarter发动activity的时分会有一个特殊的进程，这个进程便是发动一个黑白屏，用于提醒用户，正在发动新的app。那么这个发动黑白屏的进程是怎样的的呢？

咱们一同来看一下图29-1中的第8步的代码startActivityInner。

int startActivityInner(final ActivityRecord r, ActivityRecord sourceRecord,
        IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
        int startFlags, boolean doResume, ActivityOptions options, Task inTask,
        boolean restrictedBgActivity, NeededUriGrants intentGrants) {
    //初始化装备，mStartActivity、mLaunchMode等
    setInitialState(r, options, inTask, doResume, startFlags, sourceRecord, voiceSession,
            voiceInteractor, restrictedBgActivity);

     // 核算要发动的Activity的task标志，也便是核算发动形式
    computeLaunchingTaskFlags();
    computeSourceStack();

    //将mLaunchFlags设置给Intent，也便是设置发动形式
    mIntent.setFlags(mLaunchFlags);

    final Task reusedTask = getReusableTask();

    ......
    // Compute if there is an existing task that should be used for.
    final Task targetTask = reusedTask != null ? reusedTask : computeTargetTask();
    final boolean newTask = targetTask == null;
    mTargetTask = targetTask;

    computeLaunchParams(r, sourceRecord, targetTask);

    ...

  // code1
    // 创立发动黑白屏window
    mTargetStack.startActivityLocked(mStartActivity,
            topStack != null ? topStack.getTopNonFinishingActivity() : null, newTask,
            mKeepCurTransition, mOptions);
    if (mDoResume) {
        final ActivityRecord topTaskActivity =
                mStartActivity.getTask().topRunningActivityLocked();
        if (!mTargetStack.isTopActivityFocusable()
                || (topTaskActivity != null && topTaskActivity.isTaskOverlay()
                && mStartActivity != topTaskActivity)) {
            mTargetStack.ensureActivitiesVisible(null /* starting */,
                    0 /* configChanges */, !PRESERVE_WINDOWS);
            mTargetStack.getDisplay().mDisplayContent.executeAppTransition();
        } else {
            if (mTargetStack.isTopActivityFocusable()
                    && !mRootWindowContainer.isTopDisplayFocusedStack(mTargetStack)) {
                mTargetStack.moveToFront("startActivityInner");
            }
            //code2 将发动流程交给RootWindowContainer去履行，并经过
            mRootWindowContainer.resumeFocusedStacksTopActivities(
                    mTargetStack, mStartActivity, mOptions);
        }
    }
    ......

    return START_SUCCESS;
}

函数一开端先初始化发动activity需求的装备，然后再根据装备参数核算出发动形式，并将发动形式设置给Intent作为后期备用的变量。接着会运转到code1，此刻便是创立一个黑白屏。在剖析黑白屏创立办法前，咱们先剖析一下黑白屏为什么在Activity进程创立之前会发动？

当用户点击Launcher界面app icon的时分，为了让点击者在第一时间能够感受到点击的呼应，此刻有必要要有界面切换来证明改动的存在。在app发动流程中，假如在app进程创立后才显现这个黑白屏，那么Launcher界面将出现一个比较长的等待时间，这将会被用户错误的认知为点击没有及时呼应。因而，在app进程还没有创立的时分，在发动activity的进程中，一旦设置了activity的发动形式就马上创立一个黑白屏，用于联接点击app icon到app真实显现这中心的时间空隙，这也是在activity发动进程中的一个巧妙规划。关于黑白屏的具体显现流程，感爱好的朋友能够去阅览其他相关章节补充学习。

1.1.4 RootWindowContainer类的阐明

Android10新增的类，当activity发动的时分，会将整个发动流程转交给RootWindowContainer去履行，为什么会这样去做了？咱们接下来剖析。

RootWindowContainer是窗口容器（WindowContainer）的根容器，办理了一切窗口容器，设备上一切的窗口（Window）、显现（Display）都是由它来办理的。resumeFocusedStacksTopActivities函数会恢复对应使命栈顶部的Activity。这个办法会查看一些可见性相关的特点，假如当时需求resume的activityStack 是可见的，这个时分才resume，而可见性是由RootWindowContainer中的窗口操控的。所以，每个activity都有自己的窗口，为了操控activity窗口的可见性，Activity的发动有必要经过RootWindowContainer。

1.1.5 小结

从图29-1能够看出，Activity的发动会有一个相对绵长的前期预备阶段，这个阶段所做的事情如下：

1）ATMS发出发动activity的恳求；

2）将发动Activity的动作所需求预备的参数全部封装成为ActivityStarter里边的参数，也便是说ActivityStarter存储了一个activity发动所需求的一切的参数；

3）因为或许存在一次发动多个Activity的情况，或许积累了多个activity需求发动的情况，所以此刻需求将一切能够发动的activity进行发动，因而发动流程需求去走到ActivityStarterController里边进行处理；

4）当真实发动Activity的时分，假如是发动的application的launcher activity，那么咱们需求先供给一个黑白屏，因为在用户点击发动application的时分，用户需求对发动App这个动作有感知，但是此刻App发动或许比较缓慢没办法马上显现，因而就需求先创立一个黑白屏。

5）因为发动activity会改动activity的窗口的可见性，而这个可见性的办理是由RootWindowContainer进行，因而在发动路上需求经过这个类来进行可见性操控的办理。

接下来，咱们继续剖析Activity的发动流程

1.2 Activity发动流程在AMS中的履行

图29-2

1.2.1 ActivityRecord，Task，ActivityStack，ActivityStackSupervisor类阐明

咱们要了解Activity发动流程，首先是要了解一些要害类的信息。

ActivityRecord：一个ActivityRecord对应着一个Activity，保存着一个Activity的一切信息；但是一个Activity或许会有多个ActivityRecord，因为Activity或许会被发动屡次，首要是取决于Activity的发动形式。

Task：Android体系中的每个Activity都坐落一个Task中。一个Task能够包含多个Activity，同一个Activity也或许有多个实例。在AndroidManifest.xml中，咱们能够经过 android:launchMode 来操控Activity在Task中的实例。Task办理的意义还在于近期使命列表以及Back栈。当你经过多使命键（有些设备上是长按Home键。有些设备上是专门供给的多使命键）调出多使命时，事实上便是从ActivityManagerService获取了近期发动的Task列表。

ActivityStack：Task是它的父类，是一个办理类，办理着一切Activity，内部保护了Activity的一切情况、特殊情况的Actvity和Activity以及相关的列表数据。

ActivityStackSupervisor：ActivityStack是由ActivityStackSupervisor来进行办理，而这个是在ATMS的initialize中被创立出来的。ATMS初始化的时分，会创立一个ActivityStackSupervisor方针用于共同办理一些业务：1）将显现层次结构相关的内容移动到RootWindowContainer中；2）将与activity生命周期相关的业务的处理转交给ActivityLifeCyler处理；3）处理点击物理按键Menu键后使命栈的处理。

注意：在Android 11版本中上面的类的划分已经和之前的版本进行了十分大的修改，所以责任也各不相同，编者注意到在Android12版本中，已经去掉了ActivityStack类和ActivityStackSupervisor类，代替他们的是Task类和ActivityTaskSupervisor类，感爱好的读者能够拿源码进行阅览。

小结：在AMS发动的时分，会创立一个ActivityStackSupervisor方针，ActivityStackSupervisor创立和办理Android体系中一切运用的ActivityStack，一个ActivityStack对应和包含一个运用中一切的栈。

有了以上对类的根本了解，咱们就很简单了解图29-2的流程了。

一个app一切的Activity都会被ActivityStack进行办理，因而发动Activity自然也是在ActivityStack中进行，所以在完结发动流程的前9步预备作业后，自然就在第10步迈入了ActivityStack中。ActivityStack开端真实的发动Activity的时分，需求先履行12步，第12步会先让当时正在显现的Activity履行它的pause生命周期，然后再去履行13步：预备发动指定的Activity。

咱们能够看一下ActivityStack中下面的核心代码

private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
    ...
    // 停止当时的Activity
    if (mResumedActivity != null) {
        if (DEBUG_STATES) Slog.d(TAG_STATES,
                "resumeTopActivityLocked: Pausing " + mResumedActivity);
        // 停止当时的Activity
        pausing |= startPausingLocked(userLeaving, false /* uiSleeping */, next);//code1
    }
    ...
    if (next.attachedToProcess()){
    ...
    } else {
        ...
        //发动指定的Activity
        mStackSupervisor.startSpecificActivity(next, true, true); //code2
    }

    return true;
}

经过上面的code1，此处代码是用于pause 当时activity的代码，code2 则是发动特定Activity的代码。

关于startPausingLocked() 办法去触发当时Activity履行pause生命周期的具体流程，咱们就不做体系剖析了，大致流程会和履行activity onCreate的流程共同，感爱好的读者能够自行阅览源码。咱们将要点放到Activity发动上面来，所以请咱们看下面的ClientTransaction传递流程。

1.3 Activity发动中事情的跨进程通信

图 29-4

从Android 8之后，activity的发动流程就加入了触发器的机制，这个机制出现的目的是为了更加友爱的办理activity的生命周期，但是，本人感觉它更让人费解了。不管怎样，咱们一同剖析一下它的流程和类的联系，用于帮助咱们了解这个流程。

ClientLifecycleManager 是办理 Activity 生命周期的，在 ActivityTaskManagerService 里边供给 getLifecycleManager 来获取此方针，其间 mLifecycleManager 是在 ActivityTaskManagerService 的构造办法里边初始化的。

public class ActivityTaskManagerService extends IActivityTaskManager.Stub {
   ......
  private final ClientLifecycleManager mLifecycleManager;
   ......
  public ActivityTaskManagerService(Context context) {
    mContext = context;
    mFactoryTest = FactoryTest.getMode();
    mSystemThread = ActivityThread.currentActivityThread();
    mUiContext = mSystemThread.getSystemUiContext();
    mLifecycleManager = new ClientLifecycleManager();//mLifecycleManager初始化
    mInternal = new LocalService();
     ......
   }
   ......
  //获取mLifecycleManager方针
  ClientLifecycleManager getLifecycleManager() {
    return mLifecycleManager;
   }
   ......
}

小结

图29-4展示的代码履行流程能够知道，第15步，生命周期的履行是ActivityStackSupervisor这个activity栈的大管家拿着在ATMS中所创立的ClientLifecycleManager去履行生命周期的触发器。而生命周期的处理有必要要经过生命周期事物存储的容器来分发，也便是第16步走ClientTransaction。但是Activity生命周期的履行到现在停止仍是在SystemServer进程也便是在AMS地点的进程中，终究Activity的生命周期的履行还有必要是在App进程中，所以就有了第17步，经过binder调用将生命周期的履行分发给Activity地点的进程去履行。当IApplicationThread 收到AMS地点进程发送过来的生命周期处理音讯的时分，开端发送一个handler事情来处理这个生命周期，这便是第18步的履行。最终，app进程会去履行生命周期的触发器来处理ClientTransation事情。

请咱们要点重视一个细节，也便是第17步，进程间完结了一次从systemServer进程到Activity地点的app进程进行切换的进程。

1.4 运用进程中生命周期的履行流程

生命周期的履行到现在这一步算是一个重要的分水岭，因为接下来的履行进程全部是在App进程中进行，接下来的履行流程咱们能够看一下下面的流程图。

图 29-5

在履行发动流程中，咱们先来看第14步ActivityStackSupervisor中的realStartActivityLocked函数一段核心代码：

boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
        boolean andResume, boolean checkConfig) throws RemoteException {

    ......
    // Create activity launch transaction.
    // 创立 clientTransaction 方针
    final ClientTransaction clientTransaction = ClientTransaction.obtain(
            proc.getThread(), r.appToken);

    final DisplayContent dc = r.getDisplay().mDisplayContent;
    //code1
    // 增加LaunchActivityItem
    clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
            System.identityHashCode(r), r.info,
            // TODO: Have this take the merged configuration instead of separate global
            // and override configs.
            mergedConfiguration.getGlobalConfiguration(),
            mergedConfiguration.getOverrideConfiguration(), r.compat,
            r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
            r.getSavedState(), r.getPersistentSavedState(), results, newIntents,
            dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
            r.assistToken, r.createFixedRotationAdjustmentsIfNeeded()));

    // Set desired final state.
    final ActivityLifecycleItem lifecycleItem;
    if (andResume) {
        //需求Rusume的话，设置ResumeActivityItem到clientTransaction中
        lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
    } else {
        lifecycleItem = PauseActivityItem.obtain();
    }
  //code 2
    clientTransaction.setLifecycleStateRequest(lifecycleItem);

    // code3
    // Schedule transaction.
    // 获取生命周期办理类 ClientLifecycleManager，并履行业务
    mService.getLifecycleManager().scheduleTransaction(clientTransaction);
    ......
    return true;
}

以上代码创立了一个clientTransaction方针，并设置了clientTransaction方针的各参数。从上面的代码code1，咱们构建了一个LaunchActivityItem，并且将它增加到了clientTransaction的Callback列表中；然后在code2中往clientTransaction中设置了当时阶段终究想要履行的生命周期情况，也便是到生命周期的resume情况，所以再code2 代码处向clientTransation中设置了LifecycleStateRequest，也便是本次transaction希望履行的activity的生命周期的终究的情况，也便是增加了ResumeActivityItem，终究情况是activity的resume；最终在code3 把这个封装的clientTransaction 传递给了ClientLifecycleManager，这个clientTransaction方针被第17步的跨进程通信传给了app进程，所以接下来生命周期的履行就会依照AMS中构建的生命周期办理主意开端履行，也便是会依照图29-5的流程开端履行。

在Activity发动流程履行到TransactionExecutor中的excute的时分，此刻的代码已经履行到了app进程里边了。咱们一同来看一下第19步execute函数的履行流程，流程中咱们只展示核心代码：

public void execute(ClientTransaction transaction) {
    ......

    executeCallbacks(transaction); //code1

    executeLifecycleState(transaction); //code2
    mPendingActions.clear();
    if (DEBUG_RESOLVER) Slog.d(TAG, tId(transaction) + "End resolving transaction");
}

在第19步，也便是在履行上面的excute函数的时分，会履行两个十分重要的代码：code1&code2，code1便是咱们流程图中的第20步，而code2 便是咱们流程图中的第24步。咱们一同来剖析一下这两个流程：

1.4.1 履行executeCallbacks函数

code1所引发的第20步，这个进程是履行在14步ActivityStackSupervisor中的realStartActivityLocked里边增加的Callback的这个阶段，咱们经过上面代码的剖析能够得到一个定论，这次从第20步履行到第23步，整个流程是环绕当时Activity的launch流程进行。当咱们阅览第22步handleLaunchActivity源码的时分，不难发现，在代码履行中会履行Activity的创立以及attach的生命周期函数，然后再履行onCreate生命周期，具体的代码如下：

ActivityThread.java

public Activity handleLaunchActivity(ActivityClientRecord r,
        PendingTransactionActions pendingActions, Intent customIntent) {
    ......
    WindowManagerGlobal.initialize(); //code1


    final Activity a = performLaunchActivity(r, customIntent); //code2

    ......
}

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    ......
    ContextImpl appContext = createBaseContextForActivity(r);
    Activity activity = null;
    try {
        java.lang.ClassLoader cl = appContext.getClassLoader();
        //创立一个activity
        activity = mInstrumentation.newActivity( //code 3
                cl, component.getClassName(), r.intent);
        StrictMode.incrementExpectedActivityCount(activity.getClass());
        r.intent.setExtrasClassLoader(cl);
        r.intent.prepareToEnterProcess();
        if (r.state != null) {
            r.state.setClassLoader(cl);
        }
    } catch (Exception e) {
        if (!mInstrumentation.onException(activity, e)) {
            throw new RuntimeException(
                "Unable to instantiate activity " + component
                + ": " + e.toString(), e);
        }
    }

    try {
        //LoadedApk 构建 makeApplication 
        Application app = r.packageInfo.makeApplication(false, mInstrumentation);

        ......

        if (activity != null) {
            ......

            // Activity resources must be initialized with the same loaders as the
            // application context.
            appContext.getResources().addLoaders(
                    app.getResources().getLoaders().toArray(new ResourcesLoader[0]));

            appContext.setOuterContext(activity);
            //code4
            //会在这个办法中创立Activity的PhoneWindow，并绑定对应的WindowManager。
            activity.attach(appContext, this, getInstrumentation(), r.token,
                    r.ident, app, r.intent, r.activityInfo, title, r.parent,
                    r.embeddedID, r.lastNonConfigurationInstances, config,
                    r.referrer, r.voiceInteractor, window, r.configCallback,
                    r.assistToken);

            if (customIntent != null) {
                activity.mIntent = customIntent;
            }
            r.lastNonConfigurationInstances = null;
            checkAndBlockForNetworkAccess();
            activity.mStartedActivity = false;
            int theme = r.activityInfo.getThemeResource();
            if (theme != 0) {
                activity.setTheme(theme);
            }

            activity.mCalled = false;
            //code5
            // 设置 mLifecycleState 为 ON_CREATE
            if (r.isPersistable()) {
                mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
            } else {
                mInstrumentation.callActivityOnCreate(activity, r.state);
            }
            if (!activity.mCalled) {
                throw new SuperNotCalledException(
                    "Activity " + r.intent.getComponent().toShortString() +
                    " did not call through to super.onCreate()");
            }
            r.activity = activity;
            mLastReportedWindowingMode.put(activity.getActivityToken(),
                    config.windowConfiguration.getWindowingMode());
        }
        // 设置 mLifecycleState 为 ON_CREATE
        r.setState(ON_CREATE);

        // updatePendingActivityConfiguration() reads from mActivities to update
        // ActivityClientRecord which runs in a different thread. Protect modifications to
        // mActivities to avoid race.
        synchronized (mResourcesManager) {
            mActivities.put(r.token, r);
        }

    } catch (SuperNotCalledException e) {
        throw e;

    } catch (Exception e) {
        if (!mInstrumentation.onException(activity, e)) {
            throw new RuntimeException(
                "Unable to start activity " + component
                + ": " + e.toString(), e);
        }
    }

    return activity;
}

上面代码code1处是发动windowManagerGlobal，因为windowManagerGlobal是单例形式，所以，一般认为windowManagerGlobal的初始化便是在此刻，其实便是为activity预备WindowManagerService。在code2处，将履行performLaunchActivity，咱们仔细阅览performLaunchActivity的函数会不难发现 code3处创立了一个activity实例方针。然后履行到code4处，此处履行了activity的attach 生命周期，在这个生命周期里边，构建了activity的仅有的phoneWindow方针，并且并绑定对应的WindowManager方便后期运用。然后代码会履行到code5，在code5里边便是调用Activity的onCreate生命周期的进程，一同mLifecycleState被设置为ON_CREATE，这个情况在后面履行第26步的时分将会用到。

1.4.2 履行executeLifecycleState函数

上面首要介绍了 TransactionExecutor#execute履行executeCallbacks的进程，下面咱们一同介绍一下履行executeLifecycleState的进程，也便是履行第24步到31步的进程。

private void executeLifecycleState(ClientTransaction transaction) {
    //获取ActivityLifecycleItem，咱们知道这儿获取的是咱们之前增加的ResumeActivityItem
    //其值是由第14步ActivityStackSupervisor中的realStartActivityLocked函数
    final ActivityLifecycleItem lifecycleItem =     
      transaction.getLifecycleStateRequest();
    if (lifecycleItem == null) {
      // No lifecycle request, return early.
      return;
     }

    final IBinder token = transaction.getActivityToken();
    final ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
    if (DEBUG_RESOLVER) {
      Slog.d(TAG, tId(transaction) + "Resolving lifecycle state: "
          + lifecycleItem + " for activity: "
          + getShortActivityName(token, mTransactionHandler));
     }

    if (r == null) {
      // Ignore requests for non-existent client records for now.
      return;
     }

    // Cycle to the state right before the final requested state.
    //code1 要害点,ResumeActivityItem的getTargetState　是　ON_RESUME
    cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */, 
          transaction);

    // Execute the final transition with proper parameters.
    //code2 履行 ResumeActivityItem 的 execute
    lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
    lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}

从上面的代码，咱们发现code1处有一个十分重要的函数cycleToPath(),其间的 lifecycleItem.getTargetState() 回来值是 ON_RESUME。

private void cycleToPath(ActivityClientRecord r, int finish, boolean excludeLastState,
      ClientTransaction transaction) {
    //这儿在performLaunchActivity设置了LifecycleState为ON_CREATE,即：start是ON_CREATE，
    final int start = r.getLifecycleState();
    if (DEBUG_RESOLVER) {
      Slog.d(TAG, tId(transaction) + "Cycle activity: "
          + getShortActivityName(r.token, mTransactionHandler)
          + " from: " + getStateName(start) + " to: " + getStateName(finish)
          + " excludeLastState: " + excludeLastState);
     }
    //这儿的 start 是 ON_CREATE,finish 是 ON_RESUME
    //经过 mHelper 调用 getLifecyclePath 回来的 path 是 ON_START，下面会有解析
    //这儿是 Activity 履行 onStart 函数的要害地点
    final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);
    //履行path中的相关的生命周期函数
    performLifecycleSequence(r, path, transaction);
}

private void performLifecycleSequence(ActivityClientRecord r, IntArray path,
      ClientTransaction transaction) {
    //经过mHelper调用getLifecyclePath回来的path 是 ON_START
    final int size = path.size();
    for (int i = 0, state; i < size; i++) {
      state = path.get(i);
      if (DEBUG_RESOLVER) {
        Slog.d(TAG, tId(transaction) + "Transitioning activity: "
            + getShortActivityName(r.token, mTransactionHandler)
            + " to state: " + getStateName(state));
       }
      switch (state) {
        case ON_CREATE:
          mTransactionHandler.handleLaunchActivity(r, mPendingActions,
              null /* customIntent */);
          break;
        case ON_START:
          mTransactionHandler.handleStartActivity(r, mPendingActions);
          break;
        case ON_RESUME:
          mTransactionHandler.handleResumeActivity(r.token, false /* finalStateRequest */,
              r.isForward, "LIFECYCLER_RESUME_ACTIVITY");
          break;
        case ON_PAUSE:
          mTransactionHandler.handlePauseActivity(r.token, false /* finished */,
              false /* userLeaving */, 0 /* configChanges */, mPendingActions,
              "LIFECYCLER_PAUSE_ACTIVITY");
          break;
        case ON_STOP:
          mTransactionHandler.handleStopActivity(r.token, false /* show */,
              0 /* configChanges */, mPendingActions, false /* finalStateRequest */,
              "LIFECYCLER_STOP_ACTIVITY");
          break;
        case ON_DESTROY:
          mTransactionHandler.handleDestroyActivity(r.token, false /* finishing */,
              0 /* configChanges */, false /* getNonConfigInstance */,
              "performLifecycleSequence. cycling to:" + path.get(size - 1));
          break;
        case ON_RESTART:
          mTransactionHandler.performRestartActivity(r.token, false /* start */);
          break;
        default:
          throw new IllegalArgumentException("Unexpected lifecycle state: " + state);
       }
     }
}

//TransactionExecutorHelper.java
//excludeLastState 为 true, start 为 ON_CREATE（1）,finish 为 ON_RESUME（3）
public IntArray getLifecyclePath(int start, int finish, boolean excludeLastState) {
    if (start == UNDEFINED || finish == UNDEFINED) {
      throw new IllegalArgumentException("Can't resolve lifecycle path for undefined state");
     }
    if (start == ON_RESTART || finish == ON_RESTART) {
      throw new IllegalArgumentException(
          "Can't start or finish in intermittent RESTART state");
     }
    if (finish == PRE_ON_CREATE && start != finish) {
      throw new IllegalArgumentException("Can only start in pre-onCreate state");
     }

    mLifecycleSequence.clear();
    if (finish >= start) {//走到此分支
      // just go there
      for (int i = start + 1; i <= finish; i++) {
      //把　ON_START　和 ON_RESUME 增加到 mLifecycleSequence 中
        mLifecycleSequence.add(i);
       }
     } else { // finish < start, can't just cycle down
       ......
     }

    // Remove last transition in case we want to perform it with some specific params.
    //　要害点:因为 excludeLastState 为 true,所以删除去 ON_RESUME 情况
    if (excludeLastState && mLifecycleSequence.size() != 0) {
      mLifecycleSequence.remove(mLifecycleSequence.size() - 1);
     }

    return mLifecycleSequence;
   }

经过以上代码逻辑结构，咱们不难发现，整个进程是根据activity 的lifecycle的初始情况以及方针情况来进行运算，找到中心需求呼应的其他生命周期情况，也便是核算从ON_CREATE作为start的情况（在ActivityThread 中履行performLaunchActivity的进程中设置的），到以ON_RESUME作为生命周期结束情况，然后核算其间还需求经历的生命周期进程，也便是ON_START情况的进程。其实这也便是为什么activity生命周期被封装成为触发器Transaction的进程。

然后，咱们再重新回到executeLifecycleState的履行，当这个函数履行完结cycleToPath函数之后（里边会触发ActivityThread的handleStartActivity去履行acitivty的onStart 生命周期）就会运转到code2部分的代码进行运转lifecycleItem.execute(mTransactionHandler, token, mPendingActions)。lifecycleItem在executeLifecycleState 中咱们知道lifecycleItem的值是ResumeActivityItem，此刻代码就会运转到ResumeActivityItem#execute(),也便是第29步。最终会调用ActivityThread的handleResumeActivity(),从而履行Activity的onResume生命周期。

1.4.3 小结

在本阶段，首要是在Application进程经过跨进程接纳从AMS封装好的ClientTransaction方针，ClientTransaction方针里边封装了需求App进程履行Activity生命周期的一切的事情，然后在activity地点的进程中，依照触发器的触发逻辑，顺序的履行activity的创立->attach->onCreate->onStart->onResume生命周期。

在AMS进程中的会经过ActivityStackSupervisor将activity发动相关的事情封装成为一个ClientTransaction方针，然后由ClientLifecycleManager经过ClientTransaction的函数将ClientTransaction方针以跨进程通信的办法传递给ApplicationThread。在完结了跨进程后，这个触发器所带着的指令就会在Application进程中得到触发。Application地点的进程会经过Handler来发动触发器TransactionExecutor的履行。TransactionExecutor会依照AMS中设置的逻辑，逐步去分发Activity的生命周期，直到整个触发器所带着的生命周期情况被履行完结停止，也便是onResume情况得到履行停止。

1.5 发动Activity的Activity onPause生命周期的运转

在Activity A 发动Activity B的时分，当Activity B发动流程履行到onResume生命周期之后，这个时分Activity A才会去履行它的onPause生命周期，这个逻辑是怎样的呢？咱们看下面的代码。

ActivityThread.java
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
    String reason) {
   ......
  // 回调 onResume
  final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
   ......
  final Activity a = r.activity;
   ......
  if (r.window == null && !a.mFinished && willBeVisible) {
     ......
    if (a.mVisibleFromClient) {
      if (!a.mWindowAdded) {
        a.mWindowAdded = true;
                // 增加 decorView 到 WindowManager
        wm.addView(decor, l);
       } else {
        a.onWindowAttributesChanged(l);
       }
     }
   } else if (!willBeVisible) {
     ......
   }
   ......

  // 主线程闲暇时会履行 Idler
  Looper.myQueue().addIdleHandler(new Idler());
}

在代码最终有一句代码：Looper.myQueue().addIdleHandler(new Idler())。IdleHandler 不知道咱们是否了解，它供给了一种机制，当主线程音讯行列闲暇时，会履行 IdleHandler 的回调办法，假如不懂这个逻辑的能够找一下其他handler章节的内容进行学习。messageQueue 中在正常的音讯处理机制之后，额外对 IdleHandler 进行了处理。当从Messagequeue中调用next函数去取Message时，在本次取到的 Message 为空或许需求延时处理的时分，就会去履行 mIdleHandlers 数组中的 IdleHandler 方针。所以，不出意外的话(主线程很忙)，当新的 Activity 完结页面绘制并显现之后，主线程就能够停下歇一歇，来履行 IdleHandler 了。再回来 handleResumeActivity() 中来，Looper.myQueue().addIdleHandler(new Idler()) ，这儿的 Idler 是 IdleHandler 的一个具体实现类。

private class Idler implements MessageQueue.IdleHandler {
    @Override
    public final boolean queueIdle() {
        ActivityClientRecord a = mNewActivities;
        boolean stopProfiling = false;
        if (mBoundApplication != null && mProfiler.profileFd != null
                && mProfiler.autoStopProfiler) {
            stopProfiling = true;
        }
        if (a != null) {
            mNewActivities = null;
            IActivityTaskManager am = ActivityTaskManager.getService();
            ActivityClientRecord prev;
            do {
                if (localLOGV) Slog.v(
                    TAG, "Reporting idle of " + a +
                    " finished=" +
                    (a.activity != null && a.activity.mFinished));
                if (a.activity != null && !a.activity.mFinished) {
                    try {
                        // code1 调用 AMS.activityIdle()
                        am.activityIdle(a.token, a.createdConfig, stopProfiling);
                        a.createdConfig = null;
                    } catch (RemoteException ex) {
                        throw ex.rethrowFromSystemServer();
                    }
                }
                prev = a;
                a = a.nextIdle;
                prev.nextIdle = null;
            } while (a != null);
        }
        if (stopProfiling) {
            mProfiler.stopProfiling();
        }
        applyPendingProcessState();
        return false;
    }
}

上面的代码在code1处调用AMS 的activityIdle()，这个时分就顺利的将代码的履行转移到了AMS地点的进程中。

图 29-5

经过上图咱们不难发现：上面的流程证明，咱们activity的stop和destroy生命周期在此处履行。也便是说此刻会履行发动activity之前的上一个activity的onStop生命周期，或许onDestroy生命周期。当然，假如咱们具体的剖析ActivityStackSupervisor(ASS)的代码，咱们会不难发现一个细节，等待毁掉的Activity被保存在了 ASS 的 mStoppingActivities 集合中，它是一个 ArrayList。

1.5.1 小结

Activity 的 onStop/onDestroy 是依靠 IdleHandler 来回调的，正常情况下当主线程闲暇时会调用。但是因为某些特殊场景下的问题，导致主线程迟迟无法闲暇，onStop/onDestroy 也会迟迟得不到调用。但这并不意味着 Activity 永远得不到回收，体系供给了一个兜底机制，当 onResume 回调 10s 之后，假如依然没有得到调用，会自动触发。

1.6 总结

Activity的发动交由ATMS触发处理，在Activity发动前需求先在ActivityStarter类中解读包含Activity的发动形式在内的各种参数信息。确定好发动信息后经过创立一个黑白屏的办法反馈给用户一个信息：咱们正在呼应发动app的进程中。然后将发动流程转交给ActivityStack处理，因为在ActivityStack中存储了一个Application的一切Activity，因而在此刻运用的各Activity应该怎么呼应需求由ActivityStack来共同安排，在这个进程中就必定涉及到Activity的pause和需求发动的Activity的“realstart”。为了更好的办理Activity发动进程中的各生命周期，在ActivityStackSupervisor里边会将生命周期的事情封装成为一个ClientTransaction，并将这个ClientTransaction的方针经过跨进程的办法发送给App进程，然后由app进程的TransactionExecutor共同去触发履行，直到完结Activity的onResume生命周期停止，总流程如下图所示。

今日共享到此结束，对你有帮助的话，点个赞再走呗，下期更精彩~

重视公众号：Android老皮
解锁 《Android十大板块文档》 ，让学习更靠近未来实战。已形成PDF版

内容如下：

1.Android车载运用开发体系学习指南（附项目实战）
2.Android Framework学习指南，助力成为体系级开发高手
3.2023最新Android中高档面试题汇总+解析，告别零offer
4.企业级Android音视频开发学习道路+项目实战（附源码）
5.Android Jetpack从入门到精通，构建高质量UI界面
6.Flutter技能解析与实战，跨渠道首要之选
7.Kotlin从入门到实战，全方面提高架构基础
8.高档Android插件化与组件化（含实战教程和源码）
9.Android 功能优化实战+360全方面功能调优
10.Android零基础入门到精通，高手进阶之路

敲代码不易，重视一下吧。ღ( ･ᴗ･` )

每日一题：Activity启动流程分析

问题正解：

1.Activity发动流程

1.1 Launcher 调用Activity的进程

1.1.1 ActivityStarter类的阐明

1.1.2 ActivityStartController类

1.1.3 发动期间的黑白屏现象

1.1.4 RootWindowContainer类的阐明

1.1.5 小结

接下来，咱们继续剖析Activity的发动流程

1.2 Activity发动流程在AMS中的履行

1.2.1 ActivityRecord，Task，ActivityStack，ActivityStackSupervisor类阐明

1.3 Activity发动中事情的跨进程通信

小结

1.4 运用进程中生命周期的履行流程

1.4.1 履行executeCallbacks函数

1.4.2 履行executeLifecycleState函数

1.4.3 小结

1.5 发动Activity的Activity onPause生命周期的运转

1.5.1 小结

1.6 总结

作者信息

推广

每日一题：Activity启动流程分析

问题正解：

1.Activity发动流程

1.1 Launcher 调用Activity的进程

1.1.1 ActivityStarter类的阐明

1.1.2 ActivityStartController类

1.1.3 发动期间的黑白屏现象

1.1.4 RootWindowContainer类的阐明

1.1.5 小结

接下来，咱们继续剖析Activity的发动流程

1.2 Activity发动流程在AMS中的履行

1.2.1 ActivityRecord，Task，ActivityStack，ActivityStackSupervisor类阐明

1.3 Activity发动中事情的跨进程通信

小结

1.4 运用进程中生命周期的履行流程

1.4.1 履行executeCallbacks函数

1.4.2 履行executeLifecycleState函数

1.4.3 小结

1.5 发动Activity的Activity onPause生命周期的运转

1.5.1 小结

1.6 总结

相关文章

驳《阿里「Java开发手册」中的1个bug》？

CSS 思考 ☞『CSS in JS』 or 『JS in CSS』 ?

腾讯性能监控框架Matrix源码分析（二）初始化和架构设计

大数据培训十大Hive调优技巧

作者信息

推广