准备
我们首先去除掉系统的:
1 | adb root |
然后等待开机完成App(”com.android.testgreen”),抓取Log。setprop vendor.dump true。抓取的帧会按数字排列,还带分辨率参数。adb pull /data/dump/。抓到的bin文件可以用软件7yuv打开查看,格式设定为RGBA8888
App(”com.android.testgreen”)渲染图:
FrameBuffer渲染图:
效果图:
==源码(部分)==:
packages/apps/testViewportGreen && testViewportBlue && testViewportRed/
frameworks/base/core/java/android/app/
frameworks/base/services/core/java/com/android/server/wm/
frameworks/base/services/core/java/com/android/server/am/
frameworks/base/services/core/java/com/android/server/policy/
frameworks/native/services/surfaceflinger/
frameworks/native/libs/gui/
frameworks/native/libs/ui/
一、Activity概述
基于Android 10.0的源码剖析, 分析Android Activity启动流程:
1.1、Activity的管理机制
Android的管理主要是通过Activity栈来进行的。当一个Activity启动时,系统根据其配置或调用的方式,将Activity压入一个特定的栈中,系统处 于运行(Running or Resumed)状态。当按Back键或触发finish()方法时,Activity会从栈中被压出,进而被销毁,当有新的Activity压入栈时, 如果原Activity仍然可见,则原Activity的状态将转变为暂停(Paused)状态,如果原Activity完全被遮挡,那么其状态将转变为 停止(Stopped)。
1.1.1、Task和Stack
Android系统中的每一个Activity都位于一个Task中。一个Task可以包含多个Activity,同一个Activity也可能有多个实例。 在AndroidManifest.xml中,我们可以通过android:launchMode来控制Activity在Task中的实例。
1.1.2、启动模式的作用
Activity启动模式就是属于Activity配置属性之一,叫它具有四种启动模式,分别是:1.standard ,2.singleTop,3.singleTask,4.singleInstance,一般如果不显示声明,默认为standard模式。launchMode 在多个Activity跳转的过程中扮演着重要的角色,它可以决定是否生成新的Activity实例,是否重用已存在的Activity实例,是否和其他 Activity实例公用一个task里。
1.1.3、启动模式的作用
模式说明
- standard模式:这是系统默认的启动模式,这种模式就是创建一个Activity压入Task容器栈中,当当前Activity激活,并处在和用户交互时,此Activity弹出栈顶,当finish()时候,在任务栈中销毁该实例。
- singleTop模式:这种模式首先会判断要激活的Activity是否在栈顶,如果在则不重新创建新的实例,复用当前的实例,如果不在栈顶,则在任务栈中创建实例。条件是是否在栈顶,而不是是否在栈中。
- singleTask模式: 这种模式启 动的目标Activity实例如果已经存在task容器栈中,不管当前实例处于栈的任何位置,是栈顶也好,栈底也好,还是处于栈中间,只要目标 Activity实例处于task容器栈中,都可以重用该Activity实例对象,然后,把处于该Activity实例对象上面全部Activity实 例清除掉,并且,task容器栈中永远只有唯一实例对象,不会存在两个相同的实例对象。所以,如果你想你的应用不管怎么启动目标Activity,都只有 唯一一个实例对象,就使用这种启动模式。
- singleInstance模式:当该模式Activity实例在任务栈中创建后,只要该实例还在任务栈中,即只要激活的是该类型的Activity,都会通过调用实例的newInstance()方法重用该Activity,此时使用的都是同一个Activity实例,它都会处于任务栈的栈顶。此模式一般用于加载较慢的,比较耗性能且不需要每次都重新创建的Activity。
1.1.4、ActivityStack & TaskRecord & ActivityRecord 关系
Back栈管理了当你在Activity上点击Back键,当前Activity销毁后应该跳转到哪一个Activity的逻辑。
其实在ActivityManagerService与WindowManagerService内部管理中,在Task之外,还有一层容器,这个容器应用开发者和用户可能都不会感觉到或者用到,但它却非常重要,那就是ActivityStack。 下文中,我们将看到,Android系统中的多窗口管理,就是建立在Stack的数据结构上的。 一个ActivityStack中包含了多个TaskRecord,一个TaskRecord中包含了多个ActivityRecord,下图描述了它们的关系:
另外还有一点需要注意的是,ActivityManagerService和WindowManagerService中的Task和Stack结构是一一对应的,对应关系对于如下:
ActivityStack <–> TaskStack
TaskRecord <–> Task
即,ActivityManagerService中的每一个ActivityStack或者TaskRecord在WindowManagerService中都有对应的TaskStack和Task,这两类对象都有唯一的id(id是int类型),它们通过id进行关联。
1.2、ActivityManagerService相关类简介
Instrumentation
用于实现应用程序测试代码的基类。当在打开仪器的情况下运行时,这个类将在任何应用程序代码之前为您实例化,允许您监视系统与应用程序的所有交互。可以通过AndroidManifest.xml的标签描述该类的实现。ActivityManager
该类提供与Activity、Service和Process相关的信息以及交互方法, 可以被看作是ActivityManagerService的辅助类。ActivityManagerService
Android中最核心的服务,主要负责系统中四大组件的启动、切换、调度及应用程序的管理和调度等工作。ActivityThread
管理应用程序进程中主线程的执行,根据Activity管理者的请求调度和执行activities、broadcasts及其相关的操作。ActivityStack
负责单个Activity栈的状态和管理。ActivityStackSupervisor
负责所有Activity栈的管理。内部管理了mHomeStack、mFocusedStack和mLastFocusedStack三个Activity栈。其中,mHomeStack管理的是Launcher相关的Activity栈;mFocusedStack管理的是当前显示在前台Activity的Activity栈;mLastFocusedStack管理的是上一次显示在前台Activity的Activity栈。ClientLifecycleManager
用来管理多个客户端生命周期执行请求的管理类。Activity
用来管理客户端视图、点击、输入等功能的抽象,具有完整的生命周期ViewRootImpl
APP进程与system_server进程进行视图相关通信的桥梁,同时也管理着APP进程视图方面操作的主要逻辑ActivityRecord
Activity的信息记录在ActivityRecord对象, 并通过通过成员变量task指向TaskRecord
ProcessRecord app //跑在哪个进程
TaskRecord task //跑在哪个task
ActivityInfo info // Activity信息
ActivityState state //Activity状态
ApplicationInfo appInfo //跑在哪个app
ComponentName realActivity //组件名
String packageName //包名
String processName //进程名
int launchMode //启动模式
int userId // 该Activity运行在哪个用户id
- ActivityState:
INITIALIZING
RESUMED:已恢复
PAUSING
PAUSED:已暂停
STOPPING
STOPPED:已停止
FINISHING
DESTROYING
DESTROYED:已销毁
- TaskRecord
Task的信息记录在TaskRecord对象.
ActivityStack stack; //当前所属的stack
ArrayListmActivities;; // 当前task的所有Activity列表
int taskId
String affinity; 是指root activity的affinity,即该Task中第一个Activity;
int mCallingUid;
String mCallingPackage; //调用者的包名
- ActivityStack
ArrayList
mTaskHistory //保存所有的Task列表
final int mStackId;
int mDisplayId;
ActivityRecord mPausingActivity //正在pause
ActivityRecord mLastPausedActivity
ActivityRecord mResumedActivity //已经resumed
ActivityRecord mLastStartedActivity
所有前台stack的mResumedActivity的state == RESUMED, 则表示allResumedActivitiesComplete, 此时mLastFocusedStack = mFocusedStack;
- ActivityStackSupervisor
ActivityStack mHomeStack //桌面的stack
ActivityStack mFocusedStack //当前聚焦stack
ActivityStack mLastFocusedStack //正在切换
SparseArray mActivityDisplays //displayId为key
SparseArray mActivityContainers // mStackId为key
1.3、相关类重要成员变量
1.4、小结:
总体概览图:
1、点击桌面App图标,Launcher进程采用Binder IPC向system_server进程发起startActivity请求;
2、system_server进程接收到请求后,向zygote进程发送创建进程的请求;
3、Zygote进程fork出新的子进程,即App进程;
4、App进程,通过Binder IPC向sytem_server进程发起attachApplication请求;
5、system_server进程在收到请求后,进行一系列准备工作后,再通过binder IPC向App进程发送scheduleLaunchActivity请求;
6、App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送LAUNCH_ACTIVITY消息;
7、主线程在收到Message后,通过发射机制创建目标Activity,并回调Activity.onCreate()等方法。
二、APP请求启动Activity(普通app启动流程)
2.1、Activity.startActivity()(普通app启动流程)
从Launcher启动应用的时候,经过调用会执行Activity中的startActivity。(我们这里testred就是launcher)
1 | X:\frameworks\base\core\java\android\app\Activity.java |
2.2、Activity.startActivityForResult()(普通app启动流程)
1 | X:\frameworks\base\core\java\android\app\Activity.java |
2.3、Instrumentation.execStartActivity()(普通app启动流程)
1 | X:\frameworks\base\core\java\android\app\Instrumentation.java |
ActivityTaskManager.getService()返回一个android.app.IActivityManager.Stub.Proxy对象(请参考Android9.0activity启动分析)
IActivityManager.aidl -> Binder机制 -> ActivityManagerService
三、 ActivityManagerService接收启动Activity的请求
3.1、ActivityManagerService.startActivity()(普通app启动流程)
1 | X:\frameworks\base\services\core\java\com\android\server\am\ActivityManagerService.java |
3.2、ActivityTaskManagerService.startActivityAndWait()(普通app启动流程)
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityTaskManagerService.java |
3.3、ActivityStarter.execute()(普通app启动流程)
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStarter.java |
这个方法是基于初始的参数来启动activity,可以看到有两种启动activity的代码块,startActivityMayWait最终会调用startActivity所以:我们来看startActivityMayWait源码
3.4、App(”com.android.testgreen”)(Launcher App启动流程)
Android 开机会启动一个com.android.settings/.FallbackHome,当FallbackHome Paused的时候,此时系统已经没有Activity,ActivityStack 就会调用方法resumeNextFocusableActivityWhenStackIsEmpty。
1 | 11-12 03:15:29.679 433 916 V ActivityStack_Pause: Activity paused: token=Token{484d3e0 ActivityRecord{fd3e474 u0 com.android.settings/.FallbackHome t1 f}}, timeout=false |
此时就是我们的主脚上场,App(”com.android.testgreen”)启动,我们看看调用Stack。
1 | 11-12 03:15:29.701 433 916 I ActivityStack: java.lang.RuntimeException: here |
可以看到也会执行ActivityStarter.execute()来继续执行。所以我们继续分析代码。
3.5、ActivityStarter.startActivity()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStarter.java |
3.6、ActivityStarter.startActivityUnchecked()
1 | // Note: This method should only be called from {@link startActivity}. |
3.6.1、ActivityStarter.setTaskFromReuseOrCreateNewTask()-创建新的Task[AMS端]
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStarter.java |
3.6.1.1、TaskRecord创建createTaskRecord()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStack.java |
3.6.1.1.1、TaskRecord.create()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\TaskRecord.java |
3.6.1.1.2、将TaskRecord加入到ActivityStack中
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStack.java |
3.6.1.1.3、TaskRecord..createTask()[WMS端的Task]
1 | X:\frameworks\base\services\core\java\com\android\server\wm\TaskRecord.java |
3.6.1.1.4、将Task[WMS]加入到TaskStack
1 | X:\frameworks\base\services\core\java\com\android\server\wm\TaskStack.java |
3.6.2、ActivityStack.startActivityLocked()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStack.java |
3.6.3、ActivityStack.ensureActivitiesVisibleLocked()
由于现在App进程还未创建,会走此分支
1 | final void ensureActivitiesVisibleLocked(ActivityRecord starting, int configChanges, |
3.6.3.1、ActivityStack.makeVisibleAndRestartIfNeeded()
此时ActivityRecord 状态为state=INITIALIZING
11-12 03:15:29.708 433 916 V ActivityStack_Visibility: Make visible? ActivityRecord{563ed0d u0 com.android.testred/.TestActivity t2} finishing=false state=INITIALIZING
1 | private boolean makeVisibleAndRestartIfNeeded(ActivityRecord starting, int configChanges, |
3.6.4、StackSupervisor.startSpecificActivityLocked()
1 | void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) { |
3.6.5、StackSupervisor.startSpecificActivityLocked()
ActivityManagerInternal::startProcess -> ActivityManagerService::startProcess
1 | frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java |
进程的创建跟之前分析的一致,就不再分析了。创建完成后回调用ActivityThread的main方法。
3.7、Activity所在应用主线程初始化 ActivityThread.main()
在ActivityThread.main方法中对ActivityThread进行了初始化,创建了主线程的Looper对象并调用Looper.loop()方法启动Looper,把自定义Handler类H的对象作为主线程的handler。接下来跳转到ActivityThread.attach方法,看都做了什么。
1 | public static void main(String[] args) { |
Activity所在的进程创建完了,主线程也初始化了,接下来就该真正的启动Activity了。在ActivityThread.attach方法中,首先会通过ActivityManagerService为这个应用绑定一个Application,然后添加一个垃圾回收观察者,每当系统触发垃圾回收的时候就会在run方法里面去计算应用使用了多少内存,如果超过总量的四分之三就会尝试释放内存。最后,为根View添加config回调接收config变化相关的信息。
1 |
|
3.7.1、ActivityManagerService.attachApplication()
1 | X:\frameworks\base\services\core\java\com\android\server\am\ActivityManagerService.java |
这里又调用App进程自己的bindApplication()方法。接着
1 | callers=com.android.server.wm.ActivityStackSupervisor.realStartActivityLocked:917 com.android.server.wm.RootActivityContainer.attachApplication:784 com.android.server.wm.ActivityTaskManagerService$LocalService.attachApplication:6949 com.android.server.am.ActivityManagerService.attachApplicationLocked:5213 com.android.server.am.ActivityManagerService.attachApplication:5293 |
3.7.2、ActivityTaskManagerService$LocalService.attachApplication()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityTaskManagerService.java |
3.7.3、RootActivityContainer.attachApplication()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\RootActivityContainer.java |
3.7.4、ActivityStackSupervisor.realStartActivityLocked()
又进入熟悉的realStartActivityLocked方法了,之前因为app进程没有创建,startSpecificActivityLocked走的另外一个分支,还记着吗
1 | boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc, |
3.7.5、LaunchActivityItem.obtain()
ClientTransaction对象添加LaunchActivityItem的callback,然后设置当前的生命周期状态,最后调用ClientLifecycleManager.scheduleTransaction方法执行。
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStackSupervisor.java |
3.7.6、ActivityStack.minimalResumeActivityLocked(r)
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStack.java |
四、执行启动Acitivity
4.1、LaunchActivityItem.execute()
1 | X:\frameworks\base\services\core\java\com\android\server\wm\ActivityStackSupervisor.java |
这里的clientTransaction.addCallback(LaunchActivityItem.obtain(arg…))就是我们目前用到的lifecycleItem,也就是说 这个lifecycleItem就是LaunchActivityItem
继续看lifecycleItem.execute(mTransactionHandler, token, mPendingActions);源码:
1 | X:\frameworks\base\core\java\android\app\servertransaction\LaunchActivityItem.java |
4.2、ActivityThread.handleLaunchActivity()
client.handleLaunchActivity就是:控制activity的生命周期 真正的实现类是ClientTransactionHandler的子类 Activityhread;
继续看client.handleLaunchActivity源码:
1 |
|
4.3、ActivityThread.performLaunchActivity()
1 | /** Core implementation of activity launch. */ |
- 初始化activity的context
- 利用classloader机制反射获取activity实例
- 创建app的入口application
- 执行 activity的attach方法 初始化window/父parent-DecorView/windowManage ,windowManager的子类为 - WindowManagerimpl 是view和window的操作类
- 执行activity的onCreate方法
至此executeCallbacks执行完毕,开始执行executeLifecycleState方法。先执行cycleToPath方法,生命周期状态是从ON_CREATE状态到ON_RESUME状态,中间有一个ON_START状态,所以会执行ActivityThread.handleStartActivity方法。
1 | X:\frameworks\base\core\java\android\app\servertransaction\TransactionExecutor.java |
从ActivityThread.handleStartActivity方法经过多次跳转最后会调用Activity.onStart方法,至此cycleToPath方法执行完毕。
1 | frameworks/base/core/java/android/app/ActivityThread.java |
执行完毕cycleToPath,开始执行ResumeActivityItem.execute方法。
1 | frameworks/base/core/java/android/app/servertransaction/ResumeActivityItem.java |
经过上面的多次跳转最终调用到Activity.onResume方法,Activity启动完毕。
1 | 我们来看一下Activity 的生命周期: |
performPauseActivityIfNeeded
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17performPauseActivityIfNeeded
11-12 03:16:44.970 728 728 I ActivityThread: performPauseActivityIfNeeded
11-12 03:16:44.970 728 728 I ActivityThread: java.lang.RuntimeException: here
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread.performPauseActivityIfNeeded(ActivityThread.java:4493)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread.performPauseActivity(ActivityThread.java:4461)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread.handleRelaunchActivityInner(ActivityThread.java:5261)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:5199)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.servertransaction.ActivityRelaunchItem.execute(ActivityRelaunchItem.java:69)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
11-12 03:16:44.970 728 728 I ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:107)
11-12 03:16:44.970 728 728 I ActivityThread: at android.os.Looper.loop(Looper.java:214)
11-12 03:16:44.970 728 728 I ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:7368)
11-12 03:16:44.970 728 728 I ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
11-12 03:16:44.970 728 728 I ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
11-12 03:16:44.970 728 728 I ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930performStopActivityInner
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1511-12 03:15:31.339 729 729 I ActivityThread: performStopActivityInner
11-12 03:15:31.339 729 729 I ActivityThread: java.lang.RuntimeException: here
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.ActivityThread.performStopActivityInner(ActivityThread.java:4565)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.ActivityThread.handleStopActivity(ActivityThread.java:4679)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:233)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
11-12 03:15:31.339 729 729 I ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:107)
11-12 03:15:31.339 729 729 I ActivityThread: at android.os.Looper.loop(Looper.java:214)
11-12 03:15:31.339 729 729 I ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:7368)
11-12 03:15:31.339 729 729 I ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
11-12 03:15:31.339 729 729 I ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
11-12 03:15:31.339 729 729 I ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)performDestroyActivity
1
2
3
4
5
6
7
8
9
10
11
12
13
1411-12 03:15:31.341 729 729 I ActivityThread: performDestroyActivity
11-12 03:15:31.341 729 729 I ActivityThread: java.lang.RuntimeException: here
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:4909)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:4982)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:44)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
11-12 03:15:31.341 729 729 I ActivityThread: at android.os.Handler.dispatchMessage(Handler.java:107)
11-12 03:15:31.341 729 729 I ActivityThread: at android.os.Looper.loop(Looper.java:214)
11-12 03:15:31.341 729 729 I ActivityThread: at android.app.ActivityThread.main(ActivityThread.java:7368)
11-12 03:15:31.341 729 729 I ActivityThread: at java.lang.reflect.Method.invoke(Native Method)
11-12 03:15:31.341 729 729 I ActivityThread: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
11-12 03:15:31.341 729 729 I ActivityThread: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
前面我们分析了onCreate()、onStart() 、onResume()、onPause()。 Activity 暂停销毁时的 、onStop() 、onDestroy() 回调都与前面的过程大同小异,这里就只列举相应的方法栈,不再继续描述。
1 | ---------------------------------------- |