面试官：为什么 Activity.finish() 之后 10s 才 onDestroy ？

最新推荐文章于 2024-12-05 12:49:14 发布

懂你的大海

最新推荐文章于 2024-12-05 12:49:14 发布

阅读量492

点赞数 1

CC 4.0 BY-SA版权

分类专栏： Andorid进阶文章标签： android android studio 移动开发

本文链接：https://blog.csdn.net/Androidbye/article/details/111910322

本文分析了在Android应用中，Activity.finish()调用后10秒才触发onDestroy()的原因。问题源于主线程因处理大量任务未执行IdleHandler，导致销毁延迟。系统提供了10s的兜底机制，若主线程在10s内未空闲，会主动回收资源。开发者应关注onStop/onDestroy调用的及时性，避免资源泄漏。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

没有及时回调的 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 对象，Token 是 ActivityRecord 的静态内部类，它持