交流群里碰到一个很有意思的问题，调用 Activity.finish() 之后 10s 才回调 onDestroy() 。 由此产生了一些不可控问题，例如在 onDestroy() 中释放资源不及时，赋值状态异常等等。我之前倒没有遇到过类似的问题，但是 AOSP 总是我们最好的老师。从 Activity.finish() 开始撸了一遍流程，找到了问题的答案。
在读源码之前，我们先来复现一下 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()
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，打印日志如下：
FirstActivity: onPause，onPause() 距离 finish() ：5 ms
SecondActivity: onCreate
SecondActivity: onStart
SecondActivity: onResume
FirstActivity: onStop，onStop() 距离 finish() ：660 ms
FirstActivity: onDestroy，onDestroy() 距离 finish() ：663 ms
可以看到正常情况下，FirstActivity 回调 onPause 之后，SecondActivity 开始正常的生命周期流程，直到 onResume 被回调，对用户可见时，FirstActivity 才会回调 onPause 和 onDestroy 。时间间隔也都在正常范围以内。
我们再模拟一个在 SecondActivity 启动时进行大量动画的场景，源源不断的向主线程消息队列塞消息。修改一下 SecondActivity 的代码。
class SecondActivity : BaseLifecycleActivity() {
private val binding by lazy { ActivitySecondBinding.inflate(layoutInflater) }
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(binding.root)
postMessage()
}
private fun postMessage() {
binding.secondBt.post {
Thread.sleep(10)
postMessage()
}
}
}
再来看一下日志：
FirstActivity: onPause, onPause() 距离 finish() ：6 ms
SecondActivity: onCreate
SecondActivity: onStart
SecondActivity: onResume
FirstActivity: onStop, onStop() 距离 finish() ：10033 ms
FirstActivity: 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 版本。
Activity.java
public void finish() {
finish(DONT_FINISH_TASK_WITH_ACTIVITY);
}
重载了带参数的 finish() 方法。参数是 DONT_FINISH_TASK_WITH_ACTIVITY ，含义也很直白，不会销毁 Activity 所在的任务栈。
Activity.java
private void finish(int finishTask) {
// mParent 一般为 null，在 ActivityGroup 中会使用到
if (mParent == null) {
…
try {
// Binder 调用 AMS.finishActivity()
if (ActivityManager.getService()
.finishActivity(mToken, resultCode, resultData, finishTask)) {
mFinished = true;
}
} catch (RemoteException e) {
}
} else {
mParent.finishFromChild(this);
}
…
}
这里的 mParent 大多数情况下都是 null ，不需要考虑 else 分支的情况。一些大龄 Android 程序员可能会了解 ActivityGroup，在此种情况下 mParent 可能会不为 null。（因为我还年轻，所以没有使用过 ActivityGroup，就不过多解释了。）其中 Binder 调用了 AMS.finishActivity() 方法。
ActivityManagerService.java
public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,
int finishTask) {
…
synchronized(this) {
// token 持有 ActivityRecord 的弱引用
ActivityRecord r = ActivityRecord.isInStackLocked(token);
if (r == null) {
return true;
}
…
try {
boolean res;
final boolean finishWithRootActivity =
finishTask == Activity.FINISH_TASK_WITH_ROOT_ACTIVITY;
// finishTask 参数是 DONT_FINISH_TASK_WITH_ACTIVITY，进入 else 分支
if (finishTask == Activity.FINISH_TASK_WITH_ACTIVITY
|| (finishWithRootActivity && r == rootR)) {
res = mStackSupervisor.removeTaskByIdLocked(tr.taskId, false,
finishWithRootActivity, “finish-activity”);
} else {
// 调用 ActivityStack.requestFinishActivityLocked()
res = tr.getStack().requestFinishActivityLocked(token, resultCode,
resultData, “app-request”, true);
}
return res;
} finally {
Binder.restoreCallingIdentity(origId);
}
}
}
注意方法参数中的 token 对象，在上一篇文章 为什么不能使用 Application Context 显示 Dialog？ 中详细介绍过，Token 是 ActivityRecord 的静态内部类，它持有外部 ActivityRecord 的弱引用。继承自 IApplicationToken.Stub ，是一个 Binder 对象。ActivityRecord 就是对当前 Activity 的具体描述，包含了 Activity 的所有信息。
传入的 finishTask() 方法的参数是 DONT_FINISH_TASK_WITH_ACTIVITY，所以接着会调用 ActivityStack.requestFinishActivityLocked() 方法。
ActivityStack.java
final boolean requestFinishActivityLocked(IBinder token, int resultCode,
Intent resultData, String reason, boolean oomAdj) {
ActivityRecord r = isInStackLocked(token);
if (r == null) {
return false;
}
finishActivityLocked(r, resultCode, resultData, reason, oomAdj);
return true;
}
final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,
String reason, boolean oomAdj) {
// PAUSE_IMMEDIATELY 为 true，在 ActivityStackSupervisor 中定义
return finishActivityLocked(r, resultCode, resultData, reason, oomAdj, !PAUSE_IMMEDIATELY);
}
最后调用的是一个重载的 finishActivityLocked() 方法。
ActivityStack.java
// 参数 pauseImmediately 是 false
final boolean finishActivityLocked(ActivityRecord r, int resultCode, Intent resultData,
String reason, boolean oomAdj, boolean pauseImmediately) {
if (r.finishing) { // 重复 finish 的情况
return false;
}
mWindowManager.deferSurfaceLayout();
try {
// 标记 r.finishing = true，
// 前面会做重复 finish 的检测就是依赖这个值
r.makeFinishingLocked();
final TaskRecord task = r.getTask();
…
// 暂停事件分发
r.pauseKeyDispatchingLocked();
adjustFocusedActivityStack(r, “finishActivity”);
// 处理 activity result
finishActivityResultsLocked(r, resultCode, resultData);
// mResumedActivity 就是当前 Activity，会进入此分支
if (mResumedActivity == r) {
…
// Tell window manager to prepare for this one to be removed.
r.setVisibility(false);
if (mPausingActivity == null) {
// 开始 pause mResumedActivity
startPausingLocked(false, false, null, pauseImmediately);
}
…
} else if (!r.isState(PAUSING)) {
// 不会进入此分支
…
}
return false;
} finally {
mWindowManager.continueSurfaceLayout();
}
}
调用 finish 之后肯定是要先 pause 当前 Activity，没毛病。接着看 startPausingLocked() 方法。
ActivityStack.java
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
ActivityRecord resuming, boolean pauseImmediately) {
…
ActivityRecord prev = mResumedActivity;
if (prev == null) {
// 没有 onResume 的 Activity，不能执行 pause
if (resuming == null) {
mStackSupervisor.resumeFocusedStackTopActivityLocked();
}
return false;
}
…
mPausingActivity = prev;
// 设置当前 Activity 状态为 PAUSING
prev.setState(PAUSING, “startPausingLocked”);
…
if (prev.app != null && prev.app.thread != null) {
try {
…
// 1. 通过 ClientLifecycleManager 分发生命周期事件
// 最终会向 H 发送 EXECUTE_TRANSACTION 事件
mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
} catch (Exception e) {
mPausingActivity = null;
}
} else {
mPausingActivity = null;
}
…
// mPausingActivity 在前面已经赋值，就是当前 Activity
if (mPausingActivity != null) {
…
if (pauseImmediately) { // 这里是 false，进入 else 分支
completePauseLocked(false, resuming);
return false;
} else {
// 2. 发送一个延时 500ms 的消息，等待 pause 流程一点时间
// 最终会回调 activityPausedLocked() 方法
schedulePauseTimeout(prev);
return true;
}
} else {
// 不会进入此分支
}
}
这里面有两步重点操作。第一步是注释 1 处通过 ClientLifecycleManager 分发生命周期流程。第二步是发送一个延时 500ms 的消息，等待一下 onPause 流程。但是如果第一步中在 500ms 内已经完成了流程，则会取消这个消息。所以这两步的最终逻辑其实是一致的。这里就直接看第一步。
mService.getLifecycleManager().scheduleTransaction(prev.app.thread, prev.appToken,
PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
ClientLifecycleManager 我在之前的一篇文章 从源码看 Activity 生命周期（上篇） 做过详细介绍。它会向主线程的 Handler H 发送 EXECUTE_TRANSACTION 事件，调用 XXXActivityItem 的 execute() 和 postExecute() 方法。execute() 方法中会 Binder 调用 ActivityThread 中对应的 handleXXXActivity() 方法。在这里就是 handlePauseActivity() 方法，其中会通过 Instrumentation.callActivityOnPause(r.activity) 方法回调 Activity.onPause() 。
Instrumentation.java
public void callActivityOnPause(Activity activity) {
activity.performPause();
}
到这里，onPause() 方法就被执行了。但是流程没有结束，接着就该显示下一个 Activity 了。前面刚刚说过会调用 PauseActivityItem 的 execute() 和 postExecute() 方法。execute() 方法回调了当前 Activity.onPause()，而 postExecute() 方法就是去寻找要显示的 Activity 。
PauseActivityItem.java
public void postExecute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
try {
ActivityManager.getService().activityPaused(token);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
Binder 调用了 AMS.activityPaused() 方法。
ActivityManagerService.java
public final void activityPaused(IBinder token) {
synchronized(this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
}
调用了 ActivityStack.activityPausedLocked() 方法。
ActivityStack.java
final void activityPausedLocked(IBinder token, boolean timeout) {
final ActivityRecord r = isInStackLocked(token);
if (r != null) {
// 看这里
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
if (mPausingActivity == r) {
mService.mWindowManager.deferSurfaceLayout();
try {
// 看这里
completePauseLocked(true /* resumeNext /, null / resumingActivity */);
} finally {
mService.mWindowManager.continueSurfaceLayout();
}
return;
} else {
// 不会进入 else 分支
}
}
}
上面有这么一行代码 mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r) ，移除的就是之前延迟 500ms 的消息。接着看 completePauseLocked() 方法。
ActivityStack.java
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
ActivityRecord prev = mPausingActivity;
if (prev != null) {
// 设置状态为 PAUSED
prev.setState(PAUSED, “completePausedLocked”);
if (prev.finishing) { // 1. finishing 为 true，进入此分支
prev = finishCurrentActivityLocked(prev, FINISH_AFTER_VISIBLE, false,
“completedPausedLocked”);
} else if (prev.app != null) {
// 不会进入此分支
} else {
prev = null;
}
…
}
if (resumeNext) {
// 当前获取焦点的 ActivityStack
final ActivityStack topStack = mStackSupervisor.getFocusedStack();
if (!topStack.shouldSleepOrShutDownActivities()) {
// 2. 恢复要显示的 activity
mStackSupervisor.resumeFocusedStackTopActivityLocked(topStack, prev, null);
} else {
checkReadyForSleep();
ActivityRecord top = topStack.topRunningActivityLocked();
if (top == null || (prev != null && top != prev)) {
mStackSupervisor.resumeFocusedStackTopActivityLocked();
}
}
}
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
总结
找工作是个很辛苦的事情，而且一般周期都比较长，有时候既看个人技术，也看运气。第一次找工作，最后的结果虽然不尽如人意，不过收获远比offer大。接下来就是针对自己的不足，好好努力了。
最后为了节约大家的时间，我把我学习所用的资料和面试遇到的问题和答案都整理成了PDF文档，都可以分享给有需要的朋友，如有需要私信我【资料】或者**【点这里】免费领取**
喜欢文章的话请关注、点赞、转发 谢谢！
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-LYgmb2hM-1710682565208)]
[外链图片转存中…(img-VdiQ671h-1710682565209)]
[外链图片转存中…(img-jgl9DQqf-1710682565209)]
[外链图片转存中…(img-MkwqIeSI-1710682565210)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）
[外链图片转存中…(img-UscEcdqn-1710682565210)]
总结
找工作是个很辛苦的事情，而且一般周期都比较长，有时候既看个人技术，也看运气。第一次找工作，最后的结果虽然不尽如人意，不过收获远比offer大。接下来就是针对自己的不足，好好努力了。
最后为了节约大家的时间，我把我学习所用的资料和面试遇到的问题和答案都整理成了PDF文档，都可以分享给有需要的朋友，如有需要私信我【资料】或者**【点这里】免费领取**
喜欢文章的话请关注、点赞、转发 谢谢！
655
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
