Question

我正在移植我最初使用IOS 3加速度计编写的应用程序，以整合新的IOS 4运动功能。

在捕捉动作时，应用程序几乎没有其他功能 - 例如，没有图形更新。

我正在执行以下操作来设置动作更新，以替代我之前使用的加速度计。我确实意识到我可以使用NSTimer或其他东西来重建我自己的民意调查，并且可能会继续这样做。

[motionManager setDeviceMotionUpdateInterval:updateInterval]; CMDeviceMotionHandler motionHandler = ^(CMDeviceMotion *motion, NSError *error) { [self processMotion:motion withError:error]; }; [motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:motionHandler];

这样可行，但更新间隔的行为不符合预期。我已经删除了processMotion方法中的所有执行代码，除了保存时间戳以查看真实的动作更新速率。我已经测试了这个足以证明它是可重复的，甚至是1/40的奇怪结果。下表显示了我所看到的内容：

updateInterval  actual events per second
1.0/20.0        13
1.0/30.0        27
1.0/40.0        27
1.0/50.0        34
1.0/60.0        40
1.0/70.0        57
1.0/90.0        60
1.0/100.0      74

一些注意事项：
1.我确定更新间隔设置正确，并在设置确认后进行了检查。

2.我确信我正在跟踪每次调用processMotion，没有使用nil CMDeviceMotion进行任何调用或其他异常情况

3.我没有做任何阻止事情的重要处理，只是等待运动事件并记录它们。作为加速度计的代表，这一切都非常好 4.运动数据很好，只是很少更新:)

5.这是在ipod touch第4代上使用ios 4.2 6.我尽可能地搜索，没有看到解释，虽然我已经看到一些人在申请60hz时看到50hz更新频率的报告，这可能是相关的。

我将尝试的下一件事是为处理而不是使用当前队列设置专用队列，但是我确实想看看这是否是已知行为。我能理解更新率是否会以某种方式出现瓶颈，但不确定为什么它会如图所示仍然按比例放大。

同样，我想我可以重建使用NSTimer并进行自己的轮询，但我想了解为什么我会看到这个，以防我从根本上误解Core Motion框架。

Answer 1

好的，这是一个可能的解决方案：

NSOperationQueue上的并发操作数由操作系统确定。这意味着它有时可以很少甚至一次操作一次。

您可以将操作数明确设置为某个合理的数字，例如

[operationQueue setMaxConcurrentOperationCount:5];

享受。

设备运动更新的实际频率低于预期，但随设置增加

1 个答案: