哪些事件可以唤醒正在睡眠的 Android 设备？
我正在编写一个 Android 客户端应用程序，它使用 HTTP 长轮询（Comet）不断接收来自服务器的推送通知。
我不想总是保留 WakeLock，因为它会耗尽电池，但我需要确保设备即使处于睡眠模式也能收到通知。
我发现了这个问题：
其中“CommonsWare”提到非 Wifi 套接字上的传入数据包将唤醒设备。
所以我的解决方案看起来像这样：
Client ------------------------- Server
---- Request----->
release WakeLock (Allow device to sleep)
<----Notification-- (Hopes it can wake up the device)
require WakeLock
process the notification
---- Request----->
release WakeLock
....
但是在接收通知和需要唤醒锁之间有一点时间窗口，所以我的问题是，设备将保持这种唤醒状态多长时间？设备是否可以在这段时间内重新进入睡眠状态？
I am writing a Android client app which keeps receiving push notifications from a server using HTTP long-polling(Comet).
I don't want to always keep WakeLock since it will drain battery, but I need to make sure the device can receive notification even when it is in sleep mode.
And I found this question:
Android: Sleep stages/levels on an Android device?
where "CommonsWare" mentioned that an incoming packet on a non-Wifi socket will wake up the device.
So my solution looks like this:
Client ------------------------- Server
---- Request----->
release WakeLock (Allow device to sleep)
<----Notification-- (Hopes it can wake up the device)
require WakeLock
process the notification
---- Request----->
release WakeLock
....
But there is a little time window between receiving the notification and requiring the wakelock, so my question is, how long will the device keep this awake state? Is it possible for the device to back to sleep during this time window?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
设备将处于唤醒状态足够长的时间，以便在
BroadcastReceiver中执行一些简短的代码。我无法找到确切的毫秒数，但想法是，在您的接收器中，您应该获取继续进行自己的处理所需的任何WakeLock。然而，
WakeLock的精确管理可能很棘手。我建议使用@CommonsWare的WakefulIntentService：The device will be awake for long enough to execute some short code in the
BroadcastReceiver. I have not been able to find an exact number of millis, but the idea is that in your receiver, you should grab whateverWakeLockyou need to proceed with your own processing.However exact management of the
WakeLockcan be tricky. I recommend using @CommonsWare'sWakefulIntentService: