didReceiveMemoryWarning, viewDidUnload y dealloc

Algunas correcciones y sugerencias:

• didReceiveMemoryWarning prácticas

Como dijiste, la implementación predeterminada del controlador de didReceiveMemoryWarning publica su opinión si es 'seguro hacerlo'. Si bien no queda claro en los documentos de Apple qué significa 'seguro hacerlo', generalmente se reconoce que no tiene supervista (por lo tanto, no hay forma de que la vista sea visible actualmente), y loadView El método puede reconstruir la vista completa sin problemas.

La mejor práctica cuando anula didReceiveMemoryWarning es decir, no intentar liberar ningún objeto de vista en absoluto. Simplemente publique sus datos personalizados, si ya no son necesarios. Con respecto a las vistas, deje que la implementación de la superclase se ocupe de ellas.

A veces, sin embargo, la necesidad de los datos puede depender del estado de su vista. En la mayoría de los casos, esos datos personalizados se establecen en viewDidLoad método. En estos casos, "es seguro publicar datos personalizados" significa que sabe que loadView y viewDidLoad se invocará antes de que el controlador de vista vuelva a utilizar los datos personalizados.

Por lo tanto, en tu didReceiveMemoryWarning, llame primero a la implementación de la superclase y, si su vista está descargada, luego libere los datos personalizados porque sabe que loadView y viewDidLoad será invocado de nuevo con seguridad. Por ejemplo,

- (void)didReceiveMemoryWarning {
    /* This is the view controller's method */
    [super didReceiveMemoryWarning];
    if (![self isViewLoaded]) {
        /* release your custom data which will be rebuilt in loadView or viewDidLoad */
    }
}

Tenga cuidado de no utilizar self.view == nil, porque self.view asume que la vista es necesaria para alguien e inmediatamente cargará la vista nuevamente.

• viewDidUnload Método

viewDidUnload se llama cuando el controlador de vista descargado la vista debido a una advertencia de memoria. Por ejemplo, si elimina la vista de la supervista y establece la view propiedad del controlador para nil, viewDidUnload el método será no ser invocado. Un punto sutil es que incluso si la vista de un controlador de vista ya está liberada y configurada como nula cuando el controlador recibe didReceiveMemoryWarning, por lo que en realidad no hay vista para descargar para el controlador, viewDidUnload se invocará si llama a la implementación de la superclase de didReceiveMemoryWarning.

Por eso no es una buena práctica configurar manualmente el view propiedad de un controlador de vista a cero. Si lo hace, es mejor que envíe un viewDidUnload mensaje también. Supongo que tu comprensión de viewDidUnload es más deseable, pero aparentemente no es el comportamiento actual.

• Controladores de vista emergente

Si se refiere a "eliminar de la supervista" mediante "estallar", disminuye el recuento de retención de la vista, pero no necesariamente la desasigna.

Si se refiere a salir de un UINavigationController, en realidad disminuye el recuento de retención del controlador de vista en sí. Si el controlador de vista no es retenido por otro objeto, será desasignado, deseablemente con su vista. Como expliqué, viewDidUnload sí no invocarse esta vez.

• Otros...

Técnicamente, es posible que el recuento de retención no baje a cero. Es más probable que el objeto se desasigne sin establecer el recuento en cero de antemano.

Solo para asegurarse, el controlador de vista en sí normalmente no se desasigna por comportamientos predeterminados debido a la advertencia de memoria.

RecibióMemoriaAdvertencia

...

Acción: libere todo lo que no necesite, que probablemente esté deshaciendo lo que pudo haber configurado en viewDidLoad.

Esto está mal. Todo lo que recreas en viewDidLoad debe liberarse (y establecerse en nil) en viewDidUnload. Como mencionas a continuación, didReceiveMemoryWarning también se llama cuando la vista es visible. En didReceiveMemoryWarning, debe liberar cosas como cachés u otros controladores de vista a los que se aferra que se puedan volver a crear de manera perezosa la próxima vez que se requieran (es decir, implementando su getter manualmente).

verDidDescargar

...

Acción: en general, cualquier IBOutlet que publique en dealloc también debe publicarse (y las referencias se establecen en nil) en este método. Tenga en cuenta que si las propiedades están configuradas para conservar, establecerlas en nil también las liberará.

Correcto. Generalmente, todo lo que crea en viewDidLoad y todos los IBOutlets que se declaran como retain debe liberarse y establecerse en nil aquí.

desalojar

...

Acción: libere todos los objetos que han sido retenidos por la clase, incluidas, entre otras, todas las propiedades con retención o copia.

Correcto. Vale la pena señalar que esto incluye todos los objetos que maneja en viewDidUnload porque este último no se llama implícitamente en el dealloc proceso (AFAIK, no del todo seguro). Por eso es esencial configurar todos los objetos de release en nil in viewDidUnload porque de lo contrario corre el riesgo de lanzar algo dos veces (primero en viewDidUnload, luego otra vez en dealloc; si establece el puntero en nil, la llamada de liberación en dealloc no tendrá ningún efecto).

Controladores de vista emergente y memoria

Pregunta 2: ¿Hacer estallar una vista la elimina de la memoria?

No necesariamente. Ese es un detalle de implementación que no debería preocuparle. Cualquiera que sea la práctica actual, Apple podría cambiarla en la próxima versión.

Solo para actualizar este hilo para que sea relevante para iOS6:

viewDidUnload y viewWillUnload quedaron obsoletos en iOS6. Estos métodos nunca se llaman.

Para conocer este y otros métodos obsoletos, consulte: http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/DeprecationAppendix/AppendixADeprecatedAPI.html

Desde iOS 6 en adelante, cómo podemos verificar si la vista se cargó nuevamente. Dado que "viewDidUnload" está obsoleto. ¿Estás seguro de que "loadView" y "viewDidload" llamarán si la vista se elimina después de la advertencia "didReceiveMemoryWarning"?