【Android 源码分析】Activity生命周期之onStop-1

忽然有一天,我想要做一件事:去代码中去验证那些曾经被“灌输”的理论。
                  
                  
                                           – 服装学院的IT男

本篇已收录于Activity短暂的一生系列
欢迎一起学习讨论Android应用开发或者WMS
V:WJB6995
Q:707409815

正文

生命周期系列:

  • Activity生命周期之onPause

  • onCreate,onStart,onResume-1

  • onCreate,onStart,onResume-2

  • Activity生命周期之onStop-1

  • Activity生命周期之onStop-2

  • Activity生命周期之onDestory

之前看过一遍流程的Events日志

// SystemService端创建TargetActivity  (writeWmCreateActivity)
03-27 14:41:06.428 27889 28629 I wm_create_activity: [0,253598020,21,com.google.android.dialer/.extensions.GoogleDialtactsActivity,android.intent.action.MAIN,NULL,NULL,270532608]// SystemService端触发SourceActivity的Pause (writeWmPauseActivity)
03-27 14:41:06.431 27889 28629 I wm_pause_activity: [0,51114540,com.android.launcher3/.uioverrides.QuickstepLauncher,userLeaving=true,pauseBackTasks]// SourceActivity应用端将执行onPause (writeWmOnPausedCalled)
03-27 14:41:06.448 28606 28606 I wm_on_paused_called: [51114540,com.android.launcher3.uioverrides.QuickstepLauncher,performPause]// SystemService端把SourceActivity添加进需要stop的集合 (writeWmAddToStopping)
03-27 14:41:06.459 27889 28630 I wm_add_to_stopping: [0,51114540,com.android.launcher3/.uioverrides.QuickstepLauncher,makeInvisible]// SystemService端要真正触发TargetActivity启动 (writeWmRestartActivity)
03-27 14:41:06.487 27889 28630 I wm_restart_activity: [0,253598020,21,com.google.android.dialer/.extensions.GoogleDialtactsActivity]// TargetActivity端将执行onCreate  (writeWmOnCreateCalled)
03-27 14:41:06.769  3401  3401 I wm_on_create_called: [253598020,com.google.android.dialer.extensions.GoogleDialtactsActivity,performCreate]// TargetActivity端将执行onStart (writeWmOnStartCalled)
03-27 14:41:06.900  3401  3401 I wm_on_start_called: [253598020,com.google.android.dialer.extensions.GoogleDialtactsActivity,handleStartActivity]// TargetActivity端将执行Resume (writeWmOnResumeCalled)
03-27 14:41:06.911  3401  3401 I wm_on_resume_called: [253598020,com.google.android.dialer.extensions.GoogleDialtactsActivity,RESUME_ACTIVITY]// SystemService端触发SourceActivity的stop (writeWmStopActivity)
03-27 14:41:07.097 27889 30491 I wm_stop_activity: [0,51114540,com.android.launcher3/.uioverrides.QuickstepLauncher]// SourceActivity应用端将执行onStop (writeWmStopActivity)
03-27 14:41:07.119 28606 28606 I wm_on_stop_called: [51114540,com.android.launcher3.uioverrides.QuickstepLauncher,STOP_ACTIVITY_ITEM]

其中可以看到很早就打印了 “wm_add_to_stopping”,但是 SourceActivity 真正执行 onPause (“wm_on_stop_called”)却是在最后。

所以按照顺序,先看看 “wm_add_to_stopping”相关的逻辑。

整个流程分为3步:

    1. addToStopping 流程,将应用添加进需要stop的列表 – system_service进程处理
    1. stopIfPossible 流程,也就是开始执行stop – system_service进程处理
    1. 应用端处理stop流程 – 应用进程处理

前面个都是system_service进程处理的,第三步是在 SourceActivity 的应用进程处理。
本篇为 onStop第一篇,介绍 system_service 进程是如何把 SourceActivity 添加进stop集合。

第一步:addToStopping 流程

1 调用链概览

通过Events日志可知“wm_add_to_stopping”的执行在真正启动 TargetActivity 之前。 在 SourceActivity 的 pause 流程之后。

“wm_add_to_stopping” 日志打印的方法在 ActivityRecord::addToStopping 中,在这个方法加上堆栈得到以下内容

