android - BroadcastReceivers 和内存使用

Question

我没有时间玩接收器，而且我对2.3.x以上的东西都不熟悉，所以当我读到这个问题时，我感到非常困惑:
Can BroadcastReceiver registered in AndroidManifest receive intents when application process is killed?

其作者能够在任务管理器列表中看到BroadcastReceiver应用，当应用被kill时，广播接收器不再被调用。这是由于 3.1 中引入的新机制:
http://developer.android.com/sdk/android-3.1.html#launchcontrols

在该链接中，提到了应用程序的停止状态。 AFAIK 文档中的任何地方都没有解释应用程序生命周期，所以我猜应用程序可以处于以下 3 种状态之一:

• 已停止(不在 RAM 中)
• 已启动(在 RAM 中，未运行)
• 运行(在 RAM 中)

为了让用户能够在任务管理器中看到该应用程序，它应该处于启动或运行状态(我在这里猜测，因为我不知道是否还有更多状态)。并且该应用程序似乎在列表中显示了很长时间。如果接收器应用程序启动或运行，它必须有一个 linux 托管进程和它自己的 Dalvik VM 实例。这与我之前关于接收器应该如何工作的信念相冲突:

• 当接收器未运行时，系统不会出现性能损失。
• 一旦需要通知接收器，就会生成一个新的前台进程(如果尚未运行)，实例化一个新的接收器，并调用 onReceive 方法。
• 在最长 10 秒的处理时间后，onReceive 返回，如果没有其他服务或 Activity ，托管进程很可能被终止，从而释放资源。

所以，我的问题:

1. 如果应用程序显示在任务管理器中(因此有一个进程)，但尚未收到通知，为什么操作系统会为甚至没有收到通知(并且可能不会收到通知)的接收器生成一个进程根本)。如果应用程序已收到通知但进程尚未终止(因此它列在任务管理器中)，为什么操作系统不在它完成后立即终止它？在这里，我假设任务管理器只显示分配了进程的应用程序，但这会引发以下问题:
2. 在任务管理器中列出接收进程的可能性有多大？任务管理器是否显示接收器应用程序，即使它已停止？如果是这样，这是 3.1+ 的新行为，以便用户可以注意到它存在并强制关闭它吗？如果不是，则只有在调用 onReceive 的过程中或在它返回并有资格被终止时，应用程序才应列在那里，根据文档，这应该是一个很短的间隔.

提前致谢。

Answer 1

so I guess an App can be in one of these 3 states: Stopped (not in RAM), Started (in RAM, not running), Running (in RAM)

不完全是，至少我会这样说，尽管这可能是术语和/或语言问题。

进程正在运行或未运行。它不能“在 RAM 中”和“未运行”。

独立于此概念，从 Android 3.1 开始，应用程序可以禁用或启用其 list 注册的 BroadcastReceivers。文档将禁用状态称为“已停止”，这是谷歌方面非常不幸的术语选择，我曾多次提示过。当您看到对此状态的引用时，请忽略术语“已停止”的任何其他定义。事实上，您可能想为这种状态编造一些其他术语，例如“snicklefritzed”。

您的应用程序在安装后立即被窃笑。一旦某些东西明确运行您的组件之一(例如，用户从主屏幕手动启动 Activity )，您的应用程序就会进入“正常”状态。当用户从“设置”中强行停止您的应用程序时，您的应用程序将被移回被窃笑。有关应用程序是正常还是 snicklefritzed 的信息保存在一些操作系统管理的文件中，并且(据我所知)缓存在操作系统进程中。

因此，应用程序是:

• 没有运行(没有进程)和 snicklefritzed
• 没有运行(没有进程)，也没有 snicklefritzed
• 运行(有一个过程)而不是 snicklefritzed

(不可能正在运行和 snicklefritzed，因为运行某些东西的行为会使你脱离 snicklefritzed 状态，并且强行停止会终止你的过程)

When a receiver isn't running, there's no performance penalty to the system.

正确。

Once a receiver needs to be notified, a new foreground process is spawned (if not already running), a new Receiver is instantiated, and the onReceive method is called.

正确。

After a max processing time of 10 secs, onReceive returns, and provided there are no additional Services or Activities, the hosting process is very likely being killed, thus releasing resources.

我会把它表述为“托管进程有资格被杀死，并且在被杀死的优先级队列中相对较高，因为操作系统需要其他进程的 RAM”。

Why would the OS spawn a process for a receiver that hasn't even been notified (and might not be notified at all).

事实并非如此。 snicklefritzed 应用程序的 list 注册 BroadcastReceivers 被忽略。

What are the chances of having a receiver process listed in the task manager?

进程运行时为 100%。进程未运行时为 0%。

Is this the new behaviour for 3.1+ so that the user can notice it exists and force-close it?

当你说“这个”和“它”时，我不知道你指的是什么。

Or is it the normal behaviour when the system has enough memory available, even for 2.x OSes?

当你说“它”时，我仍然不知道你指的是什么。