2012-06-21 16 views
5

Tengo una pregunta rápida sobre ARC en iOS. (Perdón por haber hecho muchas de estas preguntas, pero estoy tan confundido con respecto a la administración de la memoria). Es importante tener en cuenta que nunca he usado el viejo sistema de mantenimiento de memoria (retain, release, assign ... etc.) así que no sé realmente qué significan esos términos.¿Cuándo se lanzan las propiedades fuertes en ARC en iOS?

En este momento estoy confundido con respecto a lo que tengo que hacer para asegurarme de que las propiedades fuertes se liberen correctamente. Por ejemplo, supongamos que estoy haciendo una aplicación de la escuela y mi objeto School contiene fuertes referencias de propiedad a 5 objetos diferentes Child (no en una matriz). Cada objeto Child tiene un puntero fuerte (propiedad) a un objeto Book.

Si elimino uno de los objetos Child de mi escuela (digamos haciendo su propiedad = cero, o cambiando mi propiedad para apuntar a un nuevo objeto), ¿se liberará correctamente su Book? ¿Qué debo hacer para asegurarme de que este sea el caso? ¿Debo escribir self.myBook = nil en un método dealloc? ¿Qué pasa si Child fuera un Controlador de vista, tendría que escribir self.myBook = nil en el método viewDidUnload?

Me estoy enfocando solo en iOS 5 (y versiones posteriores), por lo que la forma anterior de administración de memoria realmente no me importa.

+0

Sugiero que lea esto: http://clang.llvm.org/docs/AutomaticReferenceCounting.html –

+0

Gracias por la sugerencia. Lo echaré un vistazo. – Nosrettap

Respuesta

5

Si quito uno de los objetos Child de mi escuela (por ejemplo al hacer su property = nil, o cambiando mi propiedad para apuntar a un nuevo objeto), será su Book ser liberado correctamente?

Sí, se lanzará mientras no haya otras referencias sólidas al respecto.

¿Qué debo hacer para asegurarme de que este es el caso?

Nada en particular: ARC disminuirá recuento referencia del objeto cuando se establece la referencia a ese objeto a nil, ver que el objeto ya no se hace referencia, y proceder a eliminarlo. Es lo suficientemente inteligente como para tratar los elementos a los que se hace referencia desde el objeto que se va a eliminar, recursivamente, para que no se pierda ningún tipo de memoria.

Una cosa que hay que preocuparse es referencias circulares: si su Book tiene un fuerte respaldo referencia a Child, o bien hacer que la referencia weak o borrarla a cabo al mismo tiempo que se establece su referencia de Book a nil (la segunda opción es propensa a errores, y por lo tanto no se recomienda).

+0

¿Diría entonces que, en su mayor parte, el único momento para usar 'propiedades débiles' es para los puntos de venta y para evitar las dependencias circulares? – Nosrettap

+0

@Nosrettap Evitar las referencias circulares y, hasta cierto punto, el almacenamiento en caché, son los dos "casos paraguas" que cubren el uso de propiedades débiles. Un caso especial importante que vale la pena mencionar por separado son las propiedades que representan a los delegados: con la notable excepción de 'CAAnimation', todas las propiedades delegadas son débiles para evitar la creación de ciclos de retención. – dasblinkenlight

+0

Si hay un ciclo de referencia, no puede "borrarlo en -dealloc", porque nunca se llamará a dealloc (a menos que sea el desglose de un método que posea ambos miembros del ciclo) –

Cuestiones relacionadas