我正在开发一个使用 AlarmManager 在后台生成一些服务的应用程序。时间对我们的应用程序非常重要，功能不能等待下一个维护窗口的出现。要求用户将应用程序列入白名单不是问题，但不能解决暂停警报的问题。此外，电池消耗也不是什么大问题。
我想到的第一个可能的解决方案是生成一个始终运行的前台服务来处理服务的重新调度，而不是 AlarmManager，但这样做会改变我们应用程序的大部分基本结构，对我们来说是不可行的。
我刚刚实施的当前修复是发送高优先级推送通知并在接收到消息时，采取完全唤醒锁定并打开屏幕以打破打盹模式。
我想知道是否有另一种打瞌睡模式的方法？也可以不使用唤醒锁吗？实施上述解决方案会产生一些可能的影响吗？
PS 我正在使用 UrbanAirship 进行推送通知。
您不能“中断”/停止/禁用打瞌睡模式，但有一些方法可以在设备打瞌睡时暂时解除应用程序的限制。
FCM 高优先级消息让您能够可靠地唤醒您的应用程序以访问网络，即使用户的设备处于打盹或应用程序处于应用程序待机模式。在 Doze 或 App Standby 模式下，系统传递消息并让应用程序临时访问网络服务和部分唤醒锁，然后将设备或应用程序返回到空闲状态。
高优先级 FCM 消息不会影响打盹模式，也不会影响任何其他应用程序的状态。这意味着您的应用可以使用它们进行有效通信，同时最大限度地减少对系统和设备的电池影响。
andAllowWhileIdle使用 AlarmManager 设置的警报。打盹特别有可能影响 AlarmManager 警报和计时器管理的活动，因为 Android 5.1（API 级别 22）或更低版本中的警报在系统处于打盹时不会触发。
为了帮助安排闹钟，Android 6.0（API 级别 23）引入了两个新的 AlarmManager 方法：setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle()。使用这些方法，您可以设置即使设备处于打瞌睡状态也会触发的警报。
请注意，打盹模式下两次警报之间的最小间隔为 9 分钟。
对于这两种情况，您的应用程序会在短时间内恢复完整功能（意味着：打盹限制不适用），当该时间到期时，操作系统将恢复打盹限制。
请注意，在这些“唤醒”期间，您无需打开屏幕即可执行代码。
我手头没有消息来源，但我相信我命名的短时间约为 10 秒。