consejos para rastrear la IU de iOS de forma intermitente

Escribí una gran aplicación para iPad hace 2 años y ahora estoy volviendo a ella y actualizándola a iOS5. Es un poco complicado ya que fue mi primera gran aplicación para iPad.consejos para rastrear la IU de iOS de forma intermitente

Tiene un paso de "sincronización" que puede durar varios minutos y se trata de un conjunto de llamadas a métodos asíncronos que van y obtienen JSON de una url y los ingresan en los datos centrales. Con bastante frecuencia, la aplicación se congelará (la IU no responde).

¿Cuáles son algunas buenas técnicas para rastrear este congelamiento? El depurador no es tan útil ya que a menos que el código se esté ejecutando en el hilo principal, no tiene un rastro de pila utilizable. La aplicación a menudo tampoco recupera, lo que sugiere algún tipo de situación de bloqueo.

Aquí es un ejemplo particular que pueda ayudar:

enter image description here

me detuvo la ejecución una vez que comprobó que estaba congelado. Parece congelarse en la misma línea cada vez: una tarea simple. ¿Que esta pasando aqui? Es muy frustrante.

¿Este acceso a los datos centrales está causando esto? Cualquier puntero sería muy apreciado.

EDITAR 29-JUNIO-2012

Click here para ver la fuente de la clase que hace todo el Crear/actualizar/eliminación de objetos de datos básicos. Solo necesito detener el congelamiento/bloqueo en esta aplicación. Sé que es un desastre, me da vergüenza también. Lo escribí hace 2 años sin apenas conocimiento de objetivo-c. Debería volver a escribirlo, pero tengo que hacerlo funcionar y fuera de mi cabeza en 2 días. ¿Alguien podría darme consejos sobre los enfoques para obtener este thread-safe rápidamente? ¿Podría envolver cada método que actualiza NSManagedObjectContext en el código de bloque de despacho de grand central?

Fuente

2012-06-06 Mike S

Cuando la UI deja de responder, se debe a que está ejecutando código en el hilo principal que debe ejecutarse en segundo plano. Puedes intentar pausar la aplicación durante este bloqueo y con suerte obtener un seguimiento de pila útil en el hilo principal ... pero probablemente no lo harás. La única forma que he encontrado realmente útil en este escenario es ser realmente crítico con el código que está ejecutando y dónde. Comprueba todas tus solicitudes web y el código relacionado de sincronización, y en cualquier otro lugar que creas que puede ser un proceso intenso. – Matt

Otra idea (en lugar de detenerse en el depurador y esperar lo mejor) podría ser ejecutar la aplicación en Instrumentos, que le dirá qué métodos están usando más tiempo. Lo encontré muy útil para depurar precisamente estos problemas. –

Actualicé una pregunta con un enlace a la fuente, si eso ayuda. –

Es posible que Core Data (en combinación con multihilo) sea la causa de sus problemas. Experimenté problemas similares.

He aquí un excelente artículo sobre este tema: Core Data and threads, without the headache

También veo una llamada a performSelector: en su seguimiento de la pila. Es posible que desee considerar utilizar Grand Central Dispatch, aunque podría ser mucho para reescribir en su caso.

En cuanto a su pregunta real (rastreando interbloqueos), le sugiero que también use Instrumentos. Además, observe el estado de los otros hilos.

Fuente

2012-06-28 12:32:06

¿Entonces también tenía problemas de congelación? –

Sí, tuve problemas de congelación, así como un comportamiento extraño en general (y algunos bloqueos). Todo esto podría resolverse reduciendo el uso de datos básicos al hilo principal, pero probé el enfoque en el artículo mencionado en un proyecto de prueba, y funciona (con varios hilos). –

Usted dijo:

El depurador no es tan útil como menos que el código se ejecuta en el hilo principal , usted no tiene ninguna traza de la pila utilizable.

Esto no es cierto. Obtiene rastros de pila para todos los hilos.

El hecho de que se congela en la misma línea cada vez sugiere que hay un problema con esa línea.Esto es lo que está haciendo:

self.friendObj.affiliations = friendObject1.affiliations;

Por lo tanto, me gustaría poner un punto de interrupción en esa línea y cuando Xcode se detiene en el punto de interrupción, analizar la memoria de friendObj1. Quizás hay algo funky pasando.

¿Existe un método "setAffiliations:" personalizado en la clase de friendObj? Quizás de alguna forma se esté produciendo un ciclo infinito en esa línea.

Analizaría todas las llamadas para establecer la propiedad de "afiliaciones" de su friendObj y trataría de determinar dónde está su error.

Otra idea: ¿es friendObj un objeto de Datos básicos? Si es así, debe inicializarse en un ManagedObjectContext.

Fuente

2012-06-29 00:13:58

No, no hay un método de configuración de afiliación personalizado. Es solo una cadena @propiedad. friendObject1 es un objeto de coredata que tiene un error cuando depuro. Sin embargo, no estaba demasiado alarmado porque escuché que los objetos de datos centrales pueden estar en estado de "falla" si todavía no se han resuelto por completo. –

Si friendObj es un NSManagedObject (objeto de datos del núcleo) debe inicializarse usando [NSEntityDescription insertNewObjectForEntityForName: @ "ClassName" enManagedObjectContext: myManagedObjectContext] –

friendObj NO es un NSManagedObject - friendObj1 IS embargo. –

consejos para rastrear la IU de iOS de forma intermitente

Respuesta

Cuestiones relacionadas