03-28 14:39:03.326 23968 26756 I wm_add_to_stopping: [0,264636779,com.android.launcher3/.uioverrides.QuickstepLauncher,makeInvisible]
03-28 14:39:03.327 23968 26756 E biubiubiu: ActivityRecord  addToStopping: ActivityRecord{fc6096b u0 com.android.launcher3/.uioverrides.QuickstepLauncher} t7}
03-28 14:39:03.327 23968 26756 E biubiubiu: java.lang.Exception
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.ActivityRecord.addToStopping(ActivityRecord.java:6225)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.ActivityRecord.makeInvisible(ActivityRecord.java:5811)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.EnsureActivitiesVisibleHelper.setActivityVisibilityState(EnsureActivitiesVisibleHelper.java:243)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.EnsureActivitiesVisibleHelper.process(EnsureActivitiesVisibleHelper.java:155)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.TaskFragment.updateActivityVisibilities(TaskFragment.java:1118)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task.lambda$ensureActivitiesVisible$19(Task.java:4918)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task$$ExternalSyntheticLambda24.accept(Unknown Source:10)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task.forAllLeafTasks(Task.java:3183)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task.forAllLeafTasks(Task.java:3171)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task.ensureActivitiesVisible(Task.java:4917)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.DisplayContent.lambda$ensureActivitiesVisible$44(DisplayContent.java:6143)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.DisplayContent$$ExternalSyntheticLambda38.accept(Unknown Source:10)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.Task.forAllRootTasks(Task.java:3195)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2033)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.WindowContainer.forAllRootTasks(WindowContainer.java:2026)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.DisplayContent.ensureActivitiesVisible(DisplayContent.java:6142)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.RootWindowContainer.ensureActivitiesVisible(RootWindowContainer.java:1873)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.RootWindowContainer.ensureActivitiesVisible(RootWindowContainer.java:1854)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.TaskFragment.completePause(TaskFragment.java:1802)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.ActivityRecord.activityPaused(ActivityRecord.java:6063)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.ActivityClientController.activityPaused(ActivityClientController.java:182)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at android.app.IActivityClientController$Stub.onTransact(IActivityClientController.java:574)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at com.android.server.wm.ActivityClientController.onTransact(ActivityClientController.java:125)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at android.os.Binder.execTransactInternal(Binder.java:1280)
03-28 14:39:03.327 23968 26756 E biubiubiu: 	at android.os.Binder.execTransact(Binder.java:1244)

根据这段堆栈很明显可以看初是 SourceActivity 执行的 activityPaused 流程,再根据之前的Events日志顺序,也知道是在 SourceActivity 执行完 pause 流程后触发的。

也就是说 activityPaused 流程再触发 TargetActivity 启动前,还执行了 addToStopping 流程,将 SourceActivity 放进来需要 stop 的列表中。

关于 【Activity启动流程-2】流程之前整理的调用链如下:

ActivityClientController::activityPausedActivityRecord::activityPausedTaskFragment::completePauseRootWindowContainer::resumeFocusedTasksTopActivities       --分支1 ,再次执行 resumeFocusedTasksTopActivitiesRootWindowContainer::resumeFocusedTasksTopActivitiesTask::resumeTopActivityUncheckedLockedTask::resumeTopActivityInnerLockedTaskFragment::resumeTopActivityActivityTaskSupervisor::startSpecificActivity                           --触发 startSpecificActivity 判断应用是否创建RootWindowContainer::ensureActivitiesVisible              --分支2RootWindowContainer::ensureActivitiesVisibleDisplayContent::ensureActivitiesVisible WindowContainer::forAllRootTasks  --忽略固定逻辑Task::ensureActivitiesVisibleTask::forAllLeafTasks --忽略固定逻辑TaskFragment::updateActivityVisibilitiesEnsureActivitiesVisibleHelper::processEnsureActivitiesVisibleHelper::setActivityVisibilityStateEnsureActivitiesVisibleHelper::makeVisibleAndRestartIfNeededActivityTaskSupervisor::startSpecificActivity       --触发 startSpecificActivity 判断应用是否创建

这2个分支在【Activity启动流程】都分析过了,但是现在关注的是生命周期相关, 分之一和生命周期相关的流程已经分析过了,现在需要看看分支2和生命周期相关的逻辑。

# TaskFragmentvoid completePause(boolean resumeNext, ActivityRecord resuming) {Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "completePause");// 拿到之前的Activity,也就是需要 pause的ActivityRecord prev = mPausingActivity;ProtoLog.v(WM_DEBUG_STATES, "Complete pause: %s", prev);if (prev != null) {......// 设置窗口状态为PAUSEDprev.setState(PAUSED, "completePausedLocked");if (prev.finishing) {...... 如果已经finish,上面还在设置 pause,那正常应该是还没finish} else if (prev.hasProcess()) {// 打印状态日志ProtoLog.v(WM_DEBUG_STATES, "Enqueue pending stop if needed: %s "+ "wasStopping=%b visibleRequested=%b",  prev,  wasStopping,prev.mVisibleRequested);}else {......}if (resumeNext) {......// 重点* 第1分支Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "resumeFocusedTasksTopActivities");mRootWindowContainer.resumeFocusedTasksTopActivities(topRootTask, prev,null /* targetOptions */);Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);......}......// 重点* 第2分支Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "ensureActivitiesVisible");mRootWindowContainer.ensureActivitiesVisible(resuming, 0, !PRESERVE_WINDOWS);Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);......}Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);}

