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

本文详细探讨了Android 7.0中ActivityManagerService启动Activity的代码流程,从Task和Activity的基础知识、启动模式、Intent Flags到am命令的使用。文章通过分析ams命令启动Activity的步骤,展示了Activity如何选择对应的Task,以及涉及的启动模式、Intent Flags的判断。此外,还介绍了startActivityLocked和startActivityUnchecked等核心函数的执行逻辑,包括复用Activity的情况和创建新进程的过程。最后,总结了启动Activity的流程图,为理解Android系统内部机制提供帮助。
摘要由CSDN通过智能技术生成

从这一篇博客开始,我们将阅读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
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值