在android中使用广播recevire与闹钟管理器

Question

为什么建议通常在使用闹钟管理器时传递意向服务的待定意图？在警报管理器调用的广播接收器的onreceive（）函数中可以做同样的事情。使用服务有什么优势（意向服务）？

Answer 1

如果您需要完成的一切都可以在BroadcastReceiver的onReceive中完成，那么您应该使用它而不是IntentService。

如果您想在BroadcastReceiver之后执行任何操作，那么您应该使用IntentService。例如，如果您希望BroadcastReceiver启动Service，并且您希望该服务获得WakeLock，则应该使用IntentService代替。

原因是，AlarmManager只保证BroadcastReceiver的onReceive将运行，即使您使用RTC_WAKEUP。所以，如果你使用BroadcastReceiver/Service组合，那么CPU在Service可以获得WakeLock之前就会睡着 - 这就是说，除非你在BroadcastReceiver中获得WakeLock并且你在服务中获得一个，也许通过staticWakeLock。但是，这是......凌乱，我想。

顺便说一句，我从未实施过IntentService。我只是使用BroadcastReceiver和Service组合，并从未报告过问题。我所提供的信息是事情，我从其他SO职位（主要来自CommonsWare）读

编辑：

我从一些CommonsWare读取的50ms的时间框架贴在计算器上，并CommonsWare似乎是一个相当Android的可靠知识来源。

我看着它，并The docs不这样说：

（有被打死10秒，系统 之前允许考虑到被阻挡的接收器和一个候选超时）。

而且他们也说：

如果广播接收器通过一个标签推出，那么对象是从这个函数返回后没有 不再活着。

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

虽然，我想50毫秒的时间框架的原因是，所以你不会冒险造成ANR或任何滞后。因为如果你使用Service，那么你可以开始一个新的Thread，它不会阻塞。您将无法在BroadcastReceiver中启动新的Thread，因为线程之后的代码将继续运行，BroadcastReceiver将会死亡，然后Thread也会死亡。