每 10 秒获取一次 PARTIAL_WAKELOCK
以 10 秒间隔获取部分唤醒锁的应用程序是否存在任何问题。我的用例是能够通过设备加速计持续监控用户的运动。基本上，我有一个服务，每 10 秒由警报调用一次。
该服务获取唤醒锁，从加速度计获取一些读数以确定当前的运动状态，然后释放唤醒锁。服务的总生命周期约为 4 秒。
我的理解是，这会导致设备每分钟保持唤醒状态约 24 秒。虽然并不理想，但我希望这仍然是比在应用程序的整个生命周期中保持恒定唤醒锁更好的做法。
另一方面，在如此短的时间内获取和释放唤醒锁的行为是否可能对电池寿命同样不利？
任何意见都会受到赞赏。
Is there any problem with an application which acquires a partial wake lock at 10 second intervals. My use-case for this is being able to continually monitor the user's movement via the device accelerometer. Basically, I have a Service which is invoked by an alarm every 10 seconds.
This Service acquires a wake lock, gets some readings from the accelerometer to determine current movement status, and then releases the wake lock. The total lifetime of the service is around 4 seconds.
My understanding is that this leads to the device being kept awake for approx 24 seconds in each minute. While not ideal, I would hope that this is still better practice than holding a constant wake lock for the entire lifetime of my application.
On the other hand, is it possible that the act of acquiring and releasing the wake lock in such a short space of time is just as bad for battery life?
Any input is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如评论所表明的，这确实不是一个好主意。就像“市场上的一星评级”那样，这不是一个好主意。
加速度计设计用于跑步活动（例如游戏），仅此而已。它绝对不是为您正在尝试的模式而设计的。
您还假设设备将在您释放
WakeLock后立即重新进入睡眠状态。这可能是真的，也可能不是。我怀疑您会发现您导致 CPU 开启的时间明显超过 40% 的可用时间，即使您只要求 CPU 开启 40%。我强烈建议您查看 Jeff Sharkey 关于 2009 年 Android 电源使用情况的演示Google I|O 大会。
As the comments have indicated, this is really not a good idea. As in "one-star ratings on the Market" type of a not-good idea.
The accelerometer is designed to be used by a running activity (e.g., a game), and that's about it. It is absolutely not designed to be used in the mode in which you are trying.
You are also assuming that the device will fall back asleep immediately upon your release of the
WakeLock. That may or may not be true. I would suspect that you will find that you are causing the CPU to be powered on for significantly more than 40% of the available time, even if you are only mandating it to be on for 40%.I strongly encourage you to view Jeff Sharkey's presentation on power usage in Android from the 2009 Google I|O conference.
您使用过 MyTracks 应用程序吗？ http://code.google.com/p/mytracks/
上次我检查过，他们使用当用户有活动路径时的唤醒锁。
我和你有同样的问题 - 虽然我不想使用唤醒锁，但如果操作系统一路杀死应用程序，我的应用程序就会被毁掉。目前我们正在这样做，但代价是每小时大约损失 10% 的电池寿命 - 这并不是那么糟糕。这当然不是很好，但我们的平均路径只有大约 20 分钟。它有效。
使用警报管理器似乎确实是更好的途径。有什么关于如何在这种情况下使用它的好例子吗？
Have you ever used the app MyTracks? http://code.google.com/p/mytracks/
Last I checked, they use a wake lock when the user has an active path.
I have the same issue as you - and while I'd prefer not using a wake lock, my app is ruined if the OS kills the app along the way. Right now we're doing so, at the expense of about 10% battery life per hour - which isn't all that bad. It's certainly not great, but our average path is only about 20 minutes. And it works.
Using the Alarm Manager does seem like a better route. Any good examples of how to use it for this sort of situation?