我有一个警报应用程序，用户可以设置多个警报。当闹钟响起时（使用AlarmManager和BroadcastReceiver），应用程序只会显示通知。
我的应用可能不会长时间处于前台，因此不会运行UI线程。
我的问题是，当闹钟响起并显示通知时，我的应用程序代码的一部分将被执行（BroadcastReceiver和Notification创建）。接下来发生什么？我的应用程序的进程是否立即被杀？在Android决定杀死它之前，它是否仍然处于空闲状态？
（这与有关持久通知ID的另一个问题（http://stackoverflow.com/questions/11376294/do-i-need-to-persist-my-notification-ids）有关。当我的应用不是在前台运行并且两个警报相隔一分钟，我将通知ID存储在一个静态ArrayList中。在第二个Notification创建时使用调试器，我的Notification创建器类似乎仍然保存ArrayList中的第一个Notification ID。这表明该过程在第一次和第二次警报响起之间存在。）
答案 0 :(得分：1)
Android在此处提供了一些文档：Activity | Process Lifecycle 这一切都取决于系统有多少内存和进程类型。对于BroadcastReceivers，似乎它们在设备内存不足时首先被杀死，但如果设备内存不足则会被杀死。
答案 1 :(得分：1)
接下来会发生什么？
鉴于你的头像，你有一个现场茶。或者也许是一品脱，取决于一天中的时间和饮料偏好。
： - ）
我的应用程序的进程是否立即被杀？
可能不是。
在Android决定杀死它之前，它是否仍处于空闲状态？
是。当Android需要RAM来启动其他进程时，Android会终止进程。如果您的进程没有正在运行的组件，则要终止的进程列表中的进程相对较高。因此，您的流程可能不会过长，但您的BroadcastReceiver结尾与流程终止之间没有直接的因果关系。
当我的应用程序没有在前台运行并且两个警报相隔一分钟时，我将通知ID存储在静态ArrayList中。在第二次通知创建时使用调试器，似乎我的Notification创建器类仍然在ArrayList中保存第一个Notification的ID。这表明该过程在第一次和第二次警报响起之间存在。
警报之间只有一分钟，您的过程可能会坚持下去是合理的，但这并不能保证。当然，每分钟不停地运行一个警报不太可能让你非常受欢迎，所以要确保用户可以控制这种行为（例如，可以直接停止你的应用程序，可以修改轮询周期）。