El principal problema relacionado con la memoria que aún deberá tener en cuenta es retener los ciclos. Esto ocurre cuando un objeto tiene un puntero fuerte a otro, pero el objeto objetivo tiene un puntero fuerte hacia el original. Incluso cuando se eliminan todas las demás referencias a estos objetos, aún se conservarán entre sí y no se liberarán. Esto también puede ocurrir indirectamente, mediante una cadena de objetos que podría tener el último en la cadena que hace referencia a un objeto anterior.
Es por esta razón que existen los calificadores de propiedad __unsafe_unretained y __weak. El primero no retendrá ningún objeto al que apunte, pero deja abierta la posibilidad de que ese objeto se vaya y señale a la mala memoria, mientras que el último no retiene el objeto y automáticamente se establece en cero cuando su objetivo es desasignado. De los dos, __weak es generalmente preferido en las plataformas que lo soportan.
Utilizaría estos calificadores para cosas como delegados, donde no desea que el objeto retenga su delegado y potencialmente conduzca a un ciclo.
Otro par de preocupaciones importantes relacionadas con la memoria son el manejo de los objetos Core Foundation y la memoria asignada usando malloc() para tipos como char*. ARC no administra estos tipos, solo objetos Objective-C, por lo que aún tendrá que lidiar con ellos usted mismo. Los tipos de Fundamentos básicos pueden ser particularmente complicados, porque a veces deben enlazarse para coincidir con objetos Objective-C, y viceversa. Esto significa que el control debe transferirse de ARC hacia adelante y hacia atrás cuando se realiza un puente entre los tipos de CF y Objective-C. Algunas palabras clave relacionadas con este puente se han agregado, y Mike Ash tiene una gran descripción de varios casos de puente en his lengthy ARC writeup.
Además de esto, hay varios otros casos menos frecuentes, pero aún potencialmente problemáticos, que el published specification entra en detalle.
Gran parte del nuevo comportamiento, basado en mantener objetos alrededor mientras haya un puntero fuerte para ellos, es muy similar a la recolección de basura en la Mac. Sin embargo, los fundamentos técnicos son muy diferentes. En lugar de tener un proceso de recolector de basura que se ejecuta a intervalos regulares para limpiar objetos que ya no se apuntan, este estilo de administración de la memoria se basa en las reglas rígidas de retención/liberación que todos debemos obedecer en Objective-C.
ARC simplemente toma las tareas de administración de memoria repetitivas que hemos tenido que hacer durante años y las descarga al compilador para que no tengamos que preocuparnos por ellas nuevamente. De esta forma, no tiene los problemas de detención o los perfiles de memoria de diente de sierra experimentados en las plataformas recolectadas. He experimentado ambos en mis aplicaciones de Mac recolectadas con basura, y estoy ansioso por ver cómo se comportan bajo ARC.
Para obtener más información sobre la recolección de basura en comparación con ARC, consulte this very interesting response by Chris Lattner on the Objective-C mailing list, donde enumera muchas ventajas de ARC sobre la recolección de basura Objective-C 2.0. Me encontré con varios de los problemas de GC que describe.
Gracias por el detalle respuesta. Tuve el mismo problema cuando definí un delegado en _unsafe_unretained y obtuve mi aplicación bloqueada, más tarde lo solucioné cambiando a fuerte pero ahora tiene una pérdida de memoria. Entonces, lo cambié a débil y funciona como un encanto. – chathuram
@ichathura ¡Guau! Me salvaste del mio ARC. Me encontré con el mismo bloqueo al usar CMPopTipView. – Nianliang
@BradLarson: "no tiene los problemas de detención o los perfiles de memoria de diente de sierra experimentados en las plataformas recolectadas de basura". Esperaría que los perfiles de memoria de diente de sierra y de detención empeoraran por la recuperación basada en el alcance y el rendimiento mucho peor del recuento de referencias, por lo que me gustaría ver una comparación real. –