iPhone/iPad 中的 NSTimer 和加速度计

发布于 2024-09-24 16:47:18 字数 349 浏览 8 评论 0原文

我的应用程序有一个要求，如果应用程序/ipad 上大约 3 小时没有发生任何活动，则需要向用户显示一些消息。我考虑了一个在启动时启动 NSTimer 的解决方案。如果用户执行任何操作，我就会使计时器无效并启动一个新计时器。然而，该应用程序上有视频播放功能，据我所知，用户可能会观看视频大约 3 个小时，并且在此期间没有执行任何其他操作，但仍然会收到消息。

因此，另一种方法是每次检测到 ipad/iphone 移动时使计时器无效并启动计时器。换句话说，使用加速度计并在回调中检测加速度，我可以使计时器无效并再次创建计时器。但我对这种方法的担忧是，即使对于最小的动作，计时器也必须失效并重新创建。这种方法会以任何方式影响性能吗？

谢谢和问候，赫塔尔

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

↘紸啶 2024-10-01 16:47:18

创建一个计时器并不那么昂贵，但还是有点贵。

好消息是您可以任意更改触发日期：

[timer setFireDate:[NSDate dateWithTimeIntervalSinceNow:3*60*60]];

或者，对于稍微更少的开销：（

CFRunLoopTimerSetNextFireDate((CFRunLoopTimerRef)timer, CFAbsoluteTimeGetCurrent()+3*60*60);

我认为 CFAbsoluteTimeGetCurrent() 开销大于对象创建开销，但是，嗯。

）稍微更好的解决方案可能是大部分时间都不使用计时器；只需更新“上次活动”时间戳即可。当计时器触发时，查看“上次活动”时间戳。如果超过 3 小时前，则显示通知。如果距离不到3小时，则适当设置下一次点火日期；这意味着计时器（平均）最多每 1.5 小时触发一次，这可能不如反复更改触发日期那么昂贵。

请参阅 mach_absolute_time() 了解相对较低开销的时基（预先计算 3 小时以 mach_absolute_time 为单位）。它仍然需要大约 3 微秒，这实际上是永远的（1000 个时钟周期！）。

如果您真的担心开销，只需在每次发生事情时设置一个“活动”标志，并使用（例如）1 小时计时器。当计时器触发时，执行类似 if (activity) {counter = 0; 的操作活动= 0； } else { 计数器 ++; if (counter == 3) { ... } }。这里和那里的几微秒是否比每小时触发一次的计时器成本更高，这是有争议的，但它们都是可以忽略不计的。

更大的问题是加速计消耗电力和 CPU 时间（并且提供更新需要 CPU 时间）。设置 updateInterval = 10 左右会减少开销，并且操作系统将其限制为一个合理的值（大约 1 秒）。

Creating a timer is not that expensive, but it's still a little expensive.

The good news is that you can arbitrarily change the fire date:

[timer setFireDate:[NSDate dateWithTimeIntervalSinceNow:3*60*60]];

Alternatively, for very slightly less overhead:

CFRunLoopTimerSetNextFireDate((CFRunLoopTimerRef)timer, CFAbsoluteTimeGetCurrent()+3*60*60);

(I think the CFAbsoluteTimeGetCurrent() overhead is more than the object-creation overhead, but meh.)

A slightly better solution might be to leave the timer alone most of the time; simply update the "last activity" timestamp. When the timer fires, look at the "last activity" timestamp. If it's more than 3 hours ago, thenshow the notification. If it's less than 3 hours ago, then set the next fire date appropriately; this means the timer fires (on average) at most every 1.5 hours, which is probably not as costly as repeatedly changing the fire-date.

See mach_absolute_time() for a relatively low-overhead timebase (pre-calculating what 3 hours is in mach_absolute_time units). It still takes about 3 microseconds, which is practically forever (1000 clocks cycles!).

If you're really worried about overhead, simply set an "activity" flag every time something happens, and use (e.g.) a 1 hour timer. When the timer fires, do something like if (activity) {counter = 0; activity = 0; } else { counter ++; if (counter == 3) { ... } }. It's debatable whether a couple of microseconds here and there are more costly than a timer firing every hour, but they're both pretty negligible.

The far bigger problem is that the accelerometer eats power and CPU time (and delivering updates takes CPU time). Setting updateInterval = 10 or so will reduce the overhead, and it's capped to a sensible value (around 1 s) by the OS.

回复收藏 0 原文