这是我参与11月更文挑战的第3天，活动详情查看：2021最后一次更文挑战
在一次项目开发中，遇到一个诡异的问题，我在执行完Activity的finish()方法后，在onDestroy()中做了一些业务逻辑的处理，然后被上一个Activity的生命周期中的某个业务给阻止了，后来找了好久，结果通过deBug方法才看到，居然finish（）之后先执行的上一个Activity的生命周期，然后又重新执行了被finish()的Activity的onDestroy()方法，当时蒙了个逼，这是啥造型啊，挺别致啊。。。后来就研究了一下，为什么finish()后没有及时回调onDestroy()方法以及相关的一下底层逻辑，下面就这些疑问，做出问题的答案。
没有及时回调的 onStop/onDestroy
调用 Activity.finish() 之后 10s 才回调 onDestroy() 。
在看源码之前，复现一下10s onDestroy()的场景，写一个最简单的 FirstActivity 跳转到 SecondActivity
的场景，并记录下各个生命周期和调用 finish() 的时间间隔。
class FirstActivity : BaseLifecycleActivity() {
private val binding by lazy { ActivityFirstBinding.inflate(layoutInflater) }
var startTime = 0L
override fun onCreate(savedInstanceState: Bundle?)
super.onCreate(savedInstanceState)
setContentView(binding.root)
binding.goToSecond.setOnClickListener {
start<SecondActivity>()
finish()
startTime = System.currentTimeMillis()
}
}
override fun onPause() {
super.onPause()
Log.e("finish","onPause() 距离 finish() ：${System.currentTimeMillis() - startTime} ms")
}
override fun onStop() {
super.onStop()
Log.e("finish","onStop() 距离 finish() ：${System.currentTimeMillis() - startTime} ms")
}
override fun onDestroy() {
super.onDestroy()
Log.e("finish","onDestroy() 距离 finish() ：${System.currentTimeMillis() - startTime} ms")
}
}
SecondActivity 是一个普通的没有进行任何操作的空白 Activity 。点击按钮跳转到 SecondActivity，打印日志如下：
1FirstActivity: onPause，onPause() 距离 finish() ：5 ms
2SecondActivity: onCreate
3SecondActivity: onStart
4SecondActivity: onResume
5FirstActivity: onStop，onStop() 距离 finish() ：660 ms
6FirstActivity: onDestroy，onDestroy() 距离 finish() ：663 ms
可以看到正常情况下，FirstActivity 回调 onPause 之后，SecondActivity 开始正常的生命周期流程，直到 onResume 被回调，对用户可见时，FirstActivity 才会回调 onPause 和 onDestroy 。时间间隔也都在正常范围以内。
我们再模拟一个在 SecondActivity 启动时进行大量动画的场景，源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。
1class SecondActivity : BaseLifecycleActivity() {
2
3 private val binding by lazy { ActivitySecondBinding.inflate(layoutInflater) }
4
5 override fun onCreate(savedInstanceState: Bundle?) {
6 super.onCreate(savedInstanceState)
7 setContentView(binding.root)
8
9 postMessage()
10 }
11
12 private fun postMessage() {
13 binding.secondBt.post {
14 Thread.sleep(10)
15 postMessage()
16 }
17 }
18}
再来看一下日志：
1FirstActivity: onPause, onPause() 距离 finish() ：6 ms
2SecondActivity: onCreate
3SecondActivity: onStart
4SecondActivity: onResume
5FirstActivity: onStop, onStop() 距离 finish() ：10033 ms
6FirstActivity: onDestroy, onDestroy() 距离 finish() ：10037 ms
FirstActivity 的 onPause() 没有受到影响。因为在 Activity 跳转过程中，目标 Activity 只有在前一个
Activity onPause() 之后才会开始正常的生命周期。而 onStop 和 onDestroy() 整整过了 10s
才回调。
对比以上两个场景，我们可以猜测，当 SecondActivity 的主线程过于繁忙，没有机会停下来喘口气的时候，会造成 FirstActivity
无法及时回调 onStop 和 onDestroy 。基于以上猜测，我们就可以从 AOSP 中来寻找答案了。
接下来就是大段的枯燥的源码分析了。带着问题去读 AOSP，可以让这个过程不是那么 “枯燥”，而且一定会有很多不一样的收获。
从 Activity.finish() 说起
以下源代码基于 Android 9.0 版本。
1> Activity.java
2
3 public void finish() {
4 finish(DONT_FINISH_TASK_WITH_ACTIVITY);
5}
重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY ，含义也很直白，不会销毁 Activity
所在的任务栈。
1> Activity.java
2
3 private void finish(int finishTask) {
4 // mParent 一般为 null，在 ActivityGroup 中会使用到
5 if (mParent == null) {
6 ......
7 try {
8 // Binder 调用 AMS.finishActivity()
9 if (ActivityManager.getService()
10 .finishActivity(mToken, resultCode, resultData, finishTask)) {
11 mFinished = true;
12 }
13 } catch (RemoteException e) {
14 }
15 } else {
16 mParent.finishFromChild(this);
17 }
18 ......
19}
这里的 mParent 大多数情况下都是 null ，不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解
ActivityGroup，在此种情况下 mParent 可能会不为 null。（因为我还年轻，所以没有使用过
ActivityGroup，就不过多解释了。）其中 Binder 调用了 AMS.finishActivity() 方法。
1> ActivityManagerService.java
2
3 public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,
4 int finishTask) {
5 ......
6 synchronized(this) {
7 // token 持有 ActivityRecord 的弱引用
8 ActivityRecord r = ActivityRecord.isInStackLocked(token);
9 if (r == null) {
10 return true;
11 }
12 ......
13 try {
14 boolean res;
15 final boolean finishWithRootActivity =
16 finishTask == Activity.FINISH_TASK_WITH_ROOT_ACTIVITY;
17 // finishTask 参数是 DONT_FINISH_TASK_WITH_ACTIVITY，进入 else 分支
18 if (finishTask == Activity.FINISH_TASK_WITH_ACTIVITY
19 || (finishWithRootActivity && r == rootR)) {
20 res = mStackSupervisor.removeTaskByIdLocked(tr.taskId, false,
21 finishWithRootActivity, "finish-activity");
22 } else {
23 // 调用 ActivityStack.requestFinishActivityLocked()
24 res = tr.getStack().requestFinishActivityLocked(token, resultCode,
25 resultData, "app-request", true);
26 }
27 return res;
28 } finally {
29 Binder.restoreCallingIdentity(origId);
30 }
31 }
32}
注意方法参数中的 token 对象，Token 是 ActivityRecord
的静态内部类，它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub ，是一个 Binder
对象。ActivityRecord 就是对当前 Activity 的具体描述，包含了 Activity 的所有信息。
传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY，所以接着会调用
ActivityStack.requestFinishActivityLocked() 方法。
1> ActivityStack.java
2
3 final boolean requestFinishActivityLocked(IBinder token, int resultCode,
4 Intent resultData, String reason, boolean oomAdj) {
5 ActivityRecord r = isInStackLocked(token);
6 if (r == null) {
7 return false;
8 }
9
10 finishActivityLocked(r, resultCode, resultData, reason, oomAdj);
11 return true;
12}
13
14 final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,
15 String reason, boolean oomAdj) {
16 // PAUSE_IMMEDIATELY 为 true，在 ActivityStackSupervisor 中定义
17 return finishActivityLocked(r, resultCode, resultData, reason, oomAdj, !PAUSE_IMMEDIATELY);
18}
最后调用的是一个重载的 finishActivityLocked() 方法。
1> ActivityStack.java
2
3 // 参数 pauseImmediately 是 false
4 final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,
5 String reason, boolean oomAdj, boolean pauseImmediately) {
6 if (r.finishing) { // 重复 finish 的情况
7 return false;
8 }
9
10 mWindowManager.deferSurfaceLayout();
11 try {
12 // 标记 r.finishing = true，
13 // 前面会做重复 finish 的检测就是依赖这个值
14 r.makeFinishingLocked();
15 final TaskRecord task = r.getTask();
16 ......
17 // 暂停事件分发
18 r.pauseKeyDispatchingLocked();
19
20 adjustFocusedActivityStack(r, "finishActivity");
21
22 // 处理 activity result
23 finishActivityResultsLocked(r, resultCode, resultData);
24
25 // mResumedActivity 就是当前 Activity，会进入此分支
26 if (mResumedActivity == r) {
27 ......
28 // Tell window manager to prepare for this one to be removed.
29 r.setVisibility(false);
30
31 if (mPausingActivity == null) {
32 // 开始 pause mResumedActivity
33 startPausingLocked(false, false, null, pauseImmediately);\
34 }
35 ......
36 } else if (!r.isState(PAUSING)) {
37 // 不会进入此分支
38 ......
39 }
40 return false;
41 } finally {
42 mWindowManager.continueSurfaceLayout();
43 }
44}
调用 finish 之后肯定是要先 pause 当前 Activity，没毛病。接着看 startPausingLocked() 方法。
1> ActivityStack.java
2
3 final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
4 ActivityRecord resuming, boolean pauseImmediately) {
5 ......
6 ActivityRecord prev = mResumedActivity;
7
8 if (prev == null) {
9 // 没有 onResume 的 Activity，不能执行 pause
10 if (resuming == null) {
11 mStackSupervisor.resumeFocusedStackTopActivityLocked();
12 }
13 return false;
14 }
15 ......
16
17 mPausingActivity = prev;
18 // 设置当前 Activity 状态为 PAUSING
19 prev.setState(PAUSING, "startPausingLocked");
20 ......
21
22 if (prev.app != null && prev.app.thread != null) {
23 try {
24 ......
25 // 1. 通过 ClientLifecycleManager 分发生命周期事件
26 // 最终会向 H 发送 EXECUTE_TRANSACTION 事件
27 mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
28 PauseActivityItem.obtain(prev.finishing, userLeaving,
29 prev.configChangeFlags, pauseImmediately));
30 } catch (Exception e) {
31 mPausingActivity = null;
32 }
33 } else {
34 mPausingActivity = null;
35 }
36 ......
37 // mPausingActivity 在前面已经赋值，就是当前 Activity
38 if (mPausingActivity != null) {
39 ......
40 if (pauseImmediately) { // 这里是 false，进入 else 分支
41 completePauseLocked(false, resuming);
42 return false;
43 } else {
44 // 2. 发送一个延时 500ms 的消息，等待 pause 流程一点时间
45 // 最终会回调 activityPausedLocked() 方法
46 schedulePauseTimeout(prev);
47 return true;
48 }
49 } else {
50 // 不会进入此分支
51 }
52 }
这里面有两步重点操作。第一步是注释 1 处通过 ClientLifecycleManager 分发生命周期流程。第二步是发送一个延时 500ms 的消息，等待一下 onPause 流程。但是如果第一步中在 500ms 内已经完成了流程，则会取消这个消息。所以这两步的最终逻辑其实是一致的。这里就直接看第一步。
1 mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
2 PauseActivityItem.obtain(prev.finishing, userLeaving,
3 prev.configChangeFlags, pauseImmediately));
ClientLifecycleManager 它会向主线程的 Handler H
发送 EXECUTE_TRANSACTION 事件，调用 XXXActivityItem 的 execute() 和
postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的
handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法，其中会通过
Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause() 。
1> Instrumentation.java
2
3public void callActivityOnPause(Activity activity) {
4 activity.performPause();
5}
到这里，onPause() 方法就被执行了。但是流程没有结束，接着就该显示下一个 Activity 了。前面刚刚说过会调用
PauseActivityItem 的 execute() 和 postExecute() 方法。execute() 方法回调了当前
Activity.onPause()，而 postExecute() 方法就是去寻找要显示的 Activity 。
1> PauseActivityItem.java
2
3public void postExecute(ClientTransactionHandler client, IBinder token,
4 PendingTransactionActions pendingActions) {
5 try {
6 ActivityManager.getService().activityPaused(token);
7 } catch (RemoteException ex) {
8 throw ex.rethrowFromSystemServer();
9 }
10}
Binder 调用了 AMS.activityPaused() 方法。
1> ActivityManagerService.java
2
3public final void activityPaused(IBinder token) {
4 synchronized(this) {
5 ActivityStack stack = ActivityRecord.getStackLocked(token);
6 if (stack != null) {
7 stack.activityPausedLocked(token, false);
8 }
9 }
10}
调用了 ActivityStack.activityPausedLocked() 方法。
1> ActivityStack.java
2
3final void activityPausedLocked(IBinder token, boolean timeout) {
4 final ActivityRecord r = isInStackLocked(token);
5 if (r != null) {
6 // 看这里
7 mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
8 if (mPausingActivity == r) {
9 mService.mWindowManager.deferSurfaceLayout();
10 try {
11 // 看这里
12 completePauseLocked(true /* resumeNext */, null /* resumingActivity */);
13 } finally {
14 mService.mWindowManager.continueSurfaceLayout();
15 }
16 return;
17 } else {
18 // 不会进入 else 分支
19 }
20 }
21}
上面有这么一行代码 mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r) ，移除的就是之前延迟 500ms
的消息。接着看 completePauseLocked() 方法。
1> ActivityStack.java
2
3private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
4 ActivityRecord prev = mPausingActivity;
5
6 if (prev != null) {
7 // 设置状态为 PAUSED
8 prev.setState(PAUSED, "completePausedLocked");
9 if (prev.finishing) { // 1. finishing 为 true，进入此分支
10 prev = finishCurrentActivityLocked(prev, FINISH_AFTER_VISIBLE, false,
11 "completedPausedLocked");
12 } else if (prev.app != null) {
13 // 不会进入此分支
14 } else {
15 prev = null;
16 }
17 ......
18 }
19
20 if (resumeNext) {
21 // 当前获取焦点的 ActivityStack
22 final ActivityStack topStack = mStackSupervisor.getFocusedStack();
23 if (!topStack.shouldSleepOrShutDownActivities()) {
24 // 2. 恢复要显示的 activity
25 mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
26 } else {
27 checkReadyForSleep();
28 ActivityRecord top = topStack.topRunningActivityLocked();
29 if (top == null || (prev != null && top != prev)) {
30 mStackSupervisor.resumeFocusedStackTopActivityLocked();
31 }
32 }
33 }
34 ......
35}
里分了两步走。注释1 处判断了 finishing 状态，还记得 finishing 在何处被赋值为 true 的吗？在
Activity.finish() -> AMS.finishActivity() -> ActivityStack.requestFinishActivityLocked() -> ActivityStack.finishActivityLocked() 方法中。所以接着调用的是
finishCurrentActivityLocked() 方法。注释2 处就是来显示应该显示的 Activity ，就不再追进去细看了。
再跟到 finishCurrentActivityLocked() 方法中，看这名字，肯定是要 stop/destroy 没跑了。
1> ActivityStack.java
2
3/*
4 * 把前面带过来的参数标出来
5 * prev, FINISH_AFTER_VISIBLE, false,"completedPausedLocked"
6 */
7final ActivityRecord finishCurrentActivityLocked(ActivityRecord r, int mode, boolean oomAdj,
8 String reason) {
9
10 // 获取将要显示的栈顶 Activity
11 final ActivityRecord next = mStackSupervisor.topRunningActivityLocked(
12 true /* considerKeyguardState */);
13
14 // 1. mode 是 FINISH_AFTER_VISIBLE，进入此分支
15 if (mode == FINISH_AFTER_VISIBLE && (r.visible || r.nowVisible)
16 && next != null && !next.nowVisible) {
17 if (!mStackSupervisor.mStoppingActivities.contains(r)) {
18 // 加入到 mStackSupervisor.mStoppingActivities
19 addToStopping(r, false /* scheduleIdle */, false /* idleDelayed */);
20 }
21 // 设置状态为 STOPPING
22 r.setState(STOPPING, "finishCurrentActivityLocked");
23 return r;
24 }
25
26 ......
27
28 // 下面会执行 destroy，但是代码并不能执行到这里
29 if (mode == FINISH_IMMEDIATELY
30 || (prevState == PAUSED
31 && (mode == FINISH_AFTER_PAUSE || inPinnedWindowingMode()))
32 || finishingActivityInNonFocusedStack
33 || prevState == STOPPING
34 || prevState == STOPPED
35 || prevState == ActivityState.INITIALIZING) {
36 boolean activityRemoved = destroyActivityLocked(r, true, "finish-imm:" + reason);
37 ......
38 return activityRemoved ? null : r;
39 }
40 ......
41}
注释 1 处 mode 的值是 FINISH_AFTER_VISIBLE ，并且现在新的 Activity 还没有 onResume，所以
r.visible || r.nowVisible 和 next != null && !next.nowVisible
都是成立的，并不会进入后面的 destroy 流程。虽然看到这还没得到想要的答案，但是起码是符合预期的。如果在这就直接 destroy 了， 延迟 10s 才 onDestroy 的问题就无疾而终了。
对于这些暂时还不销毁的 Activity 都执行了 addToStopping(r, false, false) 方法。我们继续追进去。
1> ActivityStack.java
2
3void addToStopping(ActivityRecord r, boolean scheduleIdle, boolean idleDelayed) {
4 if (!mStackSupervisor.mStoppingActivities.contains(r)) {
5 mStackSupervisor.mStoppingActivities.add(r);
6 .....
7 }
8 ......
9 // 省略的代码中，对 mStoppingActivities 的存储容量做了限制。超出限制可能会提前出发销毁流程
10}
这些在等待销毁的 Activity 被保存在了 ActivityStackSupervisor 的 mStoppingActivities
集合中，它是一个 ArrayList<ActivityRecord> 。
整个 finish 流程就到此为止了。前一个 Activity 被保存在了
ActivityStackSupervisor.mStoppingActivities 集合中，新的 Activity 被显示出来了。
问题似乎进入了困境，什么时候回调 onStop/onDestroy 呢？其实这个才是根本问题。上面撸了一遍 finish()
并看不到本质，但是可以帮助我们形成一个完整的流程，这个一直是看 AOSP 最大的意义， 帮助我们把零碎的上层知识形成一个完整的闭环。
是谁指挥着 onStop/onDestroy 的调用？
回到正题来，在 Activity 跳转过程中，为了保证流畅的用户体验，只要前一个 Activity 与用户不可交互，即 onPause()
被回调之后，下一个 Activity 就要开始自己的生命周期流程了。所以 onStop/onDestroy
的调用时间是不确定的，甚至像文章开头的例子中，整整过了 10s 才回调。那么，到底是由谁来驱动 onStop/onDestroy
的执行呢？我们来看看下一个 Activity 的 onResume 过程。
直接看 ActivityThread.handleResumeActivity() 方法，相信大家对生命周期的调用流程也很熟悉了。
1> ActivityThread.java
2
3public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
4 String reason) {
5 ......
6 // 回调 onResume
7 final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
8 ......
9 final Activity a = r.activity;
10 ......
11 if (r.window == null && !a.mFinished && willBeVisible) {
12 ......
13 if (a.mVisibleFromClient) {
14 if (!a.mWindowAdded) {
15 a.mWindowAdded = true;
16 // 添加 decorView 到 WindowManager
17 wm.addView(decor, l);
18 } else {
19 a.onWindowAttributesChanged(l);
20 }
21 }
22 } else if (!willBeVisible) {
23 ......
24 }
25 ......
26
27 // 主线程空闲时会执行 Idler
28 Looper.myQueue().addIdleHandler(new Idler());
29}
handleResumeActivity() 方法是整个 UI 显示流程的重中之重，它首先会回调 Activity.onResume() , 然后将
DecorView 添加到 Window 上，其中又包括了创建 ViewRootImpl，创建 Choreographer，与 WMS 进行 Binder
通信，注册 vsync 信号，著名的 measure/draw/layout。这一块的源码真的很值得一读，不过不是这篇文章的重点，后面会单独来捋一捋。
在完成最终的界面绘制和显示之后，有这么一句代码 Looper.myQueue().addIdleHandler(new Idler())
。IdleHandler 不知道大家是否熟悉，它提供了一种机制，当主线程消息队列空闲时，会执行 IdleHandler 的回调方法。至于怎么算
“空闲”，我们可以看一下 MessageQueue.next() 方法。
1> MessageQueue.java
2
3Message next() {
4 ......
5 int pendingIdleHandlerCount = -1;
6 int nextPollTimeoutMillis = 0;
7 for (;;) {
8 // 阻塞方法，主要是通过 native 层的 epoll 监听文件描述符的写入事件来实现的。
9 // 如果 nextPollTimeoutMillis = -1，一直阻塞不会超时。
10 // 如果 nextPollTimeoutMillis = 0，不会阻塞，立即返回。
11 // 如果 nextPollTimeoutMillis > 0，最长阻塞nextPollTimeoutMillis毫秒(超时)，如果期间有程序唤醒会立即返回。
12 nativePollOnce(ptr, nextPollTimeoutMillis);
13 synchronized (this) {
14 Message prevMsg = null;
15 Message msg = mMessages;
16 if (msg != null && msg.target == null) {
17 // msg.target == null表示此消息为消息屏障（通过postSyncBarrier方法发送来的）
18 // 如果发现了一个消息屏障，会循环找出第一个异步消息（如果有异步消息的话），所有同步消息都将忽略（平常发送的一般都是同步消息）
19 do {
20 prevMsg = msg;
21 msg = msg.next;
22 } while (msg != null && !msg.isAsynchronous());
23 }
24 if (msg != null) {
25 if (now < msg.when) {
26 // 消息触发时间未到，设置下一次轮询的超时时间
27 nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
28 } else {
29 // 得到 Message
30 mBlocked = false;
31 if (prevMsg != null) {
32 prevMsg.next = msg.next;
33 } else {
34 mMessages = msg.next;
35 }
36 msg.next = null;
37 msg.markInUse(); // 标记 FLAG_IN_USE
38 return msg;
39 }
40 } else {
41 nextPollTimeoutMillis = -1;
42 }
43 ......
44
45 /*
46 * 两个条件：
47 * 1. pendingIdleHandlerCount = -1
48 * 2. 此次取到的 mMessage 为空或者需要延迟处理
49 */
50 if (pendingIdleHandlerCount < 0
51 && (mMessages == null || now < mMessages.when)) {
52 pendingIdleHandlerCount = mIdleHandlers.size();
53 }
54 if (pendingIdleHandlerCount <= 0) {
55 // 没有 idle handler 需要运行，继续循环
56 mBlocked = true;
57 continue;
58 }
59
60 if (mPendingIdleHandlers == null) {
61 mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
62 }
63 mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
64 }
65
66 // 下一次 next 时，pendingIdleHandlerCount 又会被置为 -1，不会导致死循环
67 for (int i = 0; i < pendingIdleHandlerCount; i++) {
68 final IdleHandler idler = mPendingIdleHandlers[i];
69 mPendingIdleHandlers[i] = null; // release the reference to the handler
70
71 boolean keep = false;
72 try {
73 // 执行 Idler
74 keep = idler.queueIdle();
75 } catch (Throwable t) {
76 Log.wtf(TAG, "IdleHandler threw exception", t);
77 }
78
79 if (!keep) {
80 synchronized (this) {
81 mIdleHandlers.remove(idler);
82 }
83 }
84 }
85
86 // 将 pendingIdleHandlerCount 置零
87 pendingIdleHandlerCount = 0;
88 nextPollTimeoutMillis = 0;
89 }
90}
在正常的消息处理机制之后，额外对 IdleHandler 进行了处理。当本次取到的 Message 为空或者需要延时处理的时候，就会去执行
mIdleHandlers 数组中的 IdleHandler 对象。其中还有一些关于 pendingIdleHandlerCount
的额外逻辑来防止循环处理。
所以，不出意外的话，当新的 Activity 完成页面绘制并显示之后，主线程就可以停下歇一歇，来执行 IdleHandler 了。再回来
handleResumeActivity() 中来，Looper.myQueue().addIdleHandler(new Idler())
，这里的 Idler 是 IdleHandler 的一个具体实现类。
1> ActivityThread.java
2
3private class Idler implements MessageQueue.IdleHandler {
4 @Override
5 public final boolean queueIdle() {
6 ActivityClientRecord a = mNewActivities;
7 ......
8 }
9 if (a != null) {
10 mNewActivities = null;
11 IActivityManager am = ActivityManager.getService();
12 ActivityClientRecord prev;
13 do {
14 if (a.activity != null && !a.activity.mFinished) {
15 try {
16 // 调用 AMS.activityIdle()
17 am.activityIdle(a.token, a.createdConfig, stopProfiling);
18 a.createdConfig = null;
19 } catch (RemoteException ex) {
20 throw ex.rethrowFromSystemServer();
21 }
22 }
23 prev = a;
24 a = a.nextIdle;
25 prev.nextIdle = null;
26 } while (a != null);
27 }
28 ......
29 return false;
30 }
31}
Binder 调用了 AMS.activityIdle() 。
1> ActivityManagerService.java
2
3public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) {
4
5 final long origId = Binder.clearCallingIdentity();
6 synchronized (this) {
7 ActivityStack stack = ActivityRecord.getStackLocked(token);
8 if (stack != null) {
9 ActivityRecord r =
10 mStackSupervisor.activityIdleInternalLocked(token, false /* fromTimeout */,
11 false /* processPausingActivities */, config);
12 ......
13 }
14 }
15}
调用了 ActivityStackSupervisor.activityIdleInternalLocked() 方法。
1> ActivityStackSupervisor.java
2
3final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
4 boolean processPausingActivities, Configuration config) {
5
6 ArrayList<ActivityRecord> finishes = null;
7 ArrayList<UserState> startingUsers = null;
8 int NS = 0;
9 int NF = 0;
10 boolean booting = false;
11 boolean activityRemoved = false;
12
13 ActivityRecord r = ActivityRecord.forTokenLocked(token);
14
15 ......
16 // 获取要 stop 的 Activity
17 final ArrayList<ActivityRecord> stops = processStoppingActivitiesLocked(r,
18 true /* remove */, processPausingActivities);
19 NS = stops != null ? stops.size() : 0;
20 if ((NF = mFinishingActivities.size()) > 0) {
21 finishes = new ArrayList<>(mFinishingActivities);
22 mFinishingActivities.clear();
23 }
24
25 // 该 stop 的 stop
26 for (int i = 0; i < NS; i++) {
27 r = stops.get(i);
28 final ActivityStack stack = r.getStack();
29 if (stack != null) {
30 if (r.finishing) {
31 stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false,
32 "activityIdleInternalLocked");
33 } else {
34 stack.stopActivityLocked(r);
35 }
36 }
37 }
38
39 // 该 destroy 的 destroy
40 for (int i = 0; i < NF; i++) {
41 r = finishes.get(i);
42 final ActivityStack stack = r.getStack();
43 if (stack != null) {
44 activityRemoved |= stack.destroyActivityLocked(r, true, "finish-idle");
45 }
46 }
47 ......
48
49 return r;
50}
stops 和 finishes 分别是要 stop 和 destroy 的两个 ActivityRecord 数组。stops 数组是通过
ActivityStackSuperVisor.processStoppingActivitiesLocked() 方法获取的，追进去看一下。
1> ActivityStackSuperVisor.java
2
3final ArrayList<ActivityRecord> processStoppingActivitiesLocked(ActivityRecord idleActivity,
4 boolean remove, boolean processPausingActivities) {
5 ArrayList<ActivityRecord> stops = null;
6
7 final boolean nowVisible = allResumedActivitiesVisible();
8 // 遍历 mStoppingActivities
9 for (int activityNdx = mStoppingActivities.size() - 1; activityNdx >= 0; --activityNdx) {
10 ActivityRecord s = mStoppingActivities.get(activityNdx);
11 ......
12 }
13 return stops;
14}
中间的详细处理逻辑就不看了，我们只需要关注这里遍历的是 ActivityStackSuperVisor 中的 mStoppingActivities 集合 。在前面分析 finish() 流程到最后的 addToStopping() 方法时提到过，
这些在等待销毁的 Activity 被保存在了ActivityStackSupervisor 的 mStoppingActivities 集合中，它是一个 ArrayList<ActivityRecord> 。
看到这里，终于打通了流程。再回头想一下文章开头的例子，由于人为的在 SecondActivity 不间断的向主线程塞消息，导致 Idler
迟迟无法被执行，onStop/onDestroy 也就不会被回调。
谁让 onStop/onDestroy 延迟了 10s ？
对， 不会被回调。 可实际情况是这样吗？并不是，明明是过了 10s 被回调。这就说明了即使主线程迟迟没有机会执行 Idler，系统仍然提供了兜底机制，防止已经不需要的 Activity 长时间无法被回收，从而造成内存泄漏等问题。从实际现象就可以猜测到，这个兜底机制就是 onResume 之后 10s 主动去进行释放操作。
再回到之前显示待跳转 Activity 的
ActivityStackSuperVisor.resumeFocusedStackTopActivityLocked()
方法。我这里就不带着大家追进去了，直接给出调用链。
ASS.resumeFocusedStackTopActivityLocked() ->
ActivityStack.resumeTopActivityUncheckedLocked() ->
ActivityStack.resumeTopActivityInnerLocked() ->
ActivityRecord.completeResumeLocked() -> ASS.scheduleIdleTimeoutLocked()
1> ActivityStackSuperVisor.java
2
3 void scheduleIdleTimeoutLocked(ActivityRecord next) {
4 Message msg = mHandler.obtainMessage(IDLE_TIMEOUT_MSG, next);
5 mHandler.sendMessageDelayed(msg, IDLE_TIMEOUT);
6}
IDLE_TIMEOUT 的值是 10，这里延迟 10s 发送了一个消息。这个消息是在 ActivityStackSupervisorHandler
中处理的。
1 private final class ActivityStackSupervisorHandler extends Handler {
2......
3 case IDLE_TIMEOUT_MSG: {
4 activityIdleInternal((ActivityRecord) msg.obj, true /* processPausingActivities */);
5 } break;
6......
7}
8
9 void activityIdleInternal(ActivityRecord r, boolean processPausingActivities) {
10 synchronized (mService) {
11 activityIdleInternalLocked(r != null ? r.appToken : null, true /* fromTimeout */,
12 processPausingActivities, null);
13 }
14}
忘记 activityIdleInternalLocked 方法的话可以 ctrl+F 向上搜索一下。如果 10s 内主线程执行了 Idler
的话，就会移除这个消息。
到这里，所有的问题就全部理清了。
最后
Activity 的 onStop/onDestroy 是依赖 IdleHandler 来回调的，正常情况下当主线程空闲时会调用。但是由于某些特殊场景下的问题，导致主线程迟迟无法空闲，onStop/onDestroy 也会迟迟得不到调用。但这并不意味着 Activity 永远得不到回收，系统提供了一个兜底机制，当 onResume 回调 10s 之后，如果仍然没有得到调用，会主动触发。
虽然有兜底机制，但无论如何这肯定不是我们想看到的。如果我们项目中的 onStop/onDestroy 延迟了 10s 调用，该如何排查问题呢？可以利用
Looper.getMainLooper().setMessageLogging()
方法，打印出主线程消息队列中的消息。每处理一条消息，都会打印如下内容：
1logging.println(">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what);
2logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
另外，由于 onStop/onDestroy 调用时机的不确定性，在做资源释放等操作的时候，一定要考虑好，以避免产生资源没有及时释放的情况。
