Android 7.0 ActivityManagerService(2) 启动Activity的过程：一

从这一篇博客开始，我们将阅读AMS启动一个Activity的代码流程。
自己对Activity的启动过程也不是很了解，这里就初步做一个代码阅读笔记，为以后的迭代打下一个基础。

一、基础知识
在分析Activity的启动过程前，有必要先了解一下Activity相关的基础知识。

1、Task和Activity的设计理念
关于Android中Task和Activity的介绍，个人觉得《深入理解Android》中的例子不错。
我们就借鉴其中的例子，进行相应的说明：

上图列出了用户在Android系统上想干的三件事，分别用A、B、C表示。
在Android中，每一件事可以被看作是一个Task；一个Task可以被细分成多个子步骤，每个子步骤可以被看作是一个Activity。
从上图可以看出，A、B两个Task使用了不同的Activity来完成相应的任务，即A、B两个Task的Activity之间没有复用。
但是在Task C中，分别使用了Task A中的A1、Task B中的B2。

这么设计的原因是：用户想做的事情（Task）即使完全不同，但是当细分Task为Activity时，就可能出现Activity功能类似的情况。
当Task A和Task B中已经有能满足需求的Activity时，Task C就会优先复用而不是重新创建Activity。
通过重用Activity可以节省一定的开销，同时为用户提供一致的界面和用户体验。

对Android的设计理念有一定的了解后，我们看看Android是如何组织Task及它所包含的Activity。

上图为一个比较经典的示例：图中的Task包含4个Activity。用户可以单击按钮跳转到下一个Activity。同时，通过返回键可以回到上一个Activity。
图中虚线下方为Activity的组织方式。从图中可以看出，Android是以Stack的方式来管理Activity的。
先启动的Activity成为栈底成员，被启动的Activity将作为栈顶成员显示在界面上。
当按返回键时，栈顶成员出栈，前一个Activity成为栈顶显示在界面上。

以上是一个Task的情况。当有多个Task时，Android系统只支持一个处于前台的Task，其余的Task均处于后台。
这些后台Task内部Activity保持顺序不变。用户可以一次将整个Task挪到后台或置为前台，如下图所示：

在AMS中，将用ActivityRecord来作为Activity的记录者、TaskRecord作为Task的记录者，TaskRecord中有对应的ActivityStack专门管理ActivityRecord。

2、启动模式
Android定义了4种Activity的启动模式，分别为Standard、SingleTop、SingleTask和SingleInstance。

Standard模式
我们平时直接创建的Activity都是这种模式。
这种模式的Activity的特点是：只要你创建并启动了Activity实例，Android就会向当前的任务栈中加入新创建的实例。退出该Activity时，Android就会在任务栈中销毁该实例。
因此，一个Task中可以有多个相同类型的Activity（类型相同，但不是同一个对象）。

Standard模式启动Activity的栈结构如下图所示：

SingleTop模式
这种模式会考虑当前要激活的Activity实例在任务栈中是否正处于栈顶。
如果处于栈顶则无需重新创建新的实例，将重用已存在的实例，
否则会在任务栈中创建新的实例。

SingleTop模式启动Activity的栈结构如下图所示：

注意：当用SingleTop模式启动位于栈顶的Activity时，并不会创建新的Activity，但栈顶Activity的onNewIntent函数将被调用。

SingleTask模式
在该种模式下，只要Activity在一个栈中存在，那么多次启动此Activity都不会重新创建实例。和SingleTop一样，系统也会回调其onNewIntent。

具体一点，当一个具有singleTask模式的Activity A请求启动后，系统先会寻找是否存在A想要的任务栈。
如果不存在对应任务栈，就重新创建一个任务栈，然后创建A的实例后，把A放到任务栈中。
如果存在A所需的任务栈，那么系统将判断该任务栈中是否有实例A。
如果有实例A，那么系统就将A调到栈顶并调用其onNewIntent方法（会清空A之上的Activity）。
如果没有实例A，那么系统就创建实例A并压入栈中。

SingleTask模式启动Activity的栈结构如下图所示：

SingleInstance模式
SingleInstance模式是一种加强版的SingleTask模式，它除了具有SingleTask所有的特性外，还加强了一点，那就是具有此模式的Activity只能单独地位于一个任务栈中。

3、Intent Flags
启动模式主要是配置在xml文件中的，例如：

