Android 在系统内存不足时杀死广播接收器答案

【问题标题】：Android kills broadcast receivers on system low memoryAndroid 在系统内存不足时杀死广播接收器
【发布时间】：2013-04-07 22:41:17
【问题描述】：

我的应用程序有一个广播接收器，它监听传入的短信，但没有持久服务。

我认为当系统内存不足时广播接收器会被杀死，例如当应用程序从 android 设置中强制停止时。一天后，我在自己的手机上注意到了这一点。

android 是否会在系统内存不足时杀死广播接收器？

在此之后是否可以再次启用它们？

【问题讨论】：

标签： android

【解决方案1】：

如果应用程序由于内存不足而被强制停止或杀死，那么广播接收器也会受到影响。

从 onReceive() 返回后，BroadcastReceiver 不再活动，它的托管过程仅与在其中运行的任何其他应用程序组件一样重要。这一点特别重要，因为如果该进程仅托管 BroadcastReceiver（用户从未或最近未与之交互的应用程序的常见情况），那么在从 onReceive() 返回时，系统将认为其进程为空且 积极地杀死它，以便资源可用于其他更重要的进程。

这意味着，对于运行时间较长的操作，您通常会结合使用 Service 和 BroadcastReceiver，以在整个操作期间保持包含进程处于活动状态。

当您的应用重新启动时，再次通过onResume() 方法注册接收器。在您的活动的onPause() 方法上取消注册它。对于长时间运行的操作，请使用Service。

【讨论】：

那么，是否需要一个服务来保持广播接收器一直处于活动状态？
它是否适用于触发小部件中使用的广播接收器的警报？
警报应该在任何情况下都存在，因为它们并不真正占用内存。至于背景Services，我看到他们在内存不足的情况下被杀死。它们仍然是运行长时间运行的任务的方法，但是超出了一定的范围，框架可以决定终止它。该服务的使用是为了帮助长期运行的操作，而不是增加接收器的生命周期。在您的情况下，Alarm + Service + BroadcastReceiver 应该是一个安全的选择。
警报可能会存活，但收到警报的广播接收器可能会像您所说的那样被杀死。因此，在应用程序需要一直运行的所有场景中，服务必须伴随它再次启用广播接收器。非常感谢

【解决方案2】：

我的应用有一个广播接收器，它监听传入的短信，但没有持久服务。

没关系。大多数 Android 应用中不应存在持久服务。

我认为当系统内存不足时广播接收器被杀死

不是通过清单中的<receiver> 元素注册的那些。

就像当应用程序被强制从 android 设置停止时

有才华的程序员意识到“强制停止”与“系统内存不足时被杀死”无关。在 Android 3.1+ 上，“强制停止”将阻止使用所有广播接收器，直到用户再次手动运行活动。但是，同样，当您的进程“在系统内存不足时被终止”时，Android 不会执行与您点击“强制停止”按钮时发生的相同的事情。

android 是否会在系统内存不足时杀死广播接收器？

不是那些通过清单中的<receiver> 元素注册的。

因此，在应用程序需要一直运行的所有场景中，必须伴随一个服务以再次启用广播接收器。

当然不是。要求您停止按下“强制停止”按钮。如果您希望模拟由于内存不足而终止的进程，请使用其他方法（例如，在 Android 4.0+ 上将应用从最近任务列表中滑出）。

【讨论】：

我在 manifest 中注册了接收器，但在 android 4 上一段时间后它们停止响应，那么问题是什么？
您对 Deepak Bala 的回应有何看法？
@Ali：“您对 Deepak Bala 的回应有何看法？” ——其中大部分是不正确的。清单注册的广播接收器不受低内存条件的影响。警报不会在强制停止后继续存在。拥有“长期运行的服务”是 Android 上的一种反模式，导致用户专门使用强制停止来摆脱此类应用。
@Ali: ""我已经在 manifest 中注册了接收器，但是它们在 android 4 上一段时间后停止响应，那么问题是什么？" -- 只有 Force Stop 按钮应该会导致 manifest-registered接收器停止工作。欢迎您发布示例应用程序来演示其他情况。可能是您的接收器正在获得控制权，但是您在该接收器中尝试执行的操作在一段时间后出现问题。
@Ali：“您提出的方案是否适用于 android 2.2 和 2.3？” - 是的。 “我使用包管理器来启用和禁用应用程序内的接收器，这可能会导致问题吗？” -- 如果有一个错误，并且当你认为你是的时候你没有启用接收器，那么是的。否则，应该没问题。