我在代码上加了几个 Trace 稍后再看,当前分析 onStop 流程所以只看第2分支触发的 ensureActivitiesVisible 流程,这个流程就是界面上有啥风吹草动,SystemService 端需要确保手机屏幕上Activity正确的显示。

根据上面的堆栈和整理出的调用链 RootWindowContainer::ensureActivitiesVisible 最终会执行到 EnsureActivitiesVisibleHelper::process 来处理当前 Task 下 Activity 的可见性。

EnsureActivitiesVisibleHelper的相关处理后面单独放一个章节详细解释,是ensureActivitiesVisible 流程非常重要的一环,目前可以自行了解或以黑盒概念理解

直接看 EnsureActivitiesVisibleHelper::setActivityVisibilityState 对 SourceActivity 的 stop 逻辑是如何处理的。

# EnsureActivitiesVisibleHelper// 当前Task栈顶是否有Activityprivate boolean mAboveTop;// 设置Activity可见性private void setActivityVisibilityState(ActivityRecord r, ActivityRecord starting,final boolean resumeTopActivity) {......// SourceActivity 所在的Task 被遮挡了,所以mBehindFullyOccludedContainer为truer.updateVisibilityIgnoringKeyguard(mBehindFullyOccludedContainer);// 自然是返回不可见final boolean reallyVisible = r.shouldBeVisibleUnchecked();......if (reallyVisible) {// 忽略可见处理} else {if (DEBUG_VISIBILITY) {Slog.v(TAG_VISIBILITY, "Make invisible? " + r+ " finishing=" + r.finishing + " state=" + r.getState()+ " containerShouldBeVisible=" + mContainerShouldBeVisible+ " behindFullyOccludedContainer=" + mBehindFullyOccludedContainer+ " mLaunchTaskBehind=" + r.mLaunchTaskBehind);}// 不可见的处理 --使Activity不可见r.makeInvisible();}......// launcher处理}

所以执行 ActivityRecord::makeInvisible 方法开始设置 SourceActivity 不可见。

2 设置Activity不可见 – ActivityRecord::makeInvisible

makeInvisible 方法触发的调用链:

ActivityRecord::makeInvisibleActivityRecord::setVisibility  -- setVisibility通用流程ActivityRecord::setVisibilityActivityRecord::setVisibleRequestedActivityRecord::addToStoppingActivityTaskSupervisor.mStoppingActivities::add --添加当前Activity到集合ActivityTaskSupervisor::scheduleIdle  -- 发送IDLE_NOW_MSG--------------处理消息-------------------ActivityTaskSupervisor$ActivityTaskSupervisorHandler::handleMessageActivityTaskSupervisor$ActivityTaskSupervisorHandler::handleMessageInnerActivityTaskSupervisor$ActivityTaskSupervisorHandler::activityIdleFromMessageActivityTaskSupervisor::activityIdleInternalActivityTaskSupervisor::processStoppingAndFinishingActivities -- 热启动第一次执行到这时因条件不满足不会执行后续逻辑

看一下代码执行流程。

