¿Todavía se requieren los methods 'dealloc' y 'viewDidUnload' al usar ARC, pre-iOS6?

Trabajo como parte de un gran equipo que trabaja en el código henetworkingado de iOS con un entorno iOS de destino de 4.3 y posterior. He visto a otros desarrolladores comprobar las classs que descienden de NSObject pero no tienen un método dealloc . También he visto UIViewController que no incluyen los methods viewDidUnload . Cuando le pregunto sobre este código, la respuesta habitual es "No te preocupes, ARC se encarga de eso ahora".

Entiendo que viewDidUnload se viewDidUnload cuando iOS experimenta condiciones de baja memory, con el objective de liberar memory al liberar objects que se pueden volver a crear llamando a viewDidLoad , y que se llama a dealloc cuando el recuento de retención de un object llega a cero. Para los objects y descendientes de UIViewController, esto puede significar que 'viewDidUnload' puede o no ser dealloc antes de dealloc .

Así que aquí está mi pregunta: ¿ dealloc methods dealloc y viewDidUnload todavía son necesarios cuando se usa ARC en versiones de iOS anteriores a iOS 6?

Si la respuesta es " ¡Sí! ", Necesitaré buenas razones y / o documentation para llevar a cabo la discusión.

Esperando tus respuestas. (Con gracias a Tommy por ayudarme a endurecer mi pregunta.)

viewDidUnload está en desuso . Entonces, independientemente de ARC, no solo no necesitas uno, sino que no lo uses. La justificación establecida es que las vistas no se purgan con advertencias de baja memory (presumiblemente porque ahora contribuyen muy poco al total para que valga la pena el éxito de respuesta); No me sorprendería si parte de la justificación fuera que mucha gente suponía que podían liberar todos los resources creados en viewDidLoad dentro de viewDidUnload y eso solo evitaría las fugas. Eso no es cierto porque viewDidUnload se llama solo si la vista se descarga debido a una advertencia de memory baja . No se llama en el ciclo de vida normal.

Según las nuevas reglas de ARC :

Puede implementar un método dealloc si necesita administrar resources que no sean liberar variables de instancia. No tiene que (de hecho no puede) liberar variables de instancia

EDITAR: comentar sobre 4.3+ específicamente …

ARC no implementará una versión de viewDidUnload para usted. El punto del ciclo viewDidLoad / viewDidUnload era que si retain cualquier parte de la jerarquía de la vista por cualquier motivo, hará que no se libere automáticamente con una advertencia de poca memory, pero al hacerlo no le comprará ningún beneficio porque tan pronto como la vista se cargue a continuación, todo lo que haya retenido se replaceá con una copy nueva. Entonces, si tiene IBOutlet strong para las vistas que están dentro de la jerarquía debajo de self.view todos modos, lo ideal sería que las viewDidUnload durante viewDidUnload . Incluso si tiene references weak es un buen lugar para evitar adelantarse a cualquier puntero.

A partir de iOS 5, puede tener references débiles de viewDidUnload lo que viewDidUnload y no implementar viewDidUnload sería el path a seguir si estuviera soportando más de 5. Para 4.3 si utiliza references fuertes y omite viewDidUnload , puede terminar impidiendo una respuesta tan minuciosa a una advertencia de memory baja como a Apple le gustaría, pero no perderá memory. Si utiliza references débiles, necesitará tener un poco de cuidado al no hacer reference a ninguno de esos objects en momentos en los que puede que no tenga una vista (es decir, en cualquier momento en que no esté en pantalla pero la vista haya cargado previamente en el controller que también ajusta una vista, pero que se ven afectados por otro, son un ejemplo clásico, como por ejemplo, si actualizas un campo mediante observación de valores key).

Puede usar la "Simulación de advertencia de memory" del simulador para probar y depurar esas cosas hasta cierto punto.

El dealloc que ARC proporciona será el mismo independientemente de la versión de iOS. Sin embargo, solo cubrirá objects Objective-C. Cuando dicen que no pueden liberar variables de instancia, lo quieren decir en el sentido literal de enviarles el post de release . Supongamos que tiene objects de Core Foundation o ha realizado una asignación de memory C pura, entonces querrá implementar un dealloc que disponga de todos esos.

Obviamente, la herramienta Instrumentos y Fugas es la forma de probar y depurar esa área; tenga cuidado cada vez que se filtre la memory para verificar si el tipo de object que creó esa memory también se está filtrando. El object inmediato puede estar bien, pero sus asignaciones aparecerán en la list filtrada si no lo hizo porque otro lo filtró.

viewDidUnload ahora está en desuso y ya no es invocado por el sistema (a partir de iOS 6). Nunca fue tan útil como Apple esperaba, y fue más problema de lo que valía la pena. Esto no tiene nada que ver con ARC.

dealloc menudo, no se requiere dealloc en ARC, pero aún es necesario en situaciones donde necesita gestión de resources no ARC. Por ejemplo, si necesita usar free() recurso free() o de otro modo, libere un recurso. También es un buen lugar para eliminarse como observador o delegado. Pero muchas classs ahora no requieren dealloc .