设备运动更新的实际频率低于预期，但会随着设置而增加
我正在移植一个最初使用 IOS 3 的加速度计编写的应用程序，以纳入新的 IOS 4 运动功能。
在捕捉运动时，应用程序几乎不执行任何其他操作 - 例如，不进行图形更新。
我正在执行以下操作来设置运动更新，以替代我之前使用的加速度计。我确实意识到我可以重建以使用 NSTimer 或其他东西进行自己的轮询，并且可能会继续这样做。
<代码> [motionManager setDeviceMotionUpdateInterval:updateInterval];
CMDeviceMotionHandler 运动处理程序 = ^(CMDeviceMotion *运动, NSError *错误) {
[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. 这是在第 4 代 iPod touch 上使用 ios 4.2
6. 我已尽我所能进行搜索，但没有看到解释，尽管我看到一些报告称人们在请求 60hz 时看到 50hz 更新频率，这可能是相关的。
接下来我'我会尝试设置一个专用队列来进行处理，而不是使用当前队列，但是我确实想看看这是否是已知的行为。我可以理解更新率是否存在某种瓶颈，但不确定为什么它仍然会按比例放大，如果是这种情况的话。
再次，我想我可以重建以使用 NSTimer 并进行自己的轮询，但我想了解为什么我会看到这个，以防我从根本上误解了 Core Motion 框架。
I am porting an app that I originally wrote using the accelerometer for IOS 3, to incorporate the new IOS 4 motion capabilities.
While capturing motion, the application does little else - no graphics updates for example.
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:error];
};[motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:motionHandler];
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
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好的，这是一个可能的解决方案：
NSOperationQueue上的并发操作数由操作系统决定。这意味着有时一次只能进行很少的操作，甚至一次操作 1 次。您可以明确地将操作数量设置为某个合理的数量，例如
Enjoy。
Okay, here's a possible solution:
Number of concurrent operations on
NSOperationQueueare 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.
Enjoy.