Frequenza effettiva degli aggiornamenti del movimento del dispositivo inferiore al previsto, ma ridimensiona con l'impostazione

Question

Sto portando un'app che originariamente ho scritto usando l'accelerometro per iOS 3, per incorporare le nuove funzionalità di movimento iOS 4.

Durante l'acquisizione del movimento, l'applicazione fa poco altro - nessun aggiornamento grafico ad esempio.

Sto facendo quanto segue per impostare gli aggiornamenti del movimento, come sostituzione del mio precedente utilizzo dell'accelerometro. Mi rendo conto che potrei ricostruire per fare il mio sondaggio usando Nstimer o qualcosa del genere, e potrebbe perseguire così.

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

[motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:motionHandler];

Questo funziona, ma l'intervallo di aggiornamento non si comporta come previsto. Ho spogliato tutto il codice di esecuzione nel metodo Processmotion, ad eccezione del salvataggio dei timestamp per vedere quale è la velocità di aggiornamento del movimento reale. Ho testato questo abbastanza da dimostrare a me stesso che è ripetibile, anche lo strano risultato per 1/40. La tabella seguente mostra ciò che sto vedendo:

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

.

Alcune note:
1. Sono sicuro che l'intervallo di aggiornamento viene impostato correttamente e lo ha controllato dopo l'impostazione per confermare.

2. Sono sicuro che sto monitorando ogni chiamata di Processmotion, non ci sono chiamate con Nil cmDevicemotion o altre stranezza

3. Non sto facendo alcuna elaborazione significativa che bloccherebbe le cose, aspettando solo gli eventi di movimento e registrarli. Tutto questo ha funzionato perfettamente bene come delegato per l'accelerometro

4. I dati di movimento sono buoni, solo troppo raramente aggiornati :)

5. Questo sta usando iOS 4.2 su un iPod Touch 4th Gen

6. Ho cercato il meglio che posso, non ho visto una spiegazione, anche se ho visto alcuni rapporti di persone che vedono la frequenza di aggiornamento 50Hz quando si richiede 60Hz, che potrebbe essere correlata.

La prossima cosa proverò a creare una coda dedicata per l'elaborazione invece di utilizzare la coda corrente, tuttavia volevo vedere se questo era un comportamento conosciuto. Potevo capire se il tasso di aggiornamento è stato con bottiglia di bottiglia in qualche modo, ma non è sicuro del motivo per cui sarebbe ancora scalabile come mostrato se quello era il caso.

Ancora una volta, suppongo di poter ricostruire di usare Nstimer e fare il mio sondaggio, ma mi piacerebbe capire perché sto vedendo questo, nel caso in cui io sia fondamentalmente fraintendendo il quadro di movimento principale.

Answer 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.