面试官:Activity的启动流程?还在AMS?那你就out了!api29源码解析

Warning!本文基于API 29,基于 API 30 的Activity启动流程分析已更新,点击:Activity启动流程?基于Api30的Activity启动流程分析 https://www.jianshu.com/p/b68914037364

Activity的启动流程api26

直接放图。

第一次做这个图的时候,我是按照api26的源码来的,然而现在已经api29了……

Activity的启动过程的源码我看了多个版本的,每个版本都有一些变化,有些地方属实搞得人摸不着头脑。尤其是中间这几个类,一直在改动。比如这个ActivityStarter,如果我没记错的话是api23还是26才加进来的;后来又把ActivityStackSupervisor的一部分功能分离到了不同的类中。看看源码中的注释:

ActivityStackSupervisor

好吧,这个类即将被移除了……

个人感觉可能是Android团队前期埋的坑太多,留下了一些超巨型的类,很多类都超过了几千上万行;然后随着版本的更替,发现这么多功能都放一个类里面也不成,又在慢慢分离一些职责到其他类中,所以就造成了一个版本一个样,变化很快。代码流程随着版本优化,这也是必然的趋势。

不过呢,总体来讲,大体的流程框架基本是固定的,太细节的地方也不需要过多纠结了。

言归正传,从顶至下,我个人把Activity的启动流程依次分为三个阶段
App进程中 ——(通过Binder)—→ 系统进程中 ——(通过Binder)—→ 回到App进程中

下面依次进行梳理。(只保留关键代码)

1. App进程中

App进程第一轮做的事儿不多,主要就是把传进来的Intent扔给AMS。

1.1 Activity

在Activity中调用了startActivity方法后,不管调用的是哪个重载,最后都会进入到startActivityForResult(Intent, int, Bundle)中。

    public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
            @Nullable Bundle options) {
    ……
            mInstrumentation.execStartActivity(
                this, mMainThread.getApplicationThread(), mToken, this,
                intent, requestCode, options);
    ……
    }

然后就进入到了Instrumentation.execStartActivity方法中。

1.2 Instrumentation

    public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
    ……
            ActivityTaskManager.getService().startActivity(
                        whoThread, who.getBasePackageName(), intent,
                        intent.resolveTypeIfNeeded(who.getContentResolver()),
                        token, target != null ? target.mEmbeddedID : null,
                        requestCode, 0, null, options);
    ……
    }

注意!重点!
在之前的版本中,Instrumentation都是通过Binder的方式调用AMS的方法启动Activity的;但是在api29中,IPC的对象变成了ActivityTaskManagerService(ATMS)。根据这个类的说明,“此类提供有关Activity及其容器(如task,stack和display)的信息,并与之交互。”网上关于这个类的信息不多,但是通过源码可以发现,这个类实际上就是AMS分离出的一部分职责(毕竟AMS两万多行,也该瘦瘦身了)。
Instrumentation.execStartActivity通过ActivityTaskManager.getService()获得了一个IActivityTaskManager类型的对象,这是一个Binder对象,负责应用和ATMS之间的通信。也就是在这里,流程进入到了第二阶段:系统进程中。

2. 系统进程中

2.1 ATMS(ActivityTaskManagerService)

ATMS运行在系统服务进程(system_server)之中。当App通过Instrumentation和ATMS跨进程通信之后,ATMS就代管了接下来的启动流程。
ATMS在进行了简单处理之后,就会交给ActivityStarter处理。(这其实跟之前的AMS一模一样)

    public final int startActivity(...args) {
        return startActivityAsUser(...args);
    }

    public final int startActivityAsUser(args) {
        // ...
        return getActivityStartController().obtainStarter(intent, "startActivityAsUser")
                .......
                .execute();
    }

