目录
没有及时回调的 onStop/onDestroy
从 Activity.finish() 说起
是谁指挥着 onStop/onDestroy 的调用?
谁让 onStop/onDestroy 延迟了 10s ?
没有及时回调的 onStop/onDestroy
交流群里碰到一个很有意思的问题,调用 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<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,打印日志如下:
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 t