android - AlarmManager 是否需要 WakefulBroadcastReceiver(或等效)

Question

我在 API 25 及更高版本中将 setExactAndAllowWhileIdle 与 AlarmManager 结合使用。我还使用“标准”BroadcastReceiver 来接收由 Alarm 触发的 PendingIntent。此外，API 26 中已弃用 WakefulBroadcastReceiver(它似乎更多地被设计用于服务而非警报)。

1. 这个类在 API 26 中被替换了吗？
2. 我是否需要将等效类(因为它已被弃用)与 AlarmManager 一起使用，或者在使用带有 setExactAndAllowWhileIdle 的警报时使用标准 BroadcastReceiver 足以唤醒设备？
3. 最后，当与 AlarmManager 一起使用时，我是否需要向我的 list 添加 WAKE_LOCK 权限？

Answer 1

WakefuleBroadcastReceiver 最初用于处理由于唤醒(通过警报)而需要执行的操作，其中操作可能需要一段时间，例如进行网络传输。为此，使用了 WakefulBroadcastReceiver 以便可以可靠地启动 Service 并在设备返回低功耗状态之前实际执行。它已被弃用，因为可以使用其他设施来完成相同类型的行为，例如前台服务、JobScheduler 或高优先级推送通知。就唤醒锁而言，这完全取决于您在闹钟响起时需要做什么。这篇文章可能有助于理解 AlarmManager:http://po.st/7UpipA

在 API 23 中引入的打瞌睡模式下，警报的功能逐渐减弱。从 Oreo (API 26) 开始，后台操作受到更严格的限制，以帮助延长电池生命周期。

如果您可以使用 alpha 级发布软件，那么新的 WorkManager 是您的不二之选，因为它会根据运行代码的设备为您处理很多版本依赖关系。它会自动使用 JobScheduler、AlarmManager 等，具体取决于您的需要和您正在执行的操作系统版本。

如果您不想使用 WorkManager，我建议您深入了解 JobScheduler，看看它是否能满足您的需求。您可能必须进行一些 API 级别检查，并让您的代码在某些平台上使用 AlarmManager w/WakefulBroadcastReceiver，在其他平台上使用 JobScheduler。