在 onDestroy 中释放资源真的不对吗？答案

【问题标题】：is it really wrong to release resources in onDestroy?在 onDestroy 中释放资源真的不对吗？
【发布时间】：2012-12-10 15:51:38
【问题描述】：

在极端情况下，系统可能会简单地杀死您的应用程序进程而不调用 Activity 的最终 onDestroy() 回调，因此使用 onStop() 释放可能会泄漏内存的资源非常重要。

听起来好像是错的。杀死进程怎么会泄漏内存？

【问题讨论】：

标签： android

【解决方案1】：

假设您在 onStart() 方法中启动了一项服务，并且您打算在用户退出 Activity 时停止该服务。

如果您将停止服务的代码放在 onDestroy() 中，则该代码可能永远不会被调用，这会使该服务继续运行，直到 Android 决定终止它（这可能暂时不会发生，如果有的话）。该正在运行的服务是在您的应用程序外部泄漏内存/资源的示例。

你应该把这样的清理代码放在一个保证被调用的方法中。

请注意，在调用 onPause() 之后进程是可终止的，因此 onPause() 确实是您要进行绝对必须发生的清理的地方。

（有关活动生命周期的详细信息，请参见https://developer.android.com/guide/components/activities.html 中的表 1）

另一件可能非常糟糕的泄漏：蓝牙发现或位置报告（基于 GPS 或基于网络）打开但没有尽快关闭 - 对电池寿命非常不利。

【讨论】：

我应该注意到蓝牙发现会超时，但它非常耗电，一旦您知道不再需要它就应该将其关闭。（超时时间可以长达300秒）
如果进程被杀死，Activity 怎么没有从内存中释放？如果进程被杀死，它的虚拟机也会被杀死，并且它的所有内存都会被归还给操作系统。
@user983447 - 好点 - 我已经删除了该引用。我没有考虑管理器实例在同一个进程中。如果进程没有被杀死并且开发人员没有取消注册传感器侦听器，那么问题就更大了。
我刚刚检查过 - 当活动执行 requestLocationUpdates 然后它从不执行 removeUpdates 并被杀死时，Android 停止了 GPS。因此，在 onDestroy 中执行 removeUpdates 似乎并没有什么坏处——即使在进程被杀死时未调用 onDestroy，android 也会关闭 GPS。
另一个（更重要的）要考虑的事情是，当您调用 startAcivity() 移动到下一个活动时，您是否希望 GPS 更新（或其他已启动的操作）继续。在这种情况下，活动可能会保持在“停止”状态； onDestroy() 没有被调用。在您的第二个活动中，您可能不想要那个原始 GPS 监听器。即使不需要，它也会在第二个活动期间挂起。