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

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代

6 上使用ios 4.2 .我尽力搜索,避风港没有看到解释,虽然我已经看到一些人在申请60hz时看到50hz更新频率的报告,这可能是相关的.

我将尝试的下一件事是为处理而不是使用当前队列设置专用队列,但我确实想看看这是否是已知行为.我可以理解更新速率是否会以某种方式出现瓶颈,但不确定为什么它仍然可以扩展,如果是这样的话.

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

Answer 1

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

并发操作的数量NSOperationQueue由操作系统决定。这意味着有时一次只能进行很少的操作，甚至一次操作 1 次。

您可以显式地将操作数量设置为某个合理的数量，例如

[operationQueue setMaxConcurrentOperationCount:5];

享受。