Comprensión del conteo de referencia con Cacao y Objective-C

Si entiendes el proceso de retain/release, entonces hay dos reglas de oro que son "duh" obvias para los programadores de Cocoa establecidos, pero desafortunadamente rara vez se explican claramente para los recién llegados.

1. Si una función que devuelve un objeto tiene alloc, create o copy en su nombre entonces el objeto es tuyo. Debe llamar [object release] cuando haya terminado con él. O CFRelease(object), si es un objeto Core-Foundation.

2. Si NO tiene una de estas palabras en su nombre entonces el objeto pertenece a otra persona. Debe llamar a [object retain] si desea mantener el objeto después del final de su función.

Usted estaría bien servido para seguir también esta convención en las funciones que usted mismo crea.

(Nitpickers: Sí, desafortunadamente hay algunas llamadas API que son excepciones a estas reglas, pero son raras).

Si está escribiendo código para el escritorio y puede apuntar a Mac OS X 10.5, al menos debe buscar el uso de Objective-C garbage collection. Realmente simplificará la mayor parte de su desarrollo - es por eso que Apple puso todo el esfuerzo en crearlo en primer lugar, y hacer que funcione bien.

En cuanto a las reglas de gestión de memoria cuando no se utiliza GC:

• Si se crea un nuevo objeto usando +alloc/+allocWithZone:, +new, -copy o -mutableCopy o si -retain un objeto, usted está tomando propiedad de la misma y debe asegurarse de que se envía -release.
• Si recibe un objeto de cualquier otra manera, usted es no el propietario del mismo y debe no asegurarse de que se envía -release.
• Si desea asegurarse de que se envía un objeto -release puede enviarlo usted mismo, o puede enviar el objeto -autorelease y el actual autorelease pool lo enviará -release (una vez por recibido -autorelease) cuando se agote el grupo.

Típicamente -autorelease se usa como una forma de asegurar que los objetos vivan durante la duración del evento actual, pero se limpien después, ya que hay un grupo de autorelease que rodea el procesamiento de eventos de Cocoa. En Cocoa, es mucho más común devolver objetos a un llamador que son autoreleased que devolver objetos que el mismo llamador necesita liberar.

Objective-C usa Recuento de referencia, lo que significa que cada Objeto tiene un recuento de referencia. Cuando se crea un objeto, tiene un recuento de referencia de "1". En pocas palabras, cuando se hace referencia a un objeto (es decir, almacenado en algún lugar), se "retiene", lo que significa que su recuento de referencias se incrementa en uno. Cuando un objeto ya no es necesario, se "libera", lo que significa que su recuento de referencia se reduce en uno.

Cuando el recuento de referencia de un objeto es 0, el objeto se libera. Esto es básico conteo de referencias.

Para algunos idiomas, las referencias se incrementan y disminuyen automáticamente, pero objective-c no es uno de esos idiomas. Por lo tanto, el programador es responsable de retener y liberar.

Una forma típica de escribir un método es:

id myVar = [someObject someMessage];
.... do something ....;
[myVar release];
return someValue;

El problema de tener que recordar liberar cualquier recurso adquirido dentro del código es tedioso y propenso a errores. Objective-C introduce otro concepto dirigido a hacer esto mucho más fácil: Autorelease Pools. Los pools de autorelease son objetos especiales que se instalan en cada hilo. Son una clase bastante simple, si buscas NSAutoreleasePool.

Cuando un objeto recibe un mensaje de "autorelease" enviado a él, el objeto buscará cualquier grupo de autorelease que se encuentre en la pila para este hilo actual. Agregará el objeto a la lista como un objeto para enviar un mensaje de "liberación" en algún momento en el futuro, que generalmente es cuando se libera el grupo en sí.

Tomando el código anterior, usted puede reescribirlo para que sea más corto y fácil de leer diciendo:

id myVar = [[someObject someMessage] autorelease];
... do something ...;
return someValue;

Debido a que el objeto es autoreleased, ya no necesitamos llamar explícitamente a "release" en él. Esto se debe a que sabemos que algún grupo de autorelease lo hará por nosotros más tarde.

Esperemos que esto ayude. El artículo de Wikipedia es bastante bueno sobre el conteo de referencias. Puede encontrar más información sobre autorelease pools aquí. También tenga en cuenta que si está compilando para Mac OS X 10.5 y versiones posteriores, puede decirle a Xcode que compile con la recolección de basura habilitada, lo que le permite ignorar completamente retain/release/autorelease.

Joshua (#6591) - El material de recolección de basura en Mac OS X 10.5 parece bastante genial, pero no está disponible para el iPhone (o si desea que su aplicación se ejecute en versiones anteriores a la 10.5 de Mac OS X).

Además, si estás escribiendo una biblioteca o algo que podría ser reutilizado, usando el modo GC bloquea a cualquiera que use el código también usando el modo GC, así que según lo entiendo, cualquiera que intente escribir código ampliamente reutilizable tiende a administrar la memoria manualmente.

Como siempre, cuando las personas comienzan a tratar de volver a escribir el material de referencia, casi invariablemente obtienen algo mal o proporcionan una descripción incompleta.

Apple proporciona una descripción completa del sistema de gestión de memoria de Cocoa en Memory Management Programming Guide for Cocoa, al final de la cual hay un breve pero preciso resumen de las Reglas de Gestión de Memoria .

No voy a añadir a la específica de retain / release aparte de que es posible que desee pensar en dejar caer $50 y obtener el libro Hillegass, pero me gustaría sugerir encarecidamente entrar en el uso de las herramientas de Instrumentos muy temprano en el desarrollo de su aplicación (incluso su primera!). Para ello, Ejecute - > Start with performance tools. Comenzaría con Fugas que es solo uno de muchos de los instrumentos disponibles, pero le ayudará a mostrar cuando se ha olvidado de liberar. Es desalentador dejar de cuánto información que se le presentará. Pero echa un vistazo a este tutorial para levantarse y ir rápido:
TUTORIAL DE COCOA: ARREGLAR FUGAS DE MEMORIA CON INSTRUMENTOS

En realidad tratar de forzar fugas podría ser una mejor manera de, a su vez, aprender cómo prevenirlas! Buena suerte ;)

Matt Dillard escribió :

Return [[s autorelease] release];

Autorelease hace no retener el objeto. Autorelease simplemente lo pone en cola para ser lanzado más tarde. Usted no quiere tener una declaración de liberación allí.

Mi colección habitual de artículos de gestión de memoria de cacao:

Gestión de memoria de cacao

Hay un screencast gratuito disponible en la red iDeveloperTV

Gestión de memoria en Objective-C

La respuesta de NilObject es un buen comienzo. Aquí hay información adicional relativa a la gestión manual de memoria (requerido en el iPhone ).

Si usted personalmente alloc/init un objeto, viene con un recuento de referencia de 1. Usted es responsable de limpiar después de que ya no es necesario, ya sea llamando [foo release] o [foo autorelease]. release lo limpia de inmediato, mientras que autorelease agrega el objeto al grupo de autorelease, que lo liberará automáticamente en un momento posterior.

Autorelease es principalmente para cuando tienes un método que necesita devolver el objeto en cuestión ( así que no puedes liberarlo manualmente, de lo contrario devolverás un objeto nil) pero tampoco quieres aferrarte a él.

Si adquiere un objeto al que no llamó alloc/init para obtenerlo {por ejemplo:

foo = [NSString stringWithString:@"hello"];

Pero si desea aferrarse a este objeto, debe llamar a [foo retain]. De lo contrario, es posible que obtendrá autoreleased y usted se aferra a un referencia nula (como en el ejemplo anterior stringWithString ). Cuando ya no lo necesite, llame a [foo release].

Las respuestas anteriores dan claras reafirmaciones de lo que dice la documentación; el problema con el que se topan la mayoría de las personas nuevas son los casos indocumentados. Por ejemplo:

• Autorelease : los documentos dicen que activará una versión "en algún momento en el futuro."¿CUÁNDO?! Básicamente, puede contar con que el objeto esté alrededor hasta que salga de su código de nuevo en el bucle de eventos del sistema. El sistema PUEDE liberar el objeto en cualquier momento después del ciclo de eventos actual. (Creo que Matt dijo que, antes.)

• Cadenas estáticas: NSString *foo = @"bar"; -- ¿tienes que retener o liberar eso? No. ¿Qué tal

  -(void)getBar {
      return @"bar";
  }
  

  ...

  NSString *foo = [self getBar]; // still no need to retain or release
  

• La Regla de Creación: Si la ha creado, es suya y se espera que la libere.

En general, la forma en que los nuevos programadores de Cocoa se confunden es al no entender qué rutinas devuelven un objeto con un retainCount > 0.

Aquí hay un fragmento de Reglas Muy Simples Para la Administración de Memoria En Cacao:

Reglas de recuento de retención

• Dentro de un bloque dado, el uso de-copy, -alloc y-retain debe ser igual al uso de-release y-autorelease.
• Los objetos creados usando constructores de conveniencia (por ejemplo, stringWithString de NSString) se consideran autoreleased.
• Implementar un método-dealloc para liberar las instancevariables que posee

La primera bala dice: si llamaste alloc (o new fooCopy), necesitas para llamar a la liberación de ese objeto.

La segunda viñeta dice: si usas un constructor de conveniencia y necesitas que el objeto se cuelgue (como con una imagen que se dibujará más tarde), necesitas retenerlo (y luego liberarlo).

El 3er debe explicarse por sí mismo.

Mucha información sobre cocoadev también:

• MemoryManagement
• Reglas de Thumb

Como ya han mencionado varias personas, la Introducción de Apple a la Gestión de la Memoria es, con mucho, el mejor lugar para comenzar.

Un enlace útil que aún no he visto mencionado es Gestión Práctica de la Memoria. Lo encontrarás en medio de los documentos de Apple si los lees, pero vale la pena hacer enlaces directos. Es un brillante resumen ejecutivo de las reglas de gestión de la memoria con ejemplos y errores comunes (básicamente lo que otras respuestas aquí están tratando de explicar, pero no como bien).