尝试理解是否需要使用WakeLock

Question

免责声明：我的应用程序已经在没有任何唤醒锁的情况下运行了1年以上，并且对于大多数设备来说一切都很好。

我正在跟踪GPS，它的工作原理如下：

1. AlarmReceiver每5/10/15分钟（根据用户需求）启动服务。 2. 服务订阅位置更新，并等待最多1分钟以获取良好的GPS信号。 3. 包装数据，发送到服务器并关闭服务。

由于连接不佳和位置不准确，整个过程有时需要2-3分钟。但是它仍然可以正常工作，无论手机是否处于睡眠状态。

现在我正在了解唤醒锁，但我不明白它的意义。为什么我的东西能够正常工作？这是巧合吗？

- katit

---

啊，经典问题。 “它能工作，但是……它不应该？” - Mike Park

Answer 1

我的东西怎么会工作？

这是一系列因素的结合，其中包括一点运气。:-)

首先，正如Joel所指出的那样，设备由于闹钟而短暂地唤醒，但是操作系统只保证在BroadcastReceiver的onReceive()期间持有WakeLock。

可能，在某些Android版本上，请求GPS更新会导致操作系统获取自己的WakeLock。据我所知，这是未经记录的行为，我个人从未依赖过它。如果确实如此，并且您在删除位置更新之前完成了其余工作（“Wrap up，send data to server and shut down service”），那么这就可以解释这种行为。

您的方法仍然存在潜在的漏洞（例如，如果您委托一个Service来执行工作并且没有持有WakeLock作为将控制权传递给该Service的一部分）。从统计学角度来看，它可能偶尔会失败，但大多数情况下都能正常工作。

个人建议使用 WakeLock，以防未记录的行为发生变化。这就是我在 LocationPoller 中所做的。

- CommonsWare

---

嗯.. :) 实际上在调用AsyncTask之前我会执行removeUpdates。但是我会订阅AsyncTask的更新和完成服务。需要进行5次HTTP调用，因此在调用removeUpdates后至少需要5秒钟。实际上，我希望您能回答，因为我正在考虑切换到您的WakefulIntentService，因为它更符合我的需求。 - katit

@katit：WakefulIntentService 不适用于需要持续工作的情况，例如从 LocationManager 异步接收位置信息。 "wakeful" 属性很好，但是 IntentService 基础不太适合。这就是为什么我编写了 LocationPoller，作为同一种不同类型服务中相同“wakeful”概念的示例。 - CommonsWare

Answer 2

好的，根据AlarmManager文档的阅读..

只要闹钟接收器的onReceive()方法正在执行，闹钟管理器就会持有CPU唤醒锁。

进一步地...

注意：闹钟管理器适用于您希望在特定时间运行应用程序代码的情况，即使您的应用程序当前未运行。对于正常的定时操作（滴答声、超时等），使用Handler更容易且更有效率。

因此，基于这个理由...我认为它目前可以工作；如果我错了，请纠正我。

- Joel