Como un nuevo desarrollador de Objective-C, ¿qué problemas relacionados con la memoria debo tener en cuenta al usar ARC?

Question

Recientemente comencé a codificar en Objective-C para dispositivos iOS 5. Mi nueva MacBook está cargada con Xcode 4.2 y los últimos SDK de iOS Mac &. Hasta ahora ha sido una experiencia divertida, pero hay un problema que veo con el estado actual de la documentación y los libros disponibles.

Específicamente, la mayoría de los libros (que aún deben actualizarse) siempre hacen referencia a cómo y cuándo administrar su memoria. Esto es genial, sin embargo, el SDK/compilador actual incluye el recuento automático de referencias y, como lo dejo activado para mis proyectos, no tengo ni idea de qué debo supervisar y administrar personalmente.

Vengo de un fondo C#. La gestión de la memoria en C# (técnicamente, .NET) está totalmente gestionada por el recolector de elementos no utilizados. Entiendo que ARC es en realidad una función de compilación que agrega automáticamente el código de la placa de caldera a donde pertenece. Además, mis intentos de tratar de descubrir dónde debo administrar mi propia liberación de objetos no han causado más que errores en el compilador porque ARC quiere encargarse de eso.

Todavía tengo que encontrar un caso donde he necesitado para administrar mis objetos. Me estoy volviendo "perezoso" porque no sé qué controlar y liberarme y soy completamente ajeno a cómo este comportamiento podría afectar el rendimiento de mi aplicación.

En términos de usuario nuevo, ¿qué "errores" debería tener en cuenta al usar ARC en mis proyectos de iOS? He leído algunas preguntas sobre la administración de memoria y ARC por aquí, pero para ser sincero, no son amigables con el nuevo desarrollador de iOS. ¿Podría alguien proporcionar una lista de puntos clave razonable que explique qué problemas y cuestiones hay que tener en cuenta, así como una guía imparcial sobre cuándo es necesaria la autogestión de la memoria?

Answer 1

• Referencias circulares. Cuando los objetos son codependientes, tendrán fugas. Deberá marcar algunas referencias como débiles e Instrumentos puede ayudarlo a localizar estas referencias. Estas filtraciones ni siquiera aparecerán como fugas porque tienen fuertes referencias entre sí.

• Crea reservas automáticas @autorelease para mantener los tamaños del conjunto de autorreleases donde creas muchos objetos liberados automáticamente (directa o indirectamente). Específicamente, su programa y los programas de los que depende serán autorelease muchos objetos (ARC u otros). Un objeto lanzado automáticamente es uno que se lanzará "en el futuro". Cada programa de Cocoa espera que exista un pool de autorrelease en cada hilo. Esta es la razón por la que crea un grupo nuevo cuando crea un nuevo hilo, y por qué crea uno en main. Las piscinas funcionan como una pila; puede empujar y hacer estallar piscinas. Cuando se destruye un grupo, envía su mensaje diferido release a cada objeto que contiene. Esto significa que los bucles realmente grandes con muchas asignaciones temporales pueden dar como resultado muchos objetos a los que el grupo hace referencia, y el conjunto puede crecer mucho. Por esta razón, drene los pools de administración directamente en algunos casos para minimizar el número de objetos que están esperando ser liberados y desasignados.

• Use puenteo/fundición adecuado. A veces necesitarás administrar las vidas útiles de forma explícita. ARC maneja los casos obvios, pero existen casos complejos en los que tendrá que administrar vidas de forma explícita.

• Al usar malloc 'ed y new' ed asignaciones, así como tipos opacos en 'Core' API. ARC solo administra NSObject tipos. Aún necesita liberar explícitamente, eliminar y usar recuentos de ref correctamente para estas asignaciones, tipos y cuando interactúe con esas API.

• Siempre siga las convenciones de nomenclatura NS-API, y avoid explicit memory management attributes where possible.

• Obviamente necesitará MRC cuando compile fuentes sin ARC o GC. Esto es bastante común cuando se usan/trabajan con otras bibliotecas/cuerpos de códigos. Por supuesto, el compilador maneja las interacciones correctamente para que su programa ARC no tenga fugas.

• ARC maneja más lo que necesitará si utiliza nombres adecuados y estilo escrito, pero habrá algunos otros casos de esquina. Afortunadamente, aún puedes ejecutar Leaks and Zombies para localizar estos problemas si no los realizas durante el desarrollo.