Android O Framework架构分析:以AMS视角看Activity启动过程

        在Android系统中,Activity的启动是一个非常频繁发生的过程,在Framework层中,这个过程牵涉到的模块也非常多。本文将基于Android 8.0源码,以ActivityManagerService模块(以下简称AMS)的视角来分析其过程中主要发生的行为。

一. AMS中层次结构

        AMS模块中涉及Activity的数据结构主要有三个:ActivityRecord,TaskRecord,ActivityStack. 其中ActivityRecord抽象地表示了每一个Activity,这个数据结构记录、管理了Activity的各种信息、属性、状态等。TaskRecord抽象地表示了任务的概念,任务是由一系列Activity以栈的形式组成的,一般情况下启动Activity都会在同一个任务中启动,添加了特殊的flag(FLAG_ACTIVITY_NEW_TASK)或者特殊的启动模式则会在新任务中启动一个Activity. 任务和进程并无限制关系,同一任务中也可存在其它进程的Activity,同一进程的Activity也可以存在与不同任务中。具象来看的话,系统中的最近任务界面显示的任务就和AMS里的TaskRecord描述的是一样的概念。ActivityStack则是用来管理TaskRecord的结构,是由一系列TaskRecord以栈的形式组成的。它是一个抽象的概念,在系统中无法具象地看到它。从6.0开始只有两个ActivityStack(桌面所在的TaskRecord在单独的ActivityStack中,其他TaskRecord在另一个),到8.0中已经有八个(为分屏,最近任务,画中画,自由模式等创建的),ActivityStack随着Android大版本升级越来越多。

二. Activity启动的主要流程

        Activity启动时,客户端通过Binder向system server端进行通讯,通知AMS进行相应地处理,其时序图为(红色代表app进程,蓝色代表system server进程):

Android O Framework架构分析:以AMS视角看Activity启动过程_第1张图片

        上面的时序图其实仅仅描述了在Activity启动时,AMS端的一些通用逻辑,绝大多数的情况下,在Activity启动时首先都会经历上述的流程。在上面时序图最后,也就是第10步的调用,会根据不同的情况进入不同的分支,后面会具体分析。

        客户端的Instrumentation类会通过Binder call调用到AMS端的startActivity(上图步骤4),其参数列表为:

参数 解释
IApplicationThread caller
调用者的IApplicationThread对象
String callingPackage
调用者的包名
Intent intent
客户端进程传递过来的Intent对象
String resolvedType
ContentResolver相关
IBinder resultTo
调用者的token
String resultWho
调用者Activity的mEmbeddedID字段
int requestCode
客户端传过来的,为startActivityForResult使用的请求码
int startFlags
0
ProfilerInfo profilerInfo
null
Bundle bOptions
客户端传过来的ActivityOptions参数

        接下来进入到system server进程,从上图步骤4 - 10则为AMS中的行为,下面我们简单分析下在这一系列调用栈中,AMS所发生的一些主要行为:

        ActivityStarter.startActivityMayWait (步骤6):

        1. 解析intent(ActivityStackSupervisor.resolveIntent,最终会通过PackageManagerService解析),获得ResolveInfo对象。

        2. 通过Intent以及刚刚解析出来的ResolveInfo对象去获取ActivityInfo对象(ActivityStackSupervisor.resolveActivity)。

        3. 即将启动的activity是否处于heavy-weight进程中,如果是会进行相关处理。

        ActivityStarter.startActivityLocked -> startActivity (步骤7 - 8):

        1. 检查调用者进程是否为空。

        2. 获取调用者(sourceRecord)的ActivityRecord对象,根据launch flags计算activity result需要发送回的ActivityRecord对象。

        3. 对传递进来的参数进行检查,如果存在非法值则返回。

        4. 创建待启动的ActivityRecord对象。

        5. 检查这次启动是否需要加入PendingActivity的列表中,需要则加入后返回,不需要则启动之前PendingActivity列表中的所有activity

        ActivityStarter.startActivity -> startActivityUnChecked (步骤9 - 10):

        1. setInitialState:为一些全局变量进行赋值,以及一些简单的初始化工作。

        2. computeLaunchingTaskFlags:根据要启动的task,更新mLaunchFlags,和Activity的启动模式相关。

        3. getReusableIntentActivity:获取可复用的ActivityRecord对象。如果存在可复用的ActivityRecord对象,则获取其task,并根据一些条件通知客户端进程进行一些处理(如回调onNewIntent)。接下来会为其设置对应的Stack,并将其移动至前台。即:如果启动的Activity已经存在,在此处则会进入ActivityStack.moveTaskToFrontLocked流程。

        4. 如果未发现可复用的Activity时(首次启动Activity),则需要根据条件创建/复用Task和Stack。此时会通过ActivityStack.startActivityLocked做一些Stack相关的处理。

        5. 无论是否找到可复用的Activity,接下来AMS都会通知客户端进程去paused前一Activity,至此通过客户端进程调用的startActivity触发的AMS行为结束。当前一Activity的进程paused结束后,会再次通知AMS,从而会触发新一轮的行为。

        上面提到,在启动过程中会检查待启动的Activity是否存在可复用的Activity(通常情况下可复用指的是启动一个在后台的Activity,如回桌面时,由于桌面的Activity不会被销毁,所以每次启动时都可以找到可复用的Activity),下面分析一下这两种情况的不同的处理流程:

        1. 非首次启动,调用栈:ActivityStarter.startActivityUnchecked(上面时序图步骤10) -> ActivityStarter.setTargetStackAndMoveToFrontIfNeeded -> ActivityStack.moveTaskToFrontLocked,看这个调用栈的名字可以发现,如果要启动的Activity已经存在,会把其对应的任务移动至前台。其主要行为:

        (1) insertTaskAtTop:更新mTaskToReturnTo字段,调整目标TaskRecord在ActivityStack中的位置。通知WMS TaskRecord的位置变化:StackWindowController.positionChildAtTop

        (2) ActivityStackSupervisor.moveFocusableActivityStackToFrontLocked:将ActivityRecord移动到顶部,将当前ActivityStack设置为mFocusedStack,即当前具有焦点的ActivityStack

        (3) updateTransitLocked:通知WMS设置过渡动画类型。

        (4) ActivityStackSupervisor.resumeFocusedStackTopActivityLocked

        2. 首次启动,调用栈:ActivityStarter.startActivityUnchecked(上面时序图步骤10) ->ActivityStack.startActivityLocked,其主要行为:

        (1) 查看首次启动的ActivityRecord是否以New Task形式启动,如果是,则通过insertTaskAtTop将TaskRecord移动至栈顶;否则,找到当前TaskRecord在全局中的位置。如果WMS端没有对应的WindowContainer,则通知其创建一个(用于和WMS通讯)。

        (2) 检查是否需要创建一个新进程(ProcessRecord)。

        (3) 通知WMS设置过渡动画类型。

        (4) ActivityStackSupervisor.resumeFocusedStackTopActivityLocked

        无论是否首次启动,最终都会进入ActivityStackSupervisor.resumeFocusedStackTopActivityLocked中,接下来会进行一些生命周期相关的处理。下面我们简单分析一下Activity的生命周期是如何调度的。

