setNeedsDisplay, drawRect o CALayer causando dispatch_continuation_alloc_from_heap fuga de memory malloc iOS

Estoy experimentando una pérdida de memory en mi aplicación y parece provenir de CALayer. Parece que solo afecta iPads antiguos; Veo el problema con iPad 1 y 2, pero iPad Air está bien. Tengo un informe de locking de un iPad 1 que muestra que mi aplicación fue 'expulsada' debido a la falta de memory, esta fuga es mi principal sospechoso.

Fondo

Durante la operación setNeedsDisplay se invoca continuamente cada 40 ms por el hilo de networking en varias UIViews para actualizar sus visuales, consulte la function a continuación.

- (void)setNeedsRepaint { [self performSelectorOnMainThread:@selector(setNeedsDisplay) withObject:nil waitUntilDone:NO]; } 

Simulando iPad2 y usando el instrumento de asignaciones, veo que cada vez que se establece setNeedsDisplay, el recuento de reference de malloc 64 aumenta de forma permanente. La biblioteca responsable es libdispatch.dylib y la persona que llama es dispatch_continuation_alloc_from_heap.

El simulador iPad Air no muestra este problema, en este caso el recuento de reference malloc 32 solo aumenta temporalmente.

Estoy viendo que el número de reference de malloc 64 aumenta incluso en ocasiones en que setNeedsDisplay se origina en el subprocess de GUI y no se envía a través de performSelectorOnMainThread.

A continuación se muestra una captura de pantalla del instrumento de asignación. El malloc marcado como 3 es la fuga en cuestión. Los mallocs marcan 1 y 2 fugas mucho más lento, pero siguen siendo una pequeña preocupación.

Asignaciones de captura de pantalla del instrumento

Pasos tomados

Para descartar una pérdida de memory en drawRect, comenté todo el código entre las llaves, pero la memory filtrada sigue acumulándose.

Si no anulo el método drawRect, no veo la fuga, pero lo necesito para dibujar y actualizar mi vista. Tampoco lo veo si no se llama setNeedsDisplay, puedo llamar a una function ficticia en su lugar a través de performSelectorOnMainThread sin pérdida de memory.

He intentado usar bloques y dispatch_async en lugar de performSelectorOnMainThread para ejecutar setNeedsDisplay en el subprocess GUI.

También intenté networkingucir la aplicación para que setNeedsDisplay solo se invocara repetidamente en una sola vista. Luego, eliminando todos los pointers a esa vista, ARC lo limpia con la esperanza de que los mallocs callejeros puedan limpiarse con él.

He intentado configurar los contenidos de CALayer directamente en lugar de llamar a setNeedsDisplay. Se muestra, pero el conteo de malloc aumenta exactamente de la misma manera.

 self.layer.contents = (__bridge id) _dummyCGImageRef; 

Después de leer esto , pensé que la fuga podría deberse a que la queue se inundó. Sin embargo, la ralentización de la tasa de llamadas de mi function en 10 hizo que la pérdida de memory crezca 10 veces más lentamente.

Conclusiones

La fuga realmente parece estar vinculada a CALayer en lugar de la queue de despacho y performSelectorOnMainThread. Parece que este problema se solucionó en iPads posteriores, pero todavía necesito una solución para models anteriores.

Preguntas

¿Alguien tiene algún consejo para depurar esto?

¿Es otro instrumento más adecuado para encontrar la causa exacta?

¿Es esto una peculiaridad del simulador y lo que estoy viendo no es la razón por la que mi aplicación se deshace?

Alguien sabe lo que está causando esto? ¿Se trata de un error histórico ya que no afecta a iPad Air?

¿Hay un truco de subsorting que podría hacer con CALayer para evitar que la tienda de respaldo asigne memory, o de otra manera actualizo mis imágenes visuales?

Gracias.