设备运动更新的实际频率低于预期，但随设置放大 [英] Actual frequency of device motion updates lower than expected, but scales up with setting
问题描述
我正在移植一个应用程序，我最初使用加速度计为IOS 3，结合新的IOS 4运动功能。
I am porting an app that I originally wrote using the accelerometer for IOS 3, to incorporate the new IOS 4 motion capabilities.
捕获运动时，应用程序
我执行以下操作来设置运动更新，以替代我以前使用的加速度计。我真的意识到，我可以重建使用NSTimer或其他东西做自己的投票，并可能追求。
I'm doing the following to set up motion updates, as a replacement for my previous use of the accelerometer. I do realize that I could rebuild to do my own polling using NSTimer or something, and may pursue that yet.
[motionManager setDeviceMotionUpdateInterval：updateInterval];
CMDeviceMotionHandler motionHandler = ^（CMDeviceMotion * motion，NSError * error）{
[self processMotion：motion withError：错误];
};
[motionManager startDeviceMotionUpdatesToQueue：[NSOperationQueue currentQueue] withHandler：motionHandler];
这样工作，但是更新间隔的行为不如预期。我删除了processMotion方法中的所有执行代码，除了保存时间戳以查看真正的运动更新速率。我测试了这足够证明自己，它是可重复的，即使是1/40的奇怪的结果。下表显示了我看到的内容：
This works, but the update interval doesn't behave as expected. I've stripped out all execution code in the processMotion method, except for saving off timestamps in order to see what the real motion update rate is. I've tested this enough to prove to myself that it's repeatable, even the strange result for 1/40. The table below shows what I'm seeing:
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.运动数据很好，只是太少更新:)。 。这是使用ios 4.2 on一个ipod触摸第四个基于_b $ b 6.我搜索最好的我可以，没有看到一个解释，虽然我看到一些报告的人看到50hz更新频率，请求60hz，这可能是相关的。
Some notes:
1. i'm sure that the update interval is being set properly, and have checked it after setting to confirm.
2. I'm sure that I'm tracking every call of processMotion, there aren't any calls being made with nil CMDeviceMotion or other strangeness
3. I'm not doing any significant processing that would block things, just waiting on motion events and recording them. This all worked perfectly fine as a delegate for the accelerometer
4. the motion data is good, just too infrequently updated :)
5. this is using ios 4.2 on an ipod touch 4th gen
6. I've searched as best I can, haven't seen an explanation, though i have seen some reports of people seeing 50hz update frequency when requesting 60hz, which could be related.
接下来我会尝试设置一个专用队列处理而不是使用当前队列，然而我确实想看看这是否是已知的行为。我可以理解，如果更新率是瓶颈的某种方式，但不知道为什么它仍然会按比例放大如果是这样的情况。
再次，我想我可以重建使用NSTimer并做我自己的投票，但我想知道为什么我看到这个，如果我从根本上误解核心运动框架。
The next thing i'll try is setting up a dedicated queue for the processing instead of using the current queue, however I did want to see if this was a known behavior. I could understand if the update rate was bottlenecked somehow, but not sure why it would still scale up as shown if that was the case.
Again, I suppose I could rebuild to use NSTimer and do my own polling, but I'd like to understand why i'm seeing this, in case i'm fundamentally misunderstanding the Core Motion framework.
推荐答案
好的，这里有一个可能的解决方案：
Okay, here's a possible solution:
NSOperationQueue 由OS。这意味着它有时可能非常少甚至一次操作。
Number of concurrent operations on NSOperationQueue are determined by the OS. That means it sometimes can be very few or even 1 operation at a time.
您可以将操作数明确设置为某个合理的数字，例如
You can explicitly set the number of operations to a certain reasonable number, e.g.
[operationQueue setMaxConcurrentOperationCount:5];
享受。
这篇关于设备运动更新的实际频率低于预期，但随设置放大的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
