试图了解我是否需要WakeLock

免责声明：我的应用程序已经可以在没有任何唤醒锁的情况下运行1年以上，并且所有设备都适用于大多数设备。试图了解我是否需要WakeLock

我跟踪GPS和它的工作原理是这样的：

AlarmReceiver开始每5/10/15分钟（如用户意愿）
服务认购位置更新和等待MAX 1分钟服务良好的GPS。
总结，发送数据到服务器并关闭服务。

由于连接不良和位置不好，整个过程有时需要2-3分钟。它的工作原理。不管电话是否在睡觉。

现在我正在阅读WakeLock，它对我没有意义。我的东西是如何工作的？这是巧合吗？

来源

2012-07-26 katit

啊，是的，经典的问题。 “它有效，但是......它不应该？” – climbage 2012-07-26 23:05:21

我的东西是如何工作的？

事情的组合，包括运气。 :-)

首先，正如Joel指出的那样，设备会短暂地唤醒您的警报，但操作系统只能保证WakeLock的持续时间onReceive()为BroadcastReceiver。

至少在某些版本的Android上，请求GPS更新可能会导致操作系统获得自己的WakeLock。这是AFAIK的无证行为，我从来没有依赖过它。但是，如果它确实如此，并且在删除位置更新之前，您正在完成其余的工作（“总结，发送数据到服务器并关闭服务”），这将解释行为。

您的方法仍然存在潜在的空白（例如，如果您委托Service进行工作，并且没有将WakeLock作为将控制权交给该服务的一部分）。从统计学上讲，它可能会偶尔失败，但需要花费很多时间。

就个人而言，我建议使用WakeLock，以防无证行为发生变化。 That's what I do in LocationPoller。

来源

2012-07-27 00:07:59 CommonsWare

嗯.. :)其实我在调用AsyncTask之前执行'removeUpdates'。但我确实订阅了AsyncTask更新和完成的服务。大约需要5次HTTP调用，因此在调用removeUpdates之后至少需要5秒以上的时间。实际上，我希望你会回答，因为我考虑切换到你的'WakefulIntentService'，因为它更多是我做的。 – katit 2012-07-27 00:52:30

@katit：'WakefulIntentService'不适用于涉及工作的案例，它必须超越'doWakefulWork（）例如从LocationManager异步接收位置。 “觉醒”属性很好，但“IntentService”基础不是。这就是为什么我将'LocationPoller'作为同一个“清醒”概念的例子写在另一种服务中的原因。 – CommonsWare 2012-07-27 10:30:03

那么从AlarmManager文档阅读..

报警管理器，只要报警接收机的onReceive（）方法执行持有CPU唤醒锁。

而且......

注：报警管理器适用于要具有在特定时间您的应用程序代码运行的情况下，即使你的应用程序当前未运行。对于正常的定时操作（ticks，超时等），使用Handler更容易，效率更高。

因此，基于此..我认为它是有道理的，它目前的工作;如我错了请纠正我。

来源

2012-07-26 23:08:41 Joel

试图了解我是否需要WakeLock

回答

相关问题