上述代码中,getActivityStartController().obtainStarter会返回一个ActivityStarter对象。(这个ActivityStartController中有一个ActivityStarter.DefaultFactory类型的成员变量,它维护了一个ActivityStarter池。obtainStarter()就是从里面取的。
然后ActivityStarter.execute()会根据传入的字符串"startActivityAsUser"来进行接下来的流程。

2.2 一些重要的类

接下来的工作,就是一系列的类协同处理了。代码非常复杂,但是看个大概流程还是不难的,毕竟Android源代码近亿行,不可能全部都仔细读完。

这部分主要涉及了几个类:ActivityStarterActivityStackSupervisorActivityRecordTaskRecordActivityStack

ActivityStarter
顾名思义,ActivityStarter是用来启动Activity的,同时也在其中判断了启动模式的逻辑;

ActivityStackSupervisor
顾名思义,ActivityStackSupervisor则是ActivityStack的管理者。

ActivityRecord
而每次启动一个Activity,都有一个对应的ActivityRecord被记录下来。这个ActivityRecord是在ActivityStarter.startActivity(IApplicationThread, ...)方法中被创建的,也就是在这里,Activity的启动信息完成了从intent到ActivityRecord的蜕变。ActivityRecord包含了一个Activity的所有信息,可以看做是Activity的“身份证”。

TaskRecord
任务。一个TaskRecord就是在四种启动模式中所说的“栈”。一个TaskRecord,或者说一个Task、任务,根据官方说法,任务是用户在执行某项工作时与之互动的一系列 Activity 的集合。也就是说,一个任务是包含了若干个Activity的。对于启动模式为singleInstance的Activity来说,会单独存在于一个栈中,也就是这个任务中只有一个Activity;而其他启动模式的Activity则会在当前栈中进行。具体的参考官网定义启动模式

ActivityStack
ActivityStack顾名思义,也就是Activity栈。通常来讲,一个系统里面有两个ActivityStack,一个是系统Launcher所在的ActivityStack,一个是用户App运行的ActivityStack。通常App所在的栈就是后者。
一个ActivityStack包含了多个TaskRecord,如图所示:图片来源

偷图

2.3 ActivityStarter

顾名思义,ActivityStarter肩负着Activity启动的职责。之前说到,ATMS调用了ActivityStarter.execute()方法,execute()又会调用startActivityMayWait()方法。

startActivityMayWait
为什么这个方法名字里有个“MayWait”呢?因为接下来的流程都是在同步代码块里面进行的,保证了Activity的启动在多线程下的安全性。这个方法会做一系列的验证和处理,比如根据Intent来从PackageManagerService收集待启动Activity的信息(AndroidManifest中的信息)。

startActivity
startActivityMayWait最终会调用startActivitystartActivity共有三个重载,关键是在这个流程里面,这三个重载挨个都被调用了……不得不吐槽,Android这个方法名字取得真的毫无特色,不仔细看根本不知道他是干啥的;这三步我就合到一起写了。过程很冗长,大多是做一些条件的判断,以及继续收集目标Activity的信息。最重要的是,在这个过程中,根据收集到的这些信息,目标Activity对应的ActivityRecord终于被创建了

startActivityUnchecked
经过三个startActivity方法之后,终于到了重头戏了。在startActivityUnchecked方法中,包含了关于启动模式launchMode的逻辑。根据任务栈中是否已经存在该Activity实例、AndroidManifest中设置的启动模式和传入Intent中的flags等,判断出目标Activity的启动方式(《定义启动模式》有详尽的关于启动模式的说明)。
在判断完Activity的启动方式之后,startActivityUnchecked方法中有这么一句代码:

mTargetStack.startActivityLocked(mStartActivity, topFocused, newTask, mKeepCurTransition, mOptions);

看到这个方法名,我以为流程就走这继续了呢;结果点进去看了半天才发现,这个方法处理的是把目标Activity压入相应的任务栈(或者新建任务栈或者pop上方Activity,诸如此类)相关的逻辑,另外就是创建Starting Window相关的逻辑;这算是个支线任务。真正启动Activity的流程还得往下看。
后面的逻辑就很清晰了,删去旁支之后:

if (mDoResume) {
    // ...
    mRootActivityContainer.resumeFocusedStacksTopActivities(mTargetStack, mStartActivity, mOptions);
} 

不过这个mDoResume又是哪儿来的?经过我的不懈努力,终于在某个startActivity方法中发现了,其实他就是true:

final int res = startActivity(r, sourceRecord, voiceSession, voiceInteractor, startFlags,
                true /* doResume */, checkedOptions, inTask, outActivity, restrictedBgActivity);

OK,到这就很明了了。所以说,到这又跟之前版本不同了,没有经过ActivityStackSupervisor,而是调用了RootActivityContainer.resumeFocusedStacksTopActivities

2.4 RootActivityContainer / ActivityStack / ActivityStackSupervisor

这个RootActivityContainer又是何方神圣呢?看看它的注释:

Root node for activity containers. TODO: This class is mostly temporary to separate things out of ActivityStackSupervisor.java. The intention is to have this merged with RootWindowContainer.java as part of unifying the hierarchy.

意思就是,这是个临时类,分离了一部分ActivityStackSupervisor的职责,到最后这个类会被合并到RootWindowContainer类中;之前这一步的确应该是交给ActivityStackSupervisor的。根据源码中的注释所言,之后ActivityStackSupervisor类会被彻底消灭掉,类的职责会被其他类分割。
总而言之,这个类暂时就是ActivityStackSupervisor一部分的替代品,之后这部分工作就应该是RootWindowContainer来做了。

RootActivityContainer.resumeFocusedStacksTopActivities()及之后的一系列方法

回到RootActivityContainer.resumeFocusedStacksTopActivities方法中;这开始之后的调用链依次是:
RootActivityContainer.resumeFocusedStacksTopActivities
-> ActivityStack.resumeTopActivityUncheckedLocked
-> ActivityStack.resumeTopActivityInnerLocked

它们的共同作用就是确保刚才压入栈的目标Activity能够顺利resume,包括各种状态的判断、暂停当前Activity、处理过渡动画等。而在ActivityStack.resumeTopActivityInnerLocked方法的最后:

if (next.attachedToProcess()) {
    // ...
} else {
    mStackSupervisor.startSpecificActivityLocked(next, true, true);
}

这个attachedToProcess方法的返回值也折腾了我很久;最后终于发现,只有启动了的Activity才会返回true。所以代码最终进入到了ActivityStackSupervisor.startSpecificActivityLocked方法中。此时第二阶段的流程已经接近尾声。

ActivityStackSupervisor.startSpecificActivityLocked()中又调用了
ActivityStackSupervisor.realStartActivityLocked()
终于,看到这个名字就知道,这是真正的启动Activity了!

ActivityStackSupervisor.realStartActivityLocked(ActivityRecord, WindowProcessController, boolean, boolean)
这个方法有200多行,但是最关键的其实就是下面这一段:

    final ClientTransaction clientTransaction = ClientTransaction.obtain(
            proc.getThread(), r.appToken);
    clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
            System.identityHashCode(r), r.info,
            mergedConfiguration.getGlobalConfiguration(),
            mergedConfiguration.getOverrideConfiguration(), r.compat,
            r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
            r.icicle, r.persistentState, results, newIntents,
            dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
                    r.assistToken));
    mService.getLifecycleManager().scheduleTransaction(clientTransaction);

这里的mService是ATMS,它通过LifecycleManager传递了一个Activity启动的事务;scheduleTransaction是这样的:

    void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
        final IApplicationThread client = transaction.getClient();
        transaction.schedule();
        // ...
    }

拨云见日!熟悉的IApplicationThread,终于结束了在系统进程中的流程,又要回到App进程了。

3. 重回App进程

继续偷图,原文https://www.jianshu.com/p/42cc38ba6112

https://upload-images.jianshu.io/upload_images/6635796-9f90882946ad4590.png

参考资料
https://www.jianshu.com/p/42cc38ba6112
https://www.jianshu.com/p/94816e52cd77
https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342