我没有时间玩接收器，而且我对2.3.x以上的任何东西都不熟悉，所以当我读到这个问题时我感到非常困惑：
Can BroadcastReceiver registered in AndroidManifest receive intents when application process is killed?
它的作者能够在任务管理器列表中看到BroadcastReceiver应用程序，当应用程序被杀死时，不再调用广播接收器。这是由于3.1中引入的新机制 http://developer.android.com/sdk/android-3.1.html#launchcontrols
在该链接中，提到了Application的停止状态。应用程序生命周期没有在文档AFAIK中的任何地方解释，所以我猜一个应用程序可以处于以下三种状态之一：
为了让用户能够在任务管理器中看到应用程序，它应该处于启动或运行状态（我在这里猜测，因为我不知道是否有更多状态）。似乎该应用程序在列表中显示了相当长的时间。如果接收器应用程序已启动或正在运行，则它必须具有带有自己的Dalvik VM实例的linux主机进程。这与我之前关于接收器应如何工作的信念相冲突：
onReceive方法。onReceive返回，如果没有其他服务或活动，则托管过程很可能被杀死，从而释放资源。所以，我的问题：
onReceive的调用过程中或者在它返回并且有资格被杀死之后才应该列出应用程序，根据文档，应该是短暂的间隔。提前致谢。
答案 0 :(得分：1)
所以我猜应用程序可以处于以下三种状态之一：停止（不在RAM中），已启动（在RAM中，未运行），正在运行（在RAM中）
不完全是这样，至少就像我说的那样，尽管这可能是一个术语和/或语言问题。
进程正在运行或未运行。它不能“在RAM中”和“没有运行”。
独立于此概念，从Android 3.1开始，应用程序可以禁用或启用其清单注册的BroadcastReceivers。文档将残疾人状态称为“已停止”，这是谷歌非常不幸的选择条款，我曾多次抱怨过。当您看到对此状态的引用时，请忽略术语“已停止”的任何其他定义。实际上，您可能想要为此状态组成其他术语，例如“snicklefritzed”。
安装后，您的应用程序会立即被冻结。一旦明确运行您的某个组件（例如，用户从主屏幕手动启动活动），您的应用就会进入“正常”状态。当用户从“设置”强制停止您的应用时，您的应用会被移回到snicklefritzed。有关应用程序是正常还是非法浏览的信息保存在某个操作系统管理的文件中，（AFAIK）缓存在操作系统进程中。
因此，应用程序是：
（这是不可能运行和snicklefritzed，因为运行某些东西的行为会让你离开snicklefritzed状态，并且强制停止将终止你的过程）
当接收器未运行时，系统不会有性能损失。
正确。
一旦需要通知接收者，就会产生一个新的前台进程（如果尚未运行），则实例化一个新的Receiver，并调用onReceive方法。
正确。
在最长处理时间为10秒后，onReceive返回，并且如果没有其他服务或活动，则托管进程很可能被杀死，从而释放资源。
我会将其称为“托管进程有资格被杀死，并且因为操作系统需要其他进程的RAM而被杀死的优先级队列中相对较高”。
为什么操作系统会为甚至没有收到通知的接收器产生一个进程（根本不会得到通知）。
没有。
。忽略了一个snicklefritzed应用程序的清单注册BroadcastReceivers。
流程运行时在任务管理器中列出接收程序进程的可能性有多大？
100％。进程未运行时为0％。
这是3.1+的新行为，以便用户可以注意到它存在并强行关闭吗？
当你说“这个”和“它”时，我不知道你指的是什么。
或者，即使对于2.x操作系统，当系统有足够的可用内存时，这是正常的行为吗？
当你说“它”时，我仍然不知道你指的是什么。