问题
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.
回答1:
Okay, here's a possible solution:
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];
Enjoy.
来源：https://stackoverflow.com/questions/5034411/actual-frequency-of-device-motion-updates-lower-than-expected-but-scales-up-wit