android - 在android中使用带有警报管理器的广播接收

Question

为什么在使用警报管理器时通常建议为 Intent Service 传递待处理的 Intent？同样的事情可以在报警管理器调用的广播接收器的onreceive()函数中完成。使用服务（意图服务）有什么好处？

Answer 1

如果您需要完成的所有事情都可以在 中完成onReceive，BroadcastReceiver那么您应该使用它，而不是IntentService.

如果你想在 之后做任何事情BroadcastReceiver，那么你应该使用IntentService. 例如，如果您希望自己BroadcastReceiver启动 a Service，并且希望服务获得 a WakeLock，那么您应该改用 an IntentService。

原因是AlarmManager只保证onReceivea 的BroadcastReceiver运行，即使你使用RTC_WAKEUP. 因此，如果您使用BroadcastReceiver/Service组合，那么 CPU 可能会在Service获取之前进入休眠WakeLock状态 - 这是，除非您WakeLock在 the 中获取 aBroadcastReceiver并且您在服务中获取了一个，可能通过 a 获取static WakeLock。但这……很乱，我想。

顺便说一句，我从未实现过IntentService. 我只是使用BroadcastReceiverandService组合并且从未报告过问题。我提供的所有信息都是我从其他 SO 帖子（主要来自 CommonsWare）中读到的

编辑：

我从 CommonsWare 在 StackOverflow 上发布的内容中读到了 50 毫秒的时间框架，CommonsWare 似乎是一个相当可靠的 Android 知识来源。

我查了一下，文档确实说：

（在考虑阻止接收者和杀死候选人之前，系统允许有 10 秒的超时）。

他们还说：

如果此 BroadcastReceiver 是通过标签启动的，则对象在从此函数返回后不再存在。

1. 为了安全起见，你不应该做任何需要接近 10 秒的事情。
2. 如果你做任何必须等待响应的事情，那么它BroadcastReceiver将会死掉，因为它onReceive可能会在你得到响应之前完成运行。

不过，我认为 50 毫秒时间框架的原因是为了避免导致 ANR 或任何延迟的风险。因为如果你使用 a Service，那么你可以启动一个新的Thread，并且它不会阻塞。您将无法在 a 中启动一个新Thread的，BroadcastReceiver因为线程之后的代码将继续运行，theBroadcastReceiver会死掉，然后 theThread也会死掉。