秉心说 TM | 作者

承香墨影 | 校对

https://juejin.cn/post/6898588053451833351 | 原文

Hi，大家好，这里是承香墨影！

Activity 作为 Android 四大组件，生命周期自有 Framework 维护，我们只需要依据其生命周期回调方法，在不同的生命周期做不同的业务处理。

通常，我们认为在 finish() 之后，Activity 就会回调 onDestory() 并销毁，我们会在 Activity 的 onDestroy() 做资源的释放与解注册，避免造成内存和资源的泄露。

那么 finish() 之后，onDestory() 是立即被回调的吗？有没有可能存在阻塞的情况，导致 onDestory() 被延迟回调了？如果被阻塞，系统有兜底策略吗？这其中的原理是什么？

今天给大家推荐的来自 @秉心说 TM 的文章，从源码的角度分析 finish() 与 onDestory() 的关系，希望对大家有所帮助。

交流群里碰到一个很有意思的问题，调用 Activity.finish() 之后 10s 才回调 onDestroy()。

由此产生了一些不可控问题，例如在 onDestroy() 中释放资源不及时，赋值状态异常等等。我之前倒没有遇到过类似的问题，但是 AOSP 总是我们最好的老师。从 Activity.finish() 开始撸了一遍流程，找到了问题的答案。

在读源码之前，我们先来复现一下 10s onDestroy() 的场景。写一个最简单的 FirstActivity 跳转到 SecondActivity 的场景，并记录下各个生命周期和调用 finish() 的时间间隔。

SecondActivity 是一个普通的没有进行任何操作的空白 Activity 。点击按钮跳转到 SecondActivity，打印日志如下：

可以看到正常情况下，FirstActivity 回调 onPause() 之后，SecondActivity 开始正常的生命周期流程，直到 onResume() 被回调，对用户可见时，FirstActivity 才会回调 onPause() 和 onDestroy()。时间间隔也都在正常范围以内。

我们再模拟一个在 SecondActivity 启动时，进行大量动画的场景，源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。

再来看一下日志：

FirstActivity 的 onPause() 没有受到影响。因为在 Activity 跳转过程中，目标 Activity 只有在前一个 Activity onPause() 之后才会开始正常的生命周期。而 onStop() 和 onDestroy() 整整过了 10s 才回调。

对比以上两个场景，我们可以猜测，当 SecondActivity 的主线程过于繁忙，没有机会停下来喘口气的时候，会造成 FirstActivity 无法及时回调 onStop() 和 onDestroy()。基于以上猜测，我们就可以从 AOSP 中来寻找答案了。

接下来就是大段的枯燥的源码分析了。带着问题去读 AOSP，可以让这个过程不是那么"枯燥"，而且一定会有很多不一样的收获。

以下源代码基于 Android 9.0 版本。

重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY，含义也很直白，不会销毁 Activity 所在的任务栈。

这里的 mParent 大多数情况下都是 null ，不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解 ActivityGroup，在此种情况下 mParent 可能会不为 null。（因为我还年轻，所以没有使用过 ActivityGroup，就不过多解释了）其中 Binder 调用了 AMS.finishActivity() 方法。

注意方法参数中的 token 对象，Token 是 ActivityRecord 的静态内部类，它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub，是一个 Binder 对象。ActivityRecord 就是对当前 Activity 的具体描述，包含了 Activity 的所有信息。

传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY，所以接着会调用 ActivityStack.requestFinishActivityLocked() 方法。

最后调用的是一个重载的 finishActivityLocked() 方法。

调用 finish() 之后，肯定是要先 pause() 当前 Activity，没毛病。接着看 startPausingLocked() 方法。

这里面有两步重点操作。第一步是注释 1 处通过 ClientLifecycleManager 分发生命周期流程。第二步是发送一个延时 500ms 的消息，等待一下 onPause() 流程。但是如果第一步中在 500ms 内已经完成了流程，则会取消这个消息。所以这两步的最终逻辑其实是一致的。

这里就直接看第一步。

ClientLifecycleManager 会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件，调用 XXXActivityItem 的 execute() 和 postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的 handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法，其中会通过 Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause()。

到这里，onPause() 方法就被执行了。但是流程没有结束，接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItem 的 execute() 和 postExecute() 方法。execute() 方法回调了当前 Activity.onPause()，而 postExecute() 方法就是去寻找要显示的 Activity 。

Binder 调用了 AMS.activityPaused() 方法。

