ARC no libera memory cuando se "retrocede" en el controller de navigation, y está ralentizando mi uipageviewcontroller

Parte de la aplicación en la que estoy trabajando implica un UIPageViewController, donde cada página muestra una 'input' que se almacena en los Datos básicos. Una input incluye, entre otras cosas, algunas imágenes que se están comprimiendo y almacenando como NSData. Por lo tanto, para cargar estas imágenes y mostrarlas en una página, estoy usando imageWithData, es decir

photo.image = [UIImage imageWithData:entry.photo]; 

El problema es que imageWithData no es particularmente rápido, por lo que voltear páginas no es tan receptivo como me gustaría. Mi mejor bash para remediar esta situación ha sido precargar una cantidad de controlleres de vista que mi UIPageViewController muestra en una matriz. (No estoy seguro si eso es lo mejor que puedes hacer, pero ahí lo tienes)

Por lo tanto, para aclarar, tengo un controller de navigation, que contiene viewControllerA, que luego se vincula a viewControllerB, que muestra el UIPageView y el inputControllers (un controller de input en cada página). El problema es que cuando uso la barra de navigation para retroceder desde viewControllerB para verControllerA, quiero que la matriz viewControllerB de entryControllers se libere de la memory. Pero, ARC no parece estar haciendo eso. Por lo tanto, después de ir y venir entre viewControllerA y viewControllerB varias veces, girando unas páginas cada vez, empiezo a get advertencias de memory, lo que termina borrando la matriz actual de controlControllers, y anula el objective de tener ese array, ya que Las inputs tienen que volverse a cargar cada vez que recibo una advertencia de memory.

En resumen, ARC no está borrando ninguna de las memorys que he asignado para viewControllerB cuando vuelvo a verControllerA a través de mi controller de navigation. No me gusta eso. Si alguien puede sugerir una razón por la que esto está sucediendo, o me avisa si estoy hablando de todo esto de la manera incorrecta, sería muy apreciado. ¡Solo estoy tratando de acelerar la transición de una página a la siguiente!

Gracias un montón.

La única razón por la que ARC no libera su memory es que todavía la está reteniendo en alguna parte. Solo tú sabes dónde está eso.

Por lo general, esto se debe a un ciclo de retención, que puede ocurrir fácilmente con bloques.

Sin embargo, es tan probable que mantenga un puntero al object en algún lugar, en un controller, un iVar o alguna colección.

¿Has ejecutado el analizador estático en tu código? Es bastante bueno para encontrar algunas de esas cosas.

¿Qué te dicen los instrumentos? Tiene algunas herramientas para encontrar fugas y retener ciclos.

EDITAR

Puede tener tantas references a cualquier object que desee. Una vez que el recuento se pone a cero, se liberará.

El problema es que tiene una serie de pointers fuertes para ver los controlleres como un caching. Si quieres que se publiquen, tienes que apuntar manualmente esos pointers. De alguna manera, estás cargando previamente los controlleres en una matriz. Se mantendrán con vida hasta que los descargues.

Entonces, mientras tengas un puntero fuerte a algo, se mantendrá cerca.

La edición de Jody, mencionando específicamente los indicadores de ajuste a cero, fue lo que me ayudó en términos de comprensión, y al final pude resolver mi problema al establecer ciertos indicadores a cero cuando mi "viewControllerB" desapareció. En el path, sin embargo, también me di count de otro punto importante: las imágenes grandes en los datos centrales son una gran carga de memory, y en iOS 5, esto se puede remediar estableciendo una opción para permitir el almacenamiento externo. De modo que para cualquier otra persona que sea relativamente principiante como yo y pueda encontrarse con un problema de memory similar, esta es una forma key de limitar la cantidad de memory que ingieren los objects administrados que almacenan grandes cantidades de datos: sus imágenes (o la gran cantidad de datos ) se guardan en el file automáticamente, sin que tenga que hacer nada diferente en el código.