didReceiveMemoryWarning y viewDidUnload

Question

desde la Guía de programación del controlador de vista Apple/Gestión eficaz de la memoria;

didReceiveMemoryWarning

Utilice este método para anular la planificación de todas las estructuras de datos personalizados no críticos asociados con el controlador de vista. Aunque no usaría este método para liberar referencias para ver objetos, puede usarlo para liberar cualquier estructura de datos relacionada con vistas que no haya publicado en su método viewDidUnload. (La vista objetos mismos siempre deben ser liberados en el método viewDidUnload.)

viewDidUnload

Usted puede utilizar el método viewDidUnload a liberar cualquier información que es específica de la vista y que se puede recrear con bastante facilidad si el ver se carga en la memoria de nuevo. Sin embargo, si la recreación de los datos puede consumir demasiado tiempo, no es necesario que libere los objetos de datos correspondientes aquí. En su lugar, debería considerar liberar esos objetos en su método didReceiveMemoryWarning.

http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html

1. Para didReceiveMemoryWarning, que se recomiendan para cancelar la asignación de estructuras de datos no críticos. Entonces, ¿qué es crítico y qué no es crítico?

2. Además, dice lanzar lo que no lanzamos en viewDidUnload. Pero cuando hay una advertencia de memoria que se llama aReceiveMemoryWarning y se puede descargar la vista, se invoca viewDidUnload. Entonces, ¿está hablando de mover esos códigos al método del evento anterior (didReceiveMemoryWarning) o me falta algo sobre el orden de los eventos?

3. Para viewDidUnload, se nos recomienda cuidar fácilmente recreando los datos al volver a cargar una vista. Entonces, si una vista está en uso y no se pudo descargar, ¿por qué vamos a lanzar datos que consumen mucho tiempo en didReceiveMemoryWarning? Después de esos datos publicados, cuando el usuario intenta hacer algo dentro de la vista actual, también llevará mucho tiempo cargarlos.

Answer 1

En primer lugar, estos son sólo directrices, por lo que si usted no cree que es de sentido común para liberar algo en didReceiveMemoryWarning entonces no lo haga. Pero tenga en cuenta que si su aplicación es la que está causando la advertencia de memoria en primer lugar, finalmente terminará con el sistema operativo.

Re (1): crítico frente a no crítico es totalmente su llamada. Solo usted realmente puede determinar qué datos está reteniendo que considera críticos. Aunque probablemente va a estar estrechamente relacionado con su (3), es decir, algo que se puede recrear fácilmente probablemente no sea demasiado crítico.

Re (2): No creo que la declaración se haga en referencia al orden de las llamadas. Como se habrá dado cuenta, en general, se llamará al viewDidUnload después de didReceiveMemoryWarning (desde didReceiveMemoryWarning puede llamarse al viewDidUnload). Como ejemplo, en viewDidUnload, se liberarán las referencias guardadas a los elementos UI de un plumín. Por lo tanto, no los libere en didReceiveMemoryWarning.

Re (3): Si una vista está en uso y por lo tanto no se puede descargar, entonces sí, obviamente no tiene mucho sentido soltarla en didReceiveMemoryWarning. Sin embargo, es posible que tenga instancias en las que una vista no se pueda descargar, pero se sepa que no estará visible (no terriblemente normal), en cuyo caso podría tener sentido descargar sus datos y volver a crearlos cuando la vista sea visible una vez más .

Además, estoy de acuerdo con las observaciones "En su lugar, debería considerar ..." son un poco extrañas, pero una vez más creo que el punto de recomendar los datos se publica en didReceiveMemoryWarning proviene del hecho de que si los está recibiendo advertencias, entonces su propia aplicación podría estar en peligro de ser cancelada. Entonces, aunque actualmente es el caso de que viewDidUnload se llame siempre como resultado de una advertencia de memoria, puede que no siempre sea el caso en el futuro y, por tanto, conceptualmente tiene más sentido publicar los datos en didReceiveMemoryWarning. En didReceiveMemoryWarning SABE que hay presión de memoria, en viewDidUnload no es posible. Entonces, si bien es cierto que los datos serán costosos de recrear, podría ser mejor que terminar su aplicación. Para el usuario, parecerá que la aplicación se bloqueó.

Mi propio enfoque personal a esos métodos es generalmente esto:

• viewDidUnload - Release cualquier referencia a elementos de interfaz de usuario cargados desde una punta. Libere todos los elementos de la interfaz de usuario que creé en viewDidLoad.
• didReceiveMemoryWarning - Libere todos los datos que se utilizan en la presentación de la interfaz de usuario que puedo recrear si/cuándo se llama de nuevo viewDidLoad (o algún otro evento específico de la aplicación). NO liberes nada que no sea posible recrear.

Answer 2

Las aplicaciones que estoy construyendo son intensivas en gráficos, tanto en términos de diseño chrome, como en las imágenes asociadas con los datos que descargo y visualizo.

Mis métodos didReceiveMemoryWarning SOLAMENTE son para determinar qué imágenes tengo en la memoria pero no se muestran actualmente, y soltarlas de la memoria. La otra parte de eso es, debes verificar antes de mostrar una imagen si todavía está alrededor, y cargarla de manera lenta si no es así.