调用了 ActivityStack.activityPausedLocked() 方法。

上面有这么一行代码 mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r)，移除的就是之前延迟 500ms 的消息。接着看 completePauseLocked() 方法。

这里分了两步走。

注释 1 处判断了 finishing 状态，还记得 finishing 在何处被赋值为 true 的吗？

在 Activity.finish() -> AMS.finishActivity() -> ActivityStack.requestFinishActivityLocked() -> ActivityStack.finishActivityLocked() 方法中。所以接着调用的是 finishCurrentActivityLocked() 方法。注释 2 处就是来显示应该显示的 Activity ，就不再追进去细看了。

再跟到 finishCurrentActivityLocked() 方法中，看这名字，肯定是要 stop/destroy 没跑了。

注释 1 处 mode 的值是 FINISH_AFTER_VISIBLE ，并且现在新的 Activity 还没有 onResume()，所以 r.visible || r.nowVisible 和 next != null && !next.nowVisible 都是成立的，并不会进入后面的 destroy() 流程。虽然看到这还没得到想要的答案，但是起码是符合预期的。如果在这就直接 destroy() 了，延迟 10s 才 onDestroy() 的问题就无疾而终了。

对于这些暂时还不销毁的 Activity 都执行了 addToStopping(r, false, false) 方法。我们继续追进去。

这些在等待销毁的 Activity 被保存在了 ActivityStackSupervisor 的 mStoppingActivities 集合中，它是一个 ArrayList。

整个 finish() 流程就到此为止了。前一个 Activity 被保存在了 ActivityStackSupervisor.mStoppingActivities 集合中，新的 Activity 被显示出来了。

问题似乎进入了困境，什么时候回调 onStop/onDestroy 呢？

其实这个才是根本问题。上面撸了一遍 finish() 并看不到本质，但是可以帮助我们形成一个完整的流程，这个一直是看 AOSP 最大的意义，帮助我们把零碎的上层知识形成一个完整的闭环。

回到正题来，在 Activity 跳转过程中，为了保证流畅的用户体验，只要前一个 Activity 与用户不可交互，即 onPause() 被回调之后，下一个 Activity 就要开始自己的生命周期流程了。

所以 onStop/onDestroy 的调用时间是不确定的，甚至像文章开头的例子中，整整过了 10s 才回调。那么，到底是由谁来驱动 onStop/onDestroy 的执行呢？我们来看看下一个 Activity 的 onResume() 过程。

直接看 ActivityThread.handleResumeActivity() 方法，相信大家对生命周期的调用流程也很熟悉了。

handleResumeActivity() 方法是整个 UI 显示流程的重中之重，它首先会回调 Activity.onResume() , 然后将 DecorView 添加到 Window 上，其中又包括了创建 ViewRootImpl，创建 Choreographer，与 WMS 进行 Binder 通信，注册 vsync 信号，著名的 measure/draw/layout。这一块的源码真的很值得一读，不过不是这篇文章的重点，后面会单独来捋一捋。

在完成最终的界面绘制和显示之后，有这么一句代码 Looper.myQueue().addIdleHandler(new Idler())。

IdleHandler 不知道大家是否熟悉，它提供了一种机制，当主线程消息队列空闲时，会执行 IdleHandler 的回调方法。至于怎么算 "空闲"，我们可以看一下 MessageQueue.next() 方法。

IDLE_TIMEOUT 的值是 10，这里延迟 10s 发送了一个消息。这个消息是在 ActivityStackSupervisorHandler 中处理的。

忘记 activityIdleInternalLocked() 方法的话可以 ctrl+F 向上搜索一下。如果 10s 内主线程执行了 Idler 的话，就会移除这个消息。

到这里，所有的问题就全部理清了。

Activity 的 onStop/onDestroy 是依赖 IdleHandler 来回调的，正常情况下当主线程空闲时会调用。但是由于某些特殊场景下的问题，导致主线程迟迟无法空闲，onStop/onDestroy 也会迟迟得不到调用。但这并不意味着 Activity 永远得不到回收，系统提供了一个兜底机制，当 onResume() 回调 10s 之后，如果仍然没有得到调用，会主动触发。

虽然有兜底机制，但无论如何这肯定不是我们想看到的。如果我们项目中的 onStop/onDestroy 延迟了 10s 调用，该如何排查问题呢？可以利用 Looper.getMainLooper().setMessageLogging() 方法，打印出主线程消息队列中的消息。每处理一条消息，都会打印如下内容：