Question

根据Android Marshmallow文档，当系统处于打盹模式时，将忽略任何唤醒锁。然而，我不清楚唤醒锁是否会阻止打瞌睡模式。

Answer 1

根据一些测试，使用Nexus 5安装Android 6.0的最终（？）预览：

持有PARTIAL_WAKE_LOCK不足以阻止打盹模式 - 即使您拥有WakeLock并且正在尝试定期工作（例如setExactAndAllowWhileIdle()，设备仍会打瞌睡每分钟控制一次）
使用android:keepScreenOn（或等效的Java）保持屏幕，屏幕打开，足以阻止打盹模式
在关闭屏幕（用户按下POWER按钮）的情况下，使用android:keepScreenOn（或等效的Java）保持屏幕不足以阻止打盹模式

IOW，即使播放器可能没有移动或充电，在用户观看视频时也不应影响视频播放器等。但是，如果用户按下POWER按钮，您将重新回到Doze风险中。

我没有尝试使用FULL_WAKE_LOCK（我希望行为与android:keepScreenOn相同，但我还远未确定。）

Answer 2

<强>有趣

Android 6.0中的Google自己的时钟应用程序可以完全阻止Doze模式：

在时钟应用程序中设置一个时间＆lt;从现在起60分钟
关闭设备
在控制台中设置$ adb shell dumpsys battery unplug
在控制台中设置$ adb shell dumpsys deviceidle step

州仍然是“步入：主动”

如果您使用时间＆gt;设置闹钟从现在开始60分钟，它正常工作（设备可能进入空闲状态）。但是一旦警报是＆lt; 60分钟后，似乎该设备从Doze空闲中悄然唤醒，因为状态再次返回'ACTIVE'（而不是'IDLE_MAINTENANCE'）。

我真的很想知道他们是怎么做到的！

- 编辑 -

默认情况下，setAlarmClock()似乎有这种行为。这可能对某些用例有用。

Answer 3

在回应上述评论时，这不是问题的答案。这是为了澄清Doze模式下的应用行为。在我的测试应用程序中，我试图每2分钟获得一次GPS位置，GPS信号强度始终足够。

测试条件：

Nexus 9，Android M Preview，Build MPA44I
“忽略优化”ON
setExactAndAllowWhileIdle（），间隔为2分钟
每个操作都有1分钟的超时时间来获取GPS定位并被部分唤醒锁定
日志写入SQLiteOpenHelper.getWritableDatabase（）

打盹模式的GPS测试日志：

1   2015-09-04 - 12:14  GPS ok (device left stationary unplugged)
2   2015-09-04 - 12:16  GPS ok
3   2015-09-04 - 12:18  GPS ok
4   2015-09-04 - 12:20  GPS ok
5   2015-09-04 - 12:22  GPS ok
6   2015-09-04 - 12:24  GPS ok
7   2015-09-04 - 12:26  GPS ok
8   2015-09-04 - 12:28  GPS ok
9   2015-09-04 - 12:30  GPS ok
10  2015-09-04 - 12:32  GPS ok
11  2015-09-04 - 12:34  GPS ok
...
31  2015-09-04 - 13:14  GPS ok
32  2015-09-04 - 13:16  GPS ok
33  2015-09-04 - 13:18  GPS ok
34  2015-09-04 - 13:20  GPS ok
35  2015-09-04 - 13:22  GPS ok
36  2015-09-04 - 13:24  GPS ok
37  2015-09-04 - 13:26  GPS ok (entering Doze mode some time after)
38  2015-09-04 - 13:42  GPS failed, active millis: 60174 (idle)
39  2015-09-04 - 13:57  GPS failed, active millis: 60128 (idle)
40  2015-09-04 - 14:12  GPS failed, active millis: 60122 (idle)
41  2015-09-04 - 14:16  GPS ok (idle maintenance)
42  2015-09-04 - 14:18  GPS ok (idle maintenance)
43  2015-09-04 - 14:20  GPS ok (idle maintenance)
44  2015-09-04 - 14:22  GPS ok (idle maintenance)
45  2015-09-04 - 14:38  GPS failed, active millis: 60143 (idle)
46  2015-09-04 - 14:53  GPS failed, active millis: 60122 (idle)
47  2015-09-04 - 15:08  GPS failed, active millis: 60068 (idle)
48  2015-09-04 - 15:23  GPS failed, active millis: 60138 (idle)
49  2015-09-04 - 15:38  GPS failed, active millis: 60140 (idle)
50  2015-09-04 - 15:53  GPS failed, active millis: 60131 (idle)
51  2015-09-04 - 16:08  GPS failed, active millis: 60185 (idle)
52  2015-09-04 - 16:12  GPS ok (ending Doze mode - power button on)

现在我再次查看我的日志，我发现了一个非常奇怪的行为： “忽略优化”关闭的相同测试显示基本相同的结果（就像它应该的那样），但是大多数时候超时没有按预期工作，我在~330000（~5次超时）的范围内得到“活动毫秒”空闲时，甚至~580000（~10次超时时间）。这个奇怪的行为我无法解释，但它似乎表明在Doze模式下实际上有一些“忽略优化”设置的效果。

编辑：上面描述的“奇怪”行为现在只是documented：只有“忽略优化”开启，您才可以在打盹空闲模式下保留部分唤醒锁。

Answer 4

据我所知，当更深的打瞌睡开始时，所有唤醒锁（除具有当前前台服务的应用所持有的唤醒锁）都会被删除。打瞌睡的全部意义是让系统在“相关条件”设置时进入睡眠状态。所以是锁定不是他们会关心的东西。

我看待它的方式JobScheduler是未来调度，后台任务等的方法。虽然可以控制开发人员，但这就是我认为框架人员为电池续航所采取的调用。这更像是“触发器，希望事情会或多或少地按时发生”。

来到你的用例，JobScheduler有一个onStopJob回调，知道你的工作执行何时停止[出于任何原因 - 说wifi被切换]你需要采取适当的行动，如重新安排你的工作，为下一个维护窗口。来自文档：

一个直接的反响是系统会停止为你拿一个唤醒锁。

Wakelock和打盹模式

4 个答案: