在IntentService中需要唤醒锁定：为什么要通过WakefulBroadcastReceiver？

Question

我有一个IntentService从我的应用程序中的其他地方（比如来自组件X）调用。我想让onHandleIntent以唤醒锁运行。似乎有两种方法可以做到这一点：

1. 在onHandleIntent。
中获取并释放唤醒锁定
2. 创建一个启动此服务的新WakefulBroadcastReceiver。在组件X中，直接调用此接收器而不是服务。

第二个选项似乎是recommended。但为什么？增加的间接和样板是否比第一种方法有任何优势？

Answer 1

Back in 2010，我们被告知，AlarmManager和_WAKEUP式警报的唯一保证是如果我们使用了广播PendingIntent ，然后 Android会让设备保持足够长的时间以使onReceive()完成。任何其他类型的PendingIntent都没有这种保证。

但是，在主应用程序线程上调用了onReceive()的{​​{1}}，我们无法安全地在那里花费太多时间。理想情况下，它是亚毫秒级，就像你所知道的那样，你的UI恰好在现在的前景中，并且你不希望这个接收器导致抖动。

所以，食谱变成了：

• 让警报触发BroadcastReceiver
• 让接收方获得BroadcastReceiver
• 让接收方将工作委托给WakeLock，通常为Service
• 让服务在工作完成时释放IntentService

My WakefulIntentService是第一个为此配方提供支持的库。 WakeLock后来出现了。他们都用不同的语义完成了同样的目的。

请注意“我们为什么不在服务中获得WakefulBroadcastReceiver？”失败是因为设备可能会在WakeLock的结尾与服务可能获得onReceive()的第一个地方之间入睡。

现在，对于其他情况，不涉及WakeLock，让服务管理自己的AlarmManager是完全合理的。事实上，这是我使用特殊WakeLock（IntentService）而非特殊WakefulIntentService（BroadcastReceiver）的原因之一。