<activity android:name=".TestActivity"
    android:launchMode="singleTask"
>

除了启动模式外，Android在用Intent拉起Activity时，还可以使用Intent Flags控制Activity及Task之间的关系。
Intent Flags数量非常多，这里只列举其中的一部分：

Intent.FLAG_ACTIVITY_NEW_TASK
默认的跳转类型，将目标Activity放到一个新的Task中。

Intent.FLAG_ACTIVITY_CLEAR_TASK
当用这个FLAG启动一个Activity时，系统会先把与该Activity有关联的Task释放掉，然后启动一个新的Task，并把目标Activity放到新的Task。
该标志必须和Intent.FLAG_ACTIVITY_NEW_TASK一起使用。

FLAG_ACTIVITY_SINGLE_TOP
这个FLAG就相当于启动模式中的singleTop。
例如:原来栈中结构是A B C D。现在，在D中启动D，那么栈中的结构还是A B C D。

FLAG_ACTIVITY_CLEAR_TOP
这个FLAG类似于启动模式中的SingleTask。
这种FLAG启动的Activity会其之上的Activity全部弹出栈空间。
例如：原来栈中的结构是A B C D ，从D中跳转到B，栈中的结构就变为了A B了。

FLAG_ACTIVITY_NO_HISTORY
用这个FLAG启动的Activity，一旦退出，就不会存在于栈中。
例如：原来栈中的结构是A B C，现在用这个FLAG启动D。然后在D中启动E，栈中的结构为A B C E。

对这些基础知识有了一定的了解后，我们来看看AMS启动Activity的代码级流程。

在这一篇博客中，我们对代码流程的分析，将截止于启动Activity对应的进程。
于是，这部分流程中大部分的内容，将围绕Activity如何选择对应的Task来展开，
由于Task的选择还要涉及对启动模式、Intent Flags等的判断，
因此整个代码将极其的琐碎，需要很有耐心才能较仔细地看完。

二、am命令
我们将看看利用am命令如何启动一个Activity。

之所以选择从am命令入手，是因为当我们从一个Activity拉起另一个Activity时，
当前Activity对应的进程需要和AMS进行交互，
这就要求我们需要对进程中与AMS交互的对象比较了解时，才比较容易分析。

而从am入手分析，当被启动Activity被创建后，代码流程自然就会涉及到这个进程与AMS的交互，
整个逻辑的顺序很容易理解。

当我们利用adb shell进入到手机的控制台后，可以利用am命令启动Activity、Service等。
具体的格式类似于：

am start -W -n 包名(package)/包名.activity名称

例如，启动浏览器的命令是：

am start -W -n com.android.browser/com.android.browser.BrowserActivity

上面命令中的-W是一个可选项，表示等待目标activity启动后，am才返回结果；
-n ，表示后接COMPONENT。
am命令可接的参数有很多种，有兴趣可以研究一下，此处不再一一列举。

如同之前介绍pm安装apk的流程中提及的，pm命令是一个执行脚本。
am与pm一样，同样是定义于手机中的执行脚本。
am脚本的文件路径是frameworks/base/cms/am，其内容如下：

#!/system/bin/sh
#
# Script to start "am" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/am.jar
exec app_process $base/bin com.android.commands.am.Am "$@"

与调用pm命令类似，调用am命令同样最终会调用到Am.java(frameworks/base/cmds/am/src/com/android/commands/am)的main函数。
这里的调用过程可以参考Android7.0 PackageManagerService (3) APK安装的第二部分。

现在我们直接看看Am.java的main函数:

/**
* Command-line entry point.
*
* @param args The command-line arguments
*/
public static void main(String[] args) {
    //创建一个Am对象，然后执行run函数
    (new Am()).run(args);
}

Am继承自BaseCommand，上面的run函数定义于BaseCommand中：

/**
* Call to run the command.
*/
public void run(String[] args) {
    ..........
    //将字符串封装到对象中，mArgs的类型为ShellCommand
    mArgs.init(null, null, null, null, args, 0);
    ..........
    try {
        //子类实现
        onRun();
    } catch (IllegalArgumentException e) {
        ......
    } catch (Exception e) {
        ......
    }
}

现在进入到Am.java的onRun函数：