三. Activity的生命周期


Android O Framework架构分析:以AMS视角看Activity启动过程_第2张图片

        当一个Activity启动时,一般情况下会涉及两个Activity生命周期的变化。根据前文所述,当startActivity被调用时,AMS最终都会触发到ActivityStackSupervisor.resumeFocusedStackTopActivityLocked方法中去,这个方法逻辑非常多,首先会检查当前是否有需要进入paused状态的Activity,如果有,则通知其对应的客户端进程进行相关处理,其时序图如下:

Android O Framework架构分析:以AMS视角看Activity启动过程_第3张图片

        这里的步骤1就是上面startActivity在AMS中都会最终进入的逻辑,这里会检查是否有需要进入paused状态的Activity,如果有,则通知客户端进程,AMS端的startActivity流程结束。客户端进程由ActivityThread接收到AMS端发来的通知,进行相关处理。此时旧的Activity将进入paused状态,其onPause回调被执行(步骤12)。当客户端paused相关调度执行完后,仍然会通知AMS,AMS会进行相关处理。接下来主要分为3种情况,针对这3种情况AMS会进行不同的处理:

        1. 前一个Activity进入paused状态后通知AMS,新创建的Activity启动,如果新创建的Activity已经存在对应进程,则进入onCreate -> onStart -> onResume的生命周期:

Android O Framework架构分析:以AMS视角看Activity启动过程_第4张图片

        这种情况为在已存在的进程下启动一个新的Activity,比如同一个app中启动一个新的Activity,可以看到Activity中一些关于生命周期的回调被执行,其顺序也符合我们贴的那张官方提供的生命周期的图:onCreate (步骤15)-> onStart (步骤18)-> onResume (步骤23)。

        2. 如果新创建的Activity还没有已经存在的进程,则AMS端的处理会有些不同:

Android O Framework架构分析:以AMS视角看Activity启动过程_第5张图片

        这种情况为待启动的Activity还没有对应的进程,比如从桌面启动一个从未启动过的app,其AMS端的处理会完全不同。发起点(步骤1)还是一样,仍需要等待客户端进程通知AMS旧Activity已经进入paused状态了,不同的是AMS需要首先为其创建一个进程,如步骤8所示,这个过程比较复杂,在本文中不做分析。进程创建完后,新创建的进程会通知AMS(步骤10),接下来AMS会在一系列处理后通知该进程(步骤13),对生命周期进行处理。scheduleLaunchActivity在客户端进程所产生的行为与上面情况1一致,即新Activity都会进入onCreate -> onStart -> onResume的生命周期中。

        3. 如果启动一个已存在的Activity,则会进入onRestart(如果之前是stopped状态,则执行onRestart;否则,从onStart开始执行) -> onStart -> onResume

Android O Framework架构分析:以AMS视角看Activity启动过程_第6张图片

        这种情况是启动一个已存在的Activity(之前处于paused或stopped状态,取决于其可不可见),比如从app回到桌面时,桌面的Activity经历的生命周期为onRestart(若桌面之前不可见,步骤13)-> onStart(步骤16)-> onResume(步骤18)。

        至此,Activity启动过程基本完成。简单梳理一下其过程,可以将其主要逻辑概括为:

        1. 客户端进程调用startActivity,通过Binder调用到system server进程中AMS模块;

        2. AMS模块首先进行一些处理,其中包括:检查传递的参数是否合法,根据参数创建其对应的ActivityRecord对象,为其寻找/创建对应的TaskRecord和ActivityStack,并将其移动到前台,通知WMS模块进行相关处理等等。

        3. 之后会对生命周期进行管理,首先会旧Activity会进入paused状态,AMS通过Binder通知对应客户端进程。客户端paused行为处理完后会再次通知AMS,AMS会根据新启动的Activity的不同情况(是否是可复用的Activity,是否已存在进程等)进行不同的处理。最终新的Activity都将进入resumed状态。

你可能感兴趣的:(Android,Framework)