【问题标题】:battery conservation and AlarmManager performance电池保护和 AlarmManager 性能
【发布时间】:2013-12-16 21:08:28
【问题描述】:

我有一个包含多个线程的服务组件(由活动启动并始终运行)的单进程应用程序。我需要一个应用程序重复暂停(深度睡眠)7 秒,然后在很短的时间内启动加速度计(加速度计在收集 20 个样本后停止)以节省电池。它必须在所有 android 平台上运行,最好在 2.3 以上。

我的第一种方法是在服务组件中使用基于 Handler 的 sendMessageDelayed 方法(延迟 = 7 秒)在加速度计停止后调用,而不获取部分唤醒锁。但是在我看来这不是一个好方法,因为计时器仅在手机未睡着时才计算滴答声(如果我错了或有解决此问题的方法,请在此处纠正我)。

我的第二种方法与第一种方法相同,但在调用 sendmesssageDelayed 之前获取了部分唤醒锁。它工作正常,但电池消耗过多。

所以这里有几个问题:

  1. 我应该使用 AlarmManager 每 7 秒触发一次广播吗?我担心的是 7 秒对于 AlarmManager 来说太短了,因为它在相当长的时间内在内部获取了部分唤醒锁。我想知道是否有人对 AlarmManager 获取唤醒锁的最长时间进行了性能分析,或者有其他方法。我读过其他帖子说 AlarmManager 是有效的解决方案,但它在很长一段时间内特别有用。

  2. 如果必须使用 AlarmManager,我能否使用服务组件中作为公共静态字段维护的唤醒锁对象在广播接收器中获取部分唤醒锁(以便从应用程序中的任何其他组件轻松访问)?

  3. 另外,从广播接收器访问和使用基于处理程序的对象以通知服务线程收到警报广播是否存在任何问题? (处理程序对象在服务组件中作为静态公共字段维护,因此可以从应用程序中的任何其他组件轻松访问)。

非常感谢您的帮助

【问题讨论】:

  • 解决了吗?如果是 - 你能写下你的解决方案作为答案吗?

标签: android handler alarmmanager battery wakelock


【解决方案1】:

如果您使用始终运行的服务,则无需使用 Alarmmanager。处理程序更容易。每 7 秒很多,你确定要这样吗?我的意思是,如果您提到“电池保护”?保持服务运行是昂贵的,不是对服务本身而言,而是对使用果汁的保持清醒的事物而言。

【讨论】:

  • 感谢您的评论。我在想我需要 AlarmManager,因为我确实想暂停服务运行 7 秒,然后用部分唤醒锁启动它。不幸的是,我需要部分唤醒锁,否则加速度计不会产生好的结果。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-23
  • 2020-10-24
  • 2011-06-06
  • 2012-08-20
相关资源
最近更新 更多