public void onRun() throws Exception {
    mAm = ActivityManagerNative.getDefault();
    ..............
    mPm = IPackageManager.Stub.asInterface(ServiceManager.getService("package"));
    ...............
    //从父类的mArgs中中取出第一个参数
    String op = nextArgRequired();

    if (op.equals("start")) {
        runStart();
    } else if (op.equals("startservice")) {
        runStartService();
    } .........
    ...........
}

从代码可以看出，am命令的功能很多，此处我们主要看看start相关的runStart函数：

private void runStart() throws Exception {
    //makeIntent会解析参数，得到对应的Intent
    //主要是结合Intent的parseCommandArgs函数和Am内部定义的CommandOptionHandler解析字符串
    //比较简单，不做深入分析
    Intent intent = makeIntent(UserHandle.USER_CURRENT);
    ..........
    //获取mimeType
    String mimeType = intent.getType();
    if (mimeType == null && intent.getData() != null
            && "content".equals(intent.getData().getScheme())) {
        //如果是"content"类型的数据，那么利用AMS获取对应的mimeType
        mimeType = mAm.getProviderMimeType(intent.getData(), mUserId);
    }
    ..........
    do {
        if (mStopOption) {
            //处理-S选项，即先停止对应的Activity，再启动它
            //这些变量，均是makeIntent函数解析参数得到的
            ...............
        }
        ............
        //通过am命令启动的Activity，附加了标志FLAG_ACTIVITY_NEW_TASK
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        ............
        if (mProfileFile != null) {
            //处理-P选项，用于性能统计
            .............
        }
        .............
        //通过添加参数--stack，可以指定Activity加入到特定的Task中
        //此处就是将对应的Stack Id将被写入到options中
        //与脚本命令中的 -W 一样，--stack是一个可选项
        ActivityOptions options = null;
        if (mStackId != INVALID_STACK_ID) {
            options = ActivityOptions.makeBasic();
            options.setLaunchStackId(mStackId);
        }

        if (mWaitOption) {
            //如果有-W选项，进入该分支
            result = mAm.startActivityAndWait(null, null, intent, mimeType,
                    null, null, 0, mStartFlags, profilerInfo,
                    options != null ? options.toBundle() : null, mUserId);
            res = result.result;
        } else {
            //不等待activity启动，直接返回
            res = mAm.startActivityAsUser(null, null, intent, mimeType,
                    null, null, 0, mStartFlags, profilerInfo,
                    options != null ? options.toBundle() : null, mUserId);
        }
        //判断am命令是否执行成功，成功时会break
        ..........
        mRepeat--;
        .........
    }while (mRepeat > 1);
}

从上面的代码可以看出，am最终将调用AMS的startActivityAndWait或startActivityAsUser函数，来启动参数指定的Activity。
我们以startActivityAndWait为例进行分析。

三、startActivityAndWait流程
startActivityAndWait的参数比较多，先来大致看一下参数的含义：

public final WaitResult startActivityAndWait(
//在多数情况下，一个Activity的启动是由一个应用进程发起的
//IApplicationThread是应用进程和AMS交互的通道
//通过am启动Activity时，该参数为null
IApplicationThread caller, 

//应用进程对应的pacakge
String callingPackage,

//启动使用的Intent和resolvedType
Intent intent, String resolvedType, 

//均是给Activity.java中定义的startActivityForResult使用的
//resultTo用于接收返回的结果，resultWho用于描述接收结果的对象
//requestCode由调用者定义
IBinder resultTo, String resultWho, int requestCode,

//Intent携带的start activity对应的flag
int startFlags,

//性能统计有关
ProfilerInfo profilerInfo, 

//用于指定Activity的一些选项
//从前面调用的代码来看，应该是指定Activity需要加入的Task
Bundle bOptions,

//表示调用的用户ID
int userId) {
    ..................
}

现在我们看看startActivityAndWait函数的具体内容：

public final WaitResult startActivityAndWait(....) {
    //进行权限检查相关的工作
    .............

    //用于存储处理结果
    WaitResult res = new WaitResult();

    //进入ActivityStarter中的流程
    mActivityStarter.startActivityMayWait(caller, -1, callingPackage, intent, resolvedType,
            null, null, resultTo, resultWho, requestCode, startFlags, profilerInfo, res, null,
            bOptions, false, userId, null, null);

    return res;
}

上面代码中的ActivityStarter初始化于AMS的构造函数中，专门负载启动Activity相关的工作。
当我们通过am命令启动一个Activity时，假设系统之前没有启动过该Activity，那么从功能的角度来看，ActivityStarter调用artActivityMayWait函数后，系统将完成以下工作：
1、上文提及在Am.java中，为Intent增加了标志位FLAG_ACTIVITY_NEW_TASK，因此系统将为Activity创建ActivityRecord和对应的TaskRecord。
2、系统需要启动一个新的应用进程以加载并运行该Activity。
3、还需要停止当前正在显示的Activity。

接下来，我们跟进一下ActivityStarter的startActivityMayWait函数。
我们可以将该函数分为三部分进行分析：

1 第一部分

final int startActivityMayWait(............) {
    ...............
    //判断是否指定了组件名
    boolean componentSpecified = intent.getComponent() != null;
    ...............

    //利用PKMS解析满足Intent等参数要求的信息
    ResolveInfo rInfo = mSupervisor.resolveIntent(intent, resolvedType, userId);
    ...............

    // Collect information about the target of the Intent.
    // mSupervisor的类型为ActivityStackSupervisor， 负责管理Activity和对应Task之间的关系
    // 此处，ActivityStackSupervisor实际仅从ResolveInfo中取出对应的ActivityInfo
    ActivityInfo aInfo = mSupervisor.resolveActivity(intent, rInfo, startFlags, profilerInfo);

    //得到options，其中可能指定了Activity需要加入的Task
    ActivityOptions options = ActivityOptions.fromBundle(bOptions);

    ActivityStackSupervisor.ActivityContainer container =
            (ActivityStackSupervisor.ActivityContainer)iContainer;
    synchronized (mService) {
        //从am启动时，container为null
        if (container != null && container.mParentActivity != null &&
                container.mParentActivity.state != RESUMED) {
            // Cannot start a child activity if the parent is not resumed.

            //如果从一个Activity启动另一个Activity，从此处代码可以看出，
            //要求父Activity已经执行过onResume
            return ActivityManager.START_CANCELED;
        }

        final int realCallingPid = Binder.getCallingPid();
        final int realCallingUid = Binder.getCallingUid();
        ....................

        //以下代码是决定启动Activity时的Task
        final ActivityStack stack;
        if (container == null || container.mStack.isOnHomeDisplay()) {
            //am启动，或Home来启动Activity
            //stack为前台栈
            stack = mSupervisor.mFocusedStack;
        } else {
            //当从一个Activity启动另一个Activity时，
            //启动栈为父Activity的Task
            stack = container.mStack;
        }

        //am启动时config == null
        stack.mConfigWillChange = config != null && mService.mConfiguration.diff(config) != 0;
        .................

        //正常情况下，当一个Application退到后台时，系统会为它保存状态；当调度其到前台时，恢复它之前的状态，以保证用户体验的连续性
        //AndroidManifest.xml中的Application标签可以申明一个CANT_SAVE_STATE属性
        //设置了该属性的Application将不享受系统提供的状态保存/恢复功能，被称为heavy-weight process
        if (aInfo != null &&
                (aInfo.applicationInfo.privateFlags
                        & ApplicationInfo.PRIVATE_FLAG_CANT_SAVE_STATE) != 0) {
            ............................
        }
        ...................
    }
}

从上面的代码来看，startActivityMayWait在第一阶段最主要的工作其实就是：
1、解析出与Intent相匹配的ActivityInfo。
2、得到启动该Activity的Task，即父Activity的Task或前台Task。

2 第二部分

..................
//用于保存启动Activity后，对应的ActivityRecord
final ActivityRecord[] outRecord = new ActivityRecord[1];

//调用startActivityLocked函数，进行实际的启动工作
int res = startActivityLocked(...............);
..................

这一部分中，涉及到了启动Activity的核心函数startActivityLocked。该函数比较复杂，我们在后面单独分析。
当该函数成功执行完毕后，Activity将会被启动，并形成对应的ActivityRecord被AMS统一管理。

我们先看看startActivityMayWait函数第三部分的工作。

3 第三部分

...................
//outResult不等于null，表示等待启动结果
//目标Activity要运行在一个新的应用进程中，因此需要等待应用进程正常启动并处理相关请求
if (outResult != null) {
    outResult.result = res;
    if (res == ActivityManager.START_SUCCESS) {
        mSupervisor.mWaitingActivi