Ho una lunga operazione O che viene chiamata tramite NSInvocationOperation, programmata essa stessa aggiungendola a NSOperationQueue in modo che venga eseguita in modo asincrono. Quella lunga operazione O è invocata in due casi diversi nella mia app.Rallentamento principale con NSInvocationOperation (NSOperation) con NSOperationQueue su iOS 4 (iPhone)
Nel caso A, l'operazione O viene richiamata come risultato del tocco di alcuni widget in una vista. Non appena il widget viene toccato, l'operazione O viene eseguita per un po '(lo vedo grazie a UIActivityIndicator), ma non rallenta o blocca l'interfaccia utente, quindi sono in grado di toccare altri widget ed eseguire altre operazioni dell'interfaccia utente mentre l'operazione O è in esecuzione.
Nel caso B, l'operazione O viene richiamata in seguito alla ricezione di una notifica locale, nel metodo didReceiveLocalNotification del delegato dell'app. In questo caso, le operazioni dell'interfaccia utente eseguite subito dopo aver richiamato l'operazione O, mentre si trovavano ancora nel metodo didReceiveLocalNotification, sono considerevolmente rallentate, fondamentalmente a una scansione, quasi come se l'operazione O avesse preso il controllo della CPU.
Per quale motivo, e quale sarebbe il modo corretto di richiamare l'operazione O nel caso B, in modo che venga eseguito contemporaneamente in background con priorità più bassa, lasciando il resto del codice nel metodo didReceiveLocalNotification da eseguire in un velocità normale?
NOTA: L'operazione O si comporta con le notifiche locali (rimuovendo quelle esistenti o programmandone di nuove) e calendari (interrogando l'archivio eventi per pianificare meglio le notifiche locali).