是否需要保持唤醒锁应该与您的工作量无关Service
确实如此 - 理论上,即使工作量很小,设备也可以进入睡眠状态。
仅当您绝对必须确保设备在唤醒时不能休眠时才应考虑唤醒锁。Service
在跑。像这样的案例非常罕见。一些例子:
- 闹钟应用程序(即使设备正在睡眠也需要叫醒您)
- 实时消息应用程序(即使设备处于睡眠状态也需要通知您新消息)
大多数应用程序没有如此严格的时序要求。例如,以下并不是使用唤醒锁的充分理由:
- 定期与服务器同步数据(应延迟到设备唤醒)
- 在地图上显示当前用户的位置(可以在设备唤醒时获取;但监控用户整个路线的应用程序需要唤醒锁)
如果您确实需要确保设备在休眠期间不休眠Service
执行,那么您需要获取唤醒锁(几种类型之一)。我们假设这里就是这种情况。
你希望能够开始“清醒”Service
从应用程序的 UI (Activity
),并使用AlarmManager
.
从用户界面开始
由于设备应该完全唤醒以便用户与 UI 交互,因此您可以放心地假设,如果您启动Service
为了响应 UI 交互,它将有机会获取唤醒锁(但一旦Service
已启动)。
您的解决方案涵盖了这种情况。
从...开始AlarmManager
不幸的是,无法保证(至少没有书面保证)AlarmManager
开始Service
它将持有唤醒锁并允许Service
获取自己的唤醒锁。这意味着设备可以在闹钟响起后但在您之前进入睡眠状态。Service
有机会获得唤醒锁。
这意味着在这种情况下您的解决方案将“崩溃”。
唯一记录在案的计划AlarmManager
将帮助您完成涉及广播的唤醒锁:
只要警报发生,警报管理器就会保持 CPU 唤醒锁
接收者的 onReceive() 方法正在执行。这保证了
在您处理完广播之前,手机不会休眠。
一旦 onReceive() 返回,警报管理器就会释放此唤醒锁。
这意味着在某些情况下,一旦您的手机进入睡眠状态,手机就会进入睡眠状态。
onReceive() 方法完成。如果您的报警接收器打来电话
Context.startService(),有可能手机会休眠
在启动请求的服务之前。为了防止这种情况发生,您的
BroadcastReceiver 和 Service 需要实现单独的唤醒
锁定策略,确保手机继续运行,直到
服务变得可用。
这是哪里唤醒广播接收器 https://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html非常方便。
请注意,如果您使用此方案,则无需为“UI 启动”情况支持不同的方案 - 在这两种情况下使用相同的方法。
您可能还想看看这个图书馆 https://github.com/commonsguy/cwac-wakeful由@CommonsWare开发(虽然我自己没有使用它)。