# ActivityRecordvoid makeInvisible() {// mVisibleRequested 为false表示当前 Activity 已经在处理可见性逻辑了,不需要执行后面的逻辑, if (!mVisibleRequested) {if (DEBUG_VISIBILITY) Slog.v(TAG_VISIBILITY, "Already invisible: " + this);return;}// Now for any activities that aren't visible to the user, make sure they no longer are// keeping the screen frozen.// 对于不可见的Activity,需要开始真正的处理了if (DEBUG_VISIBILITY) {Slog.v(TAG_VISIBILITY, "Making invisible: " + this + ", state=" + getState());}try {final boolean canEnterPictureInPicture = checkEnterPictureInPictureState("makeInvisible", true /* beforeStopping */);// Defer telling the client it is hidden if it can enter Pip and isn't current paused,// stopped or stopping. This gives it a chance to enter Pip in onPause().// 画中画相关final boolean deferHidingClient = canEnterPictureInPicture&& !isState(STARTED, STOPPING, STOPPED, PAUSED);setDeferHidingClient(deferHidingClient);// 重点* 1. 设置为不可见 ,会将 mVisibleRequested 设置为falsesetVisibility(false);switch (getState()) {case STOPPING:case STOPPED:// Reset the flag indicating that an app can enter picture-in-picture once the// activity is hiddensupportsEnterPipOnTaskSwitch = false;break;case RESUMED:case INITIALIZING:case PAUSING:case PAUSED:case STARTED:// 重点* 2. 加入到Stop列表addToStopping(true /* scheduleIdle */,canEnterPictureInPicture /* idleDelayed */, "makeInvisible");break;default:break;}} catch (Exception e) {// Just skip on any failure; we'll make it visible when it next restarts.Slog.w(TAG, "Exception thrown making hidden: " + intent.getComponent(), e);}}
    1. 调用 setVisibility 方法设置为不可见
    1. 根据 state 做了一些处理,STOPPING 和 STOPPED 的情况下就设置了一个画中画的标志位,其他的几个状态会执行 addToStopping

方法前面的 mVisibleRequested 唯一赋值的地方在 ActivityRecord::setVisibleRequested 方法中,值为可见性,所以这个变量表示: 当前Activity被设置的可见性的值。

makeInvisible 方法是要将 Activity 设置为不可见,所以方法开始的时候如果 mVisibleRequested 是 false, 说明已经在做这件事了, 就不需要执行后面的逻辑了。

然后中间有一段画中画的逻辑处理,这段当前不需要关注。

再下面就是getState() 的返回值处理,当前执行到这里的是 SourceActivity 的 activityPaused 流程,所以这里的 getState() 返回的是 PAUSED ,这个可以通过上面的log确认。

2.1 setVisibility 方法

看一眼 setVisibility方法主要做了什么

# ActivityRecordvoid setVisibility(boolean visible, boolean deferHidingClient) {......ProtoLog.v(WM_DEBUG_APP_TRANSITIONS,"setAppVisibility(%s, visible=%b): %s visible=%b mVisibleRequested=%b Callers=%s",token, visible, appTransition, isVisible(), mVisibleRequested,Debug.getCallers(6));......// 处理 DisplayContent 下的2个集合displayContent.mOpeningApps.remove(this);displayContent.mClosingApps.remove(this);......// 1. 给 mVisibleRequested 赋值setVisibleRequested(visible);......// 2. 处理 DisplayContent 下的2个集合if (visible) {displayContent.mOpeningApps.add(this);mEnteringAnimation = true;} else if (mVisible) {displayContent.mClosingApps.add(this);mEnteringAnimation = false;}......// 3. 提交可见性更新commitVisibility(visible, true /* performLayout */);updateReportedVisibilityLocked();}
    1. 执行 setVisibleRequested 方法,内部会对 mVisibleRequested 变量赋值
    1. 处理 DisplayContent类维护的2个列表, 分别对应打开和关闭的应用(这个很重要)
    1. 执行 commitVisibility 方法,这里会最终可见性

继续看主流程 addToStopping 方法。

addToStopping 流程非常重要

3. ActivityRecord::addToStopping 方法

# ActivityRecordfinal ActivityTaskSupervisor mTaskSupervisor;void addToStopping(boolean scheduleIdle, boolean idleDelayed, String reason) {if (!mTaskSupervisor.mStoppingActivities.contains(this)) {// 打印 event日志EventLogTags.writeWmAddToStopping(mUserId, System.identityHashCode(this),shortComponentName, reason);// 重点* 1. 唯一将Activity添加到 mStoppingActivities 集合中的代码mTaskSupervisor.mStoppingActivities.add(this);}final Task rootTask = getRootTask();......if (scheduleIdle || forceIdle) {// 打印Proto日志ProtoLog.v(WM_DEBUG_STATES,"Scheduling idle now: forceIdle=%b immediate=%b", forceIdle, !idleDelayed);if (!idleDelayed) {// 重点* 2. 一般都是立即执行,所以是走这(可见根据上面log的immediate值确认)mTaskSupervisor.scheduleIdle();} ......} ......}

这个方法做了2件事

    1. 将当前这个Activity 添加到 ActivityTaskSupervisor 下的 mStoppingActivities 集合
    1. 执行 ActivityTaskSupervisor::scheduleIdle 内部会发送 “IDLE_NOW_MSG” 消息,进而触发后续 stop 逻辑

这个方法正常是执行 scheduleIdle 逻辑的, 另外有 Events 和Proto 2个日志的打印,如果发现有问题可以仔细看看相关变量的打印。

ActivityTaskSupervisor::scheduleIdle 方法如下:

# ActivityTaskSupervisorfinal void scheduleIdle() {if (!mHandler.hasMessages(IDLE_NOW_MSG)) {// 发送消息,打堆栈if (DEBUG_IDLE) Slog.d(TAG_IDLE, "scheduleIdle: Callers=" + Debug.getCallers(4));mHandler.sendEmptyMessage(IDLE_NOW_MSG);}}

这个方法主要就是发送了“IDLE_NOW_MSG” 消息,并且打印了debug的堆栈。

冷启动的话 ActivityTaskSupervisor::scheduleIdle 的调用链就上面分析的一个,但是应用内启动Activity 根据log打印的堆栈发现会有3个调用链,这边也整理一下3个调用链,感兴趣的可以自己跟一下

Callers=com.android.server.wm.ActivityRecord.addToStopping:6239com.android.server.wm.ActivityRecord.makeInvisible:5810com.android.server.wm.EnsureActivitiesVisibleHelper.setActivityVisibilityState:240com.android.server.wm.EnsureActivitiesVisibleHelper.process:153 
Callers=com.android.server.wm.ActivityTaskSupervisor.scheduleProcessStoppingAndFinishingActivitiesIfNeeded:2175com.android.server.wm.ActivityRecord.onAnimationFinished:7473com.android.server.wm.WindowContainer$$ExternalSyntheticLambda4.onAnimationFinished:2com.android.server.wm.SurfaceAnimator.lambda$getFinishedCallback$0$com-android-server-wm-SurfaceAnimator:133 
Callers=com.android.server.wm.ActivityTaskSupervisor.scheduleProcessStoppingAndFinishingActivitiesIfNeeded:2175com.android.server.wm.ActivityRecord.onWindowsVisible:6532com.android.server.wm.ActivityRecord.updateReportedVisibilityLocked:6633com.android.server.wm.WindowManagerService$4.onAppTransitionFinishedLocked:1154 

4 “IDLE_NOW_MSG”的处理 ActivityTaskSupervisor – activityIdleFromMessage

消息的执行也在 ActivityTaskSupervisor 类。

# ActivityTaskSupervisorprivate final class ActivityTaskSupervisorHandler extends Handler {@Overridepublic void handleMessage(Message msg) {synchronized (mService.mGlobalLock) {// 处理消息if (handleMessageInner(msg)) {return;}}......}private boolean handleMessageInner(Message msg) {......case IDLE_NOW_MSG: {if (DEBUG_IDLE) Slog.d(TAG_IDLE, "handleMessage: IDLE_NOW_MSG: r=" + msg.obj);// 打印activityIdleFromMessage((ActivityRecord) msg.obj, false /* fromTimeout */);} break;......}}

处理消息的时候也有log打印,“msg.obj” 为null。

继续看处理的代码

# ActivityTaskSupervisorprivate void activityIdleFromMessage(ActivityRecord idleActivity, boolean fromTimeout) {activityIdleInternal(idleActivity, fromTimeout,fromTimeout /* processPausingActivities */, null /* config */);}void activityIdleInternal(ActivityRecord r, boolean fromTimeout,boolean processPausingActivities, Configuration config) {// 重点* 1 logif (DEBUG_ALL) Slog.v(TAG, "Activity idle: " + r);// 重点* 2. ActivityRecord 不为null才执行内部逻辑if (r != null) {// 重点* 3. logif (DEBUG_IDLE) Slog.d(TAG_IDLE, "activityIdleInternal: Callers="+ Debug.getCallers(4));......}......// Atomically retrieve all of the other things to do. 原子检索所有其他要做的事情// 重点* 4. 看方法名是处理 停止和finish的Activity辑在这里processStoppingAndFinishingActivities(r, processPausingActivities, "idle");if (DEBUG_IDLE) {// 重点* 5. log Slogf.i(TAG, "activityIdleInternal(): r=%s, mStartingUsers=%s", r, mStartingUsers);}......}

这里有5个重点,其中1,3,5都是log,很少会将log标记为重点,当前这么做是因为这个方法会执行两次,需要通过这3个log来区分

现在是分析第一次执行,根据前面的分析参数 r 是null,所以执行 processStoppingAndFinishingActivities 方法。

log中搜索"Activity idle: "可以有以下2次打印

Line 5664: 04-01 20:50:30.411  8585  8751 V ActivityTaskManager: Activity idle: null
Line 19079: 04-01 20:50:31.171  8585  9527 V ActivityTaskManager: Activity idle: ActivityRecord{95d53d7 u0 com.google.android.dialer/.extensions.GoogleDialtactsActivity} t26}

