2010-09-17 7 views
5

Tengo una operación larga O que se llama a través de una NSInvocationOperation, programada en sí misma añadiéndola a un NSOperationQueue para que se ejecute de forma asíncrona. Esa larga operación O se invoca en dos casos diferentes en mi aplicación.Desaceleración importante utilizando NSInvocationOperation (NSOperation) con NSOperationQueue en iOS 4 (iPhone)

En el caso A, se invoca la operación O como resultado de tocar algún widget en alguna vista. Tan pronto como se toca el widget, la operación O se ejecuta por un tiempo (puedo verlo gracias a un UIActivityIndicator), pero no ralentiza o bloquea la interfaz de usuario, por lo tanto, puedo tocar otros widgets y realizar otras operaciones de IU mientras la operación O se está ejecutando.

En el caso B, se invoca la operación O como resultado de recibir una notificación local, en el método didReceiveLocalNotification del delegado de la aplicación. En este caso, las operaciones de IU realizadas justo después de invocar la operación O, mientras todavía están en el método didReceiveLocalNotification, se ralentizan considerablemente, básicamente a un rastreo, casi como si la operación O se hubiera apoderado de la CPU.

¿Por qué? Y ¿cuál sería la forma correcta de invocar la operación O en el caso B, para que se ejecute al mismo tiempo en segundo plano con una prioridad más baja, dejando el resto del código en el método didReceiveLocalNotification para ejecutar en ¿velocidad normal?

NOTA: La Operación O rebusca con notificaciones locales (eliminando las existentes o programando nuevas) y calendarios (consultando el almacén de eventos para programar mejor las notificaciones locales).

Respuesta

0

¿Has probado a disminuir la prioridad de subprocesos?

Esto solo funcionará en iOS 4, pero puede llamar al método setThreadPriority en NSInvocationOperation.

Cuestiones relacionadas