3

我正在使用AlarmManager在后台生成一些服务的应用程序工作。时序对于我们的应用程序非常重要,并且功能不能等待下一个维护时段发生。 要求用户白名单应用程序不是一个问题,但不解决暂停警报的问题。电池消耗也不是一个大问题。打盹模式处理

我想到的第一个可能的解决方案是生成一个始终运行的前台服务来处理重新计划服务而不是AlarmManager,但这样做会转移我们应用程序的大部分基础结构,并且对我们来说不可行。

我刚刚实施的当前修复程序是发送高优先级推送通知,并在接收消息时,采取完全唤醒锁定并打开屏幕以打破打盹模式。

我想知道是否有其他方式打破打盹模式?也可以不采取唤醒锁?实施上述解决方案可能会产生一些影响吗?

P.S.我正在使用UrbanAirship进行推送通知。

+0

*也可以不采取唤醒锁?*是可能的吗? –

+0

在没有打开屏幕的情况下接收高优先级推送通知是否有可能打瞌睡?我正在考虑不在托盘上显示通知,但没有这个功能,打开屏幕会更奇怪。 –

+0

我试图用FCM消息解决类似的问题。但它会在很短的时间内唤醒我的应用程序。你有没有一个好的解决方案? –

回答

2

您不能“休息”/停止/禁用打盹模式,但有些方法可以在设备打瞌睡时临时解除应用程序的限制。

  1. 高优先级FCM消息。

FCM高优先级的消息让你可靠地唤醒你的应用程序访问网络,即使用户的设备处于打盹或应用程序是在应用待机模式。在打盹或应用待机模式下,系统发送消息并为应用临时访问网络服务和部分唤醒锁,然后将设备或应用返回到闲置状态。

高优先级FCM消息不会影响打盹模式,也不会影响任何其他应用程序的状态。这意味着您的应用可以使用它们进行有效通信,同时最大限度地降低整个系统和设备的电池影响。

  1. andAllowWhileIdle报警设置AlarmManager。

打盹,特别容易影响AlarmManager报警和定时器管理活动,因为在搭载Android 5.1(API级别22)以下时,报警系统处于打盹不火。

为了帮助安排警报,Android 6.0(API级别23)引入了两个新的AlarmManager方法:setAndAllowWhileIdle()和setExactAndAllowWhileIdle()。使用这些方法,即使设备处于打盹状态,您也可以设置即将触发的警报。

请注意,打盹模式下两次报警之间的最小间隔时间为9分钟。


对于这两种情况下,你的应用程序恢复到全功能(意思是:休眠限制不适用)的时间很短,当时间结束时,操作系统将恢复瞌睡限制。

请注意,您不需要在这些“唤醒”期间打开屏幕来执行代码。

我手边没有资料来源,但我相信我这个短期我的名字是~10秒。

Source & additional reading

+0

你好,蒂姆,我有一个类似的问题,如果你有时间,请看看它。这对我来说真的很有帮助。 https://stackoverflow.com/questions/44079858/dealing-with-android-doze-mode-on-my-ble-monitoring-app-while-users-sleeping –