iOS: utilidad de didReceiveMemoryWarning:

Si el usuario deja abrir algunas aplicaciones que tendrá muy poca memoria a su disposición. Así que a veces didReceiveMemoryWarningpuede ser llamado por el sistema sólo después de 1 MB de uso.

El sistema llama a este método en todos los controladores de vista, si se coloca un NSLog en cada uno de sus controladores de vista, se puede observar que.

Entonces automáticamente el método viewDidUnloadserá llamado por el sistema en todos sus controladores de vista (no dealloc). Así que hay que poner todas sus instrucciones desasignación allí.

Usted tiene que hacer un montón de experimentos porque si su aplicación es compleja que se enfrentará a muchas caídas antes de administrar bien.

ACTUALIZACIÓN A partir de iOS 6, las UIViewControllervistas ya no se descargan en respuesta a las advertencias de memoria. En lugar de eso, solo haga lo posible por liberar cualquier recurso que pueda recrear de manera razonable (por ejemplo, datos almacenados en caché) cuando didReceiveMemoryWarningse llame.

ACTUALIZACIÓN
Escribí mi respuesta original cuando era un joven enojado; los tiempos han cambiado y, básicamente, está mal.

Si tiene una aplicación con un controlador de vista única y recibe una advertencia de memoria, no hay mucho que pueda hacer. Pero las cosas cambian dramáticamente si tiene múltiples controladores de vista, porque puede descargar todo el estado asociado con los controladores que no son frontales. De hecho, [UIViewController didReceiveMemoryWarning]lo empujará en la dirección correcta descargando sus vistas no visibles para usted (¡sorpresa!). Cuando se descarta el controlador de vista frontal, la vista subyacente se vuelve a cargar y, como máximo, el usuario solo debe tener en cuenta una demora, aunque internamente su aplicación haya realizado un reinicio completo.

Este no es un detalle que pueda actualizar fácilmente, debe tener en cuenta el uso de la memoria desde el principio y diseñar su aplicación multivista en UIViewControllerpiezas que se pueden descargar de forma limpia . De hecho, vale la pena mantener el código compatible con el simulador solo para utilizar su función de advertencia de memoria.

Cuando la memoria es abundante, no se descarga nada y todo se suaviza, y cuando la memoria es baja las cosas siguen funcionando, aunque más lentamente. Ahora diría que esta solución para el problema de la memoria finita es ideal.

Para aprovechar este truco de la sala de memoria, sobrecargue los UIViewControllermétodos viewDidLoad, viewDidUnloady viewWillUnload(iOS5, útil si el estado de descarga requiere que su vista siga existiendo, por ejemplo, si no desea filtrar las texturas OpenGL y el búfer de renderizado, en iOS4 puede simular esto al sobrecargar didReceiveMemoryWarningy rastrear la visibilidad de su vista).

RESPUESTA ORIGINAL Y MÁS BILIA

didReceiveMemoryWarning es absolutamente inútil

No hay garantía de que si liberas memoria (incluso toda) no te maten.

En mi amarga experiencia, generalmente funciona así en 2.x / 3.0:

1. mediaserverd pierde un montón de memoria

2. mi aplicación es asesinada

Desafortunadamente, el segador nunca piensa en matar a mediaserverd.

Entonces, si el uso de la memoria no es su culpa, realmente solo tiene dos opciones:

1. Pídale al usuario que reinicie (el usuario asume que es su culpa, escribe una revisión mordaz)

2. ¡Espero que el culpable se cuelgue (mediaserverd a menudo obliga!)

El objetivo de didReceiveMemoryWarning es brindarte la oportunidad de liberar vistas de memoria o pop para evitar un bloqueo. No lo recibirá en ningún punto predecible porque depende de lo que esté haciendo el usuario. Por ejemplo, si el usuario está escuchando el iPod, hay menos memoria disponible y la recibirá antes.

La regla general es que tiene alrededor de 8 MB de RAM para trabajar. Cuando te acercas a eso, puedes esperar que el evento se eleve. Si está ocupando esa cantidad de RAM deliberadamente, debe tener un plan para hacer algo al respecto.