在 onDestroy 中进行所有清理是不是安全？

Posted 2023-04-18

【中文标题】在 onDestroy 中进行所有清理是不是安全？

【英文标题】：Is it safe to do all cleaning up in onDestroy?在 onDestroy 中进行所有清理是否安全？

【发布时间】：2013-01-13 00:35:46

【问题描述】：

更具体地说：在 onDestroy 中取消任务是否安全？另外，使用 onDestroy 注销接收器和释放资源是否安全？

我的目标是确保我的任务在 Activity 被销毁时被取消/销毁，而不是之前。

onDestroy():

在活动被销毁并且资源必须被销毁时调用 发布。 在 Activity 被匆忙销毁时不会调用（当 系统资源不足等）。

第一种情况很清楚：我在 onDestroy 中进行了所有清理，没有出现任何问题。第二种情况虽然有点问题。当 Activity 被销毁并跳过 onDestroy（所以我不会取消我的任务）时，是否会发生任务继续执行，然后完成并尝试更新死的 Activity，因此应用程序崩溃？

---

我们来到了真正的问题：

当 Activity 被杀死并跳过 onDestroy 时，附加到该 Activity 的所有内容是否会自动销毁？（是否仅在 所有内容都将被完全清除时才跳过 onDestroy？任务，注册接收者等） 如果跳过 onDestroy 是否意味着 整个应用 正在被杀死？

---

让我们关注 onDestroy()，因为解决方案不在 onPause() 或 onStop() 中。参数：

在销毁 Activity 时可以跳过 onStop()，就像 onDestroy 一样 onPause 调用太早且太频繁，因此不适合用例。示例：

锁屏：当设备锁屏时可以调用onPause。很多时候，这就像屏幕保护程序一样发生，用户会立即解锁，因为他站在那里看着屏幕。在这种情况下取​​消任务并停止我的应用程序正在执行的所有操作只会降低用户体验。我不希望我的应用仅仅因为偶然的“屏幕保护程序”而窒息和行为不端。

在一个示例应用程序中，我有两个屏幕是活动。用户可以在它们之间快速切换。在这个应用程序中，用户倾向于经常快速地切换屏幕。

导航：其中一个屏幕有一张地图，可以从系统接收位置更新。它记录了位置（路线）变化的精确图形日志，因此它需要不断运行，直到 Activity 关闭。通常我会在 onResume 和 onPause 中注册和取消注册任何接收器。但是，这会使应用程序非常不可用，因为每次用户导航离开时地图上的更新都会停止。因此，我想在 onDestroy 中注销接收器。

加载列表：第二个屏幕有一个列表，显示来自网络服务的数据。下载数据需要 4 秒。我使用 AsyncTask 并且我知道我应该在必要时取消。它不应该在 onPause 中取消，因为它应该在用户在屏幕之间切换时继续加载。因此，我想在 onDestroy 中取消它。

还有很多例子。在每个人看来，其中一些可能并不完全合适（您甚至可能建议使用服务而不是 AsyncTask）。但是这个想法很重要，而且他们都有一个相同的想法：继续做特定于 Activity 的工作，而 Activity 暂停，但确保停止做当 Activity 被销毁时。 （不管我使用的是 AsyncTask 还是 Service，无论哪种情况，都应该在 Activity 销毁时停止工作。）

附：如果答案是在 onDestroy 中进行清理是不安全的，这意味着 android 框架要求我们停止我们在 onPause 中所做的一切。然后我看不出有任何理由使用 onDestroy...

【参考方案1】：

我想推荐你给这个宝贝：http://developer.android.com/reference/android/content/ComponentCallbacks2.html#onTrimMemory(int)

基本上，它为您提供了系统认为取消任务和清理内存有用的所有地方：

请仔细看看以下2个案例：

TRIM_MEMORY_UI_HIDDEN - 进程一直显示用户界面，现在不再显示。

TRIM_MEMORY_COMPLETE - 进程接近后台 LRU 列表的末尾。

你问的大部分情况是什么。

在同样的方法中，您还可以捕获 TRIM_MEMORY_RUNNING_CRITICAL，它会提醒您系统没有内存并且必须立即采取特殊措施的情况。

这种方法在类似情况下让我的开发生活变得更好。

【讨论】：

谢谢，我不确定我是否可以直接将它应用到我的案例中，但它看起来确实很有趣。

【参考方案2】：

如果你只是需要做一些清理工作，不管活动如何关闭，你应该可以使用onSaveInstanceState()和onDestroy()的组合。无论如何都应该调用其中之一。可能在您的活动中有一个boolean cleanupDone，只要两者之一完成，就会设置它。

关于保存用户数据，请看Saving Persistent State：

谷歌推荐一个

“就地编辑”用户模型

即：用户创建新数据后立即保存，最迟保存在onPause()。这并不意味着您需要重新创建onResume() 中的数据，只是它应该已经保存了。

顺便说一句：onStop()can be skipped only on pre-Honeycomb devices，也就是as of June 2015，不到所有设备的6%。尽管如此，如果onDestroy() 或onStop() 被省略，则应该调用onSaveInstanceState()。

【参考方案3】：

就我使用安卓而言，

1当您的应用崩溃时，与之相关的所有资源都会被销毁。

2当设备更改配置导致Activity被销毁并重新创建时。

3当应用程序在后台运行时，Android 由于运行在内存不足而杀死它

除了这些之外，其他的回调方法被称为 i e

1 当另一个 Activity 出现在前面，或者您的设备锁定 ..etc 时

在所有情况下，根据您的要求，您可以在 onDestroy 中释放所有资源并取消 Thread 和 Asyntask 并停止所有服务等。如果您希望您的任务在调用销毁时保持暂停和活动状态，那么您可以保存配置并在通过检查是否为 null 再次调用 onCreate 时保留它。

【讨论】：

感谢您的回答，但问题是在销毁活动时并不总是调用 onDestroy，尤其是在内存不足的情况下。那么我如何确保我释放所有内容呢？这就是我的问题所在。 （关于 2 的附注 - 重新创建活动，但如果您保留对旧实例的引用，旧实例将保持活动状态。）

在 UI-Thread 中运行的东西会被销毁，而其他的则保持活动状态，例如您自己的线程、Asyntask、服务