AlarmManager 是否需要 WakefulBroadcastReceiver （或等效的）

Question

我在 API 25 及更高版本中使用 setExactAndAllowWhileIdle 和 AlarmManager。我还使用“标准”广播接收器来接收警报触发的 PendingIntent。此外，API 26 中已弃用 WakefulBroadcastReceiver（似乎更多地用于服务而不是警报）。

1. API 26 中是否替换了此类？
2. 当使用带有 setExactAndAllowWhileIdle 的警报时，我是否需要使用具有等效类（因为它已被弃用）和 AlarmManager 或使用标准 BroadcastReceiver 足以唤醒设备？
3. 最后，与 AlarmManager 一起使用时，我是否需要向我的 Manifest 添加 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。