2次打印的行数和时间有很大的差距,说明不是一个时机执行的,当前分析的是第一次执行,是由 SourceActivity 执行 activityPaused 的时候会触发 addToStopping 流程。这一次参数 r 为null。

第二次打印的 r 为 TargetActivity 具体执行流程下面会分析。

4.1 processStoppingAndFinishingActivities 逻辑(其实啥也没干)

# ActivityTaskSupervisor/*** Processes the activities to be stopped or destroyed. This should be called when the resumed* 处理要停止或销毁的Activity。这应该在resumed时调用* activities are idle or drawn.*/private void processStoppingAndFinishingActivities(ActivityRecord launchedActivity,boolean processPausingActivities, String reason) {// 准备要执行 Stop 的Activity 集合 ArrayList<ActivityRecord> readyToStopActivities = null;// 重点 * 1. 遍历mStoppingActivitiesfor (int i = mStoppingActivities.size() - 1; i >= 0; --i) {// 获取到ActivityRecord (当前分析场景就1个)final ActivityRecord s = mStoppingActivities.get(i);final boolean animating = s.isAnimating(TRANSITION | PARENTS,ANIMATION_TYPE_APP_TRANSITION | ANIMATION_TYPE_RECENTS)|| s.inTransition();// 日志ProtoLog.v(WM_DEBUG_STATES, "Stopping %s: nowVisible=%b animating=%b "+ "finishing=%s", s, s.nowVisible, animating, s.finishing);// 条件满足才执行if (!animating || mService.mShuttingDown) {......// 打印 准备stop的logProtoLog.v(WM_DEBUG_STATES, "Ready to stop: %s", s);if (readyToStopActivities == null) {readyToStopActivities = new ArrayList<>();}// 重点 * 2. 添加进集合readyToStopActivities.add(s);// 从集合中移除mStoppingActivities.remove(i);}}// 重点 * 3. 遍历readyToStopActivitiesfinal int numReadyStops = readyToStopActivities == null ? 0 : readyToStopActivities.size();for (int i = 0; i < numReadyStops; i++) {final ActivityRecord r = readyToStopActivities.get(i);// 检查该ActivityRecord对象是否在历史记录中。  if (r.isInHistory()) {// 如果该ActivityRecord对象正在结束(可能是用户或系统触发的结束操作)。if (r.finishing) {// TODO(b/137329632): Wait for idle of the right activity, not just any.r.destroyIfPossible(reason);} else {// 重点* 4. 如果ActivityRecord对象不在结束状态,则尝试停止它r.stopIfPossible();}}}......}

这个方法的逻辑还是很重要的,不过当前这一次执行进来,因为条件不满足,其实相当于啥也没干。

    1. 这里遍历的集合,在 ActivityRecord::addToStopping 方法中看到对其赋值
    1. 满足条件的会被添加进 readyToStopActivities 集合, 进入if的条件刚好log也有打印
V WindowManager: Stopping ActivityRecord{f40797d u0 com.android.launcher3/.uioverrides.QuickstepLauncher} t20}: nowVisible=true animating=true finishing=false  mShuttingDown=false

animating 和 mShuttingDown 都不满足条件,所以不会进入。自如也不会有下面的"Ready to stop:"的打印,因为这里没进入执行 readyToStopActivities 集合没有元素,所以重点3也不会执行。

但是第二次执行 ActivityTaskSupervisor::activityIdleInternal 方法的时候的日志会有后续的打印,也就是说会执行到 ActivityRecord::stopIfPossible ,第二次的log如下

04-01 20:50:31.182  8585  9527 V WindowManager: Stopping ActivityRecord{f40797d u0 com.android.launcher3/.uioverrides.QuickstepLauncher} t20}: nowVisible=false animating=false finishing=false  mShuttingDown=false
04-01 20:50:31.182  8585  9527 V WindowManager: Ready to stop: ActivityRecord{f40797d u0 com.android.launcher3/.uioverrides.QuickstepLauncher} t20}

第二次相关的逻辑有个印象几个,后面会再分析

5 小结

在正确冷启动流程的开始 SourceActivity 执行 activityPaused 的时候会触发 addToStopping 流程,这个流程会执行到 ActivityTaskSupervisor:: processStoppingAndFinishingActivities 方法,但是由于条件不满足,在这个方法中不会有什么实质性的处理。(后续还有会流程第二次触发该方法)

因此 addToStopping 流程最重要的事就是将 SourceActivity 添加到了 ActivityTaskSupervisor 类下的 mStoppingActivities 集合中。等后面条件满足再触发 ActivityTaskSupervisor:: processStoppingAndFinishingActivities 方法时就会执行 ActivityRecord::stopIfPossible 流程了。

“wm_add_to_stopping” 日志的线索跟到这里就结束了,后面的流程还有2个线索

    1. 第二个和 stop 有关的events 日志为 “wm_stop_activity” 并且已知在 “wm_on_resume_called”后打印
    1. ActivityTaskSupervisor::activityIdleInternal 的第二次执行,并且第二次执行到 ActivityTaskSupervisor::processStoppingAndFinishingActivities 方法会触发后续逻辑创建 Stop 的事务。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/web/54427.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【2024】前端学习笔记11-网页布局-弹性布局flex

学习笔记 网页布局弹性布局&#xff1a;flex案例&#xff1a;flex布局案例 网页布局 在页面布局中&#xff0c;display属性用于设置一个元素的显示方式。它可以指定元素是作为块级元素、内联元素还是充当表格元素显示。 display的常见属性值&#xff1a; block&#xff1a;将…

解决方案:机器学习中,出现欠拟合和过拟合,这两种情况分别如何解决

文章目录 一、现象二、解决方案欠拟合&#xff08;Underfitting&#xff09;过拟合&#xff08;Overfitting&#xff09; 一、现象 在工作中&#xff0c;在机器学习中&#xff0c;出现欠拟合和过拟合的时候&#xff0c;需要有对应的解决方法&#xff0c;所以整理一下 二、解决…

k8s 中微服务之 MetailLB 搭配 ingress-nginx 实现七层负载

目录 1 MetailLB 搭建 1.1 MetalLB 的作用和原理 1.2 MetalLB功能 1.3 部署 MetalLB 1.3.1 创建deployment控制器和创建一个服务 1.3.2 下载MealLB清单文件 1.3.3 使用 docker 对镜像进行拉取 1.3.4 将镜像上传至私人仓库 1.3.5 将官方仓库地址修改为本地私人地址 1.3.6 运行清…

驱动中的device和device_driver结构体

device和device driver是Linux驱动开发的基本概念。Linux kernel的思路很简单&#xff1a;驱动开发&#xff0c;就是要开发指定的软件&#xff08;driver&#xff09;以驱动指定的设备&#xff0c;所以kernel就为设备和驱动它的driver定义了两个数据结构&#xff0c;分别是devi…

ensp回顾--聚合链路技术简介与详细案例(构建基于交换机到交换机的聚合链路)

文章目录 什么是聚合链路&#xff1f;聚合链路的工作原理聚合链路的优势使用场景 案例ensp版本图例pc的ip地址具体步骤连通性测试 在现代网络中&#xff0c;聚合链路&#xff08;Link Aggregation&#xff09;是一种常见的技术&#xff0c;用于提高网络连接的带宽和可靠性。本文…

RNN经典案例——构建人名分类器

RNN经典案例——人名分类器 一、数据处理1.1 去掉语言中的重音标记1.2 读取数据1.3 构建人名类别与人名对应关系字典1.4 将人名转换为对应的onehot张量 二、构建RNN模型2.1 构建传统RNN模型2.2 构建LSTM模型2.3 构建GRU模型 三、构建训练函数并进行训练3.1 从输出结果中获得指定…

【可答疑】基于51单片机的智能台灯(含仿真、代码、报告、演示视频等)

✨哈喽大家好&#xff0c;这里是每天一杯冰美式oh&#xff0c;985电子本硕&#xff0c;大厂嵌入式在职0.3年&#xff0c;业余时间做做单片机小项目&#xff0c;有需要也可以提供就业指导&#xff08;免费&#xff09;~ &#x1f431;‍&#x1f409;这是51单片机毕业设计100篇…

2025秋招LLM大模型多模态面试题(九)-- LoRA 面试问题大全:从理论到实践

随着深度学习模型的不断发展,微调大模型的需求也逐渐增多。然而,传统的全参数微调需要消耗大量的计算资源和显存,对于普通用户和中小企业来说负担较大。为了应对这些问题,LoRA(Low-Rank Adaptation)应运而生。LoRA 是一种高效微调技术,通过低秩分解的方式显著减少训练参…

单目三d重建学习笔记2024

从单目视频生成动态多物体场景 已经开源&#xff1a; https://github.com/dreamscene4d/dreamscene4d 2021年&#xff1a; 浙大团队研发NeuralRecon&#xff0c;首个基于学习的实时单目三维重建系统 https://github.com/zju3dv/NeuralRecon https://github.com/zju3dv/Neura…

数据分析-28-交互式数据分析EDA工具和低代码数据科学工具

文章目录 1 数据分析的七步指南1.1 第一步:问题定义和数据采集1.2 第二步:数据清洗和预处理1.3 第三步:数据探索和分析1.4 第四步:模型建立和分析1.5 第五步:数据可视化1.6 第六步:结果解释和报告1.7 第七步:部署和维护1.8 基础的数据分析库1.9 低代码数据科学工具2 EDA…

Flutter InAppWebView 路由导航处理

flutter InAppWebView路由导航处理&#xff0c;有以下两种处理方案&#xff1a; H5层控制路由&#xff0c;H5拥有自己的路由&#xff0c;当返回到跟路由root时&#xff0c;此时点击跟节点&#xff0c;通过jsbridge调用flutter提供的方法来关闭当前widget&#xff0c;flutter关…

改变数组页面重新渲染的操作/那些操作不会重新渲染页面以及解决方法

在前端开发中&#xff0c;当数组数据发生变化时&#xff0c;是否会导致页面重新渲染&#xff0c;以及如何进行相关操作&#xff0c;这取决于使用的具体框架或库&#xff08;如React、Vue等&#xff09;及其内部机制。以下是对这一问题的详细解答&#xff1a; 一、会导致页面重…

STM32 通用定时器

一、概述 STM32内部集成了多个定时/计数器&#xff0c;根据型号不同&#xff0c;STM32系列芯片最多包含8个定时/计数器。其中&#xff0c;TIM6、TIM7为基本定时器&#xff0c;TIM2~TIM5为通用定时器&#xff0c;TIM1、TIM8为高级控制定时器。 1.定时器的类型 基本定时器通用定…

实战案例:结合大模型与爬虫技术实现12306智能查票系统

大语言模型&#xff0c;例如 GPT-4&#xff0c;拥有强大的知识储备和语言理解能力&#xff0c;能够进行流畅的对话、创作精彩的故事&#xff0c;甚至编写代码。然而&#xff0c;它们也面临着一些难以克服的困境&#xff0c;就像一个空有知识却无法行动的巨人 信息滞后&#xf…

Linux 之 安装软件、GCC编译器、Linux 操作系统基础

安装软件、GCC编译器、Linux 操作系统基础 学习任务&#xff1a; 安装 Vmware虚拟机、掌握Ubuntu 系统的使用认识 Ubuntu 操作系统的终端和 Shell掌握软件安装、文件系统、掌握磁盘管理与解压缩掌握 VIM 编辑器、Makefile 基本语法熟悉 Linux 常见指令操作 安装好开发软件&…

148.排序链表

文章目录 方法1&#xff1a;自顶向下的归并排序方法2 自底向上的归并排序 方法1&#xff1a;自顶向下的归并排序 使用归并排序算法。归并排序是一种分治算法&#xff0c;它将链表分成两半&#xff0c;然后对每一半进行排序&#xff0c;最后将两个有序的链表合并。由于链表不支…

[Go语言快速上手]初识Go语言

目录 一、什么是Go语言 二、第一段Go程序 1、Go语言结构 注意 2、Go基础语法 关键字 运算符优先级 三、Go语言数据类型 示例 小结 一、什么是Go语言 Go语言&#xff0c;通常被称为Golang&#xff0c;是一种静态类型、编译型的计算机编程语言。它由Google的Robert Gr…

用HTML5+CSS+JavaScript庆祝国庆

用HTML5CSSJavaScript庆祝国庆 中华人民共和国的国庆日是每年的10月1日。 1949年10月1日&#xff0c;中华人民共和国中央人民政府成立&#xff0c;在首都北京天安门广场举行了开国大典&#xff0c;中央人民政府主席毛泽东庄严宣告中华人民共和国成立&#xff0c;并亲手升起了…

Vue3 中Ref的最佳实践

在vue3中如果我们需要获取一个响应式的变量&#xff0c;可以使用ref来定义一个变量。 const name ref( "" );name.value "test" 定义好后&#xff0c;就可以实现修改状态&#xff0c;更新UI的效果了。 在这个基础上&#xff0c;本文主要讨论跨组件时如何…

Discord:报错:A fatal Javascript error occured(解决办法)

按 Windows 键 R 并输入 %appdata% 选择 discord 文件夹并将其删除。 再次按 Windows 键 R 并输入 %LocalAppData% 选择 discord 文件夹并再次将其删除。 附加&#xff1a; 如果还不行&#xff0c;就通过官网下载吧&#xff0c;这个问题通过epic下载可能会有