¿Cómo puedo eliminar la memoria sucia residente en Objective-C?

Question

Vi el video WWDC 2010 de Apple sobre Análisis avanzado de memoria con instrumentos y, a partir de eso, pude encontrar mucha memoria sucia residente. Me doy cuenta de que tener tanta memoria sucia residente es algo malo (y probablemente la explicación de que mi aplicación se cuelgue tanto ...), pero no estoy seguro de cómo solucionarlo. ¿Dónde debería mirar?

Instrumentos me muestra una gran cantidad de información potencialmente útil que se parece a un galimatías para mí, como por ejemplo:

% of Res Type      Resident Size 
18%  VM_ALLOCATE (8192 pages) 32.00 MB 

Esto está en la categoría de "sucio" - 32 MB de memoria sucia residente es mucho en una dispositivo que solo tiene 256 MB, ¿verdad? :) Hay varios trozos más grandes como este. ¿Cómo puedo rastrear esto a mi código desde Instruments? ¿O debería olvidarme de los instrumentos y buscar problemas específicos en mi código?

Answer 1

¿Ves este fragmento de 32 MB de VM_ALLOCATE cuando corriendo en el dispositivo o en el simulador?

Pregunto porque cuando jugué con el instrumento de asignaciones en la aplicación OS X en la que estoy trabajando, también noté un fragmento de 32 MB de VM_ALLOCATE y me pregunto si esto es un subproducto de la ejecución en el entorno OS X Ejecutar en el dispositivo puede darle un conjunto de datos diferente.

En general, sin embargo, la memoria residente es la memoria que utiliza su aplicación que no se intercambia en el disco. En iOS, no hay intercambio, por lo que la memoria residente debe ser igual a la huella de memoria virtual.

La memoria sucia es la memoria que ha asignado y utilizado. La memoria sucia debe ser menor que la memoria residente porque esta última incluye código (tuyo y marcos).

No estoy seguro exactamente de lo que está haciendo en su aplicación, pero supongo que ha cargado algunos activos grandes de su paquete y los mantiene cerca. No hagas esto, cuando sea posible.

También hay API que puede utilizar al cargar objetos NSData que utilizan una técnica de asignación de memoria en lugar de lectura de bytes de fuerza bruta. Esto puede ser mejor porque permite que el sistema operativo lea las páginas del disco de forma perezosa. Con NSData (dado que no es mutable), también podría ser lo suficientemente inteligente como para marcar las páginas como de solo lectura. Teóricamente, esta es una pista valiosa para el sistema operativo que puede purgar esas páginas cuando está bajo presión, ya que sabe que no puede cambiar. Lea los documentos para +[NSData dataWithContentsOfMappedFile:].

Para las imágenes, recuerdo haber leído algo que sugería evitar imageNamed: a excepción de las imágenes que usabas regularmente a través de tu aplicación (es decir, elementos de la IU). Especialmente para imágenes grandes, pueden permanecer en un caché sobre el que no tienes control. (imageNamed: tenía una fuga en el 2.x días, pero se corrigió en 3.x y es perfectamente seguro de usar hoy en día.) Use imageWithContentsOfFile: para obtener imágenes más grandes e imágenes que no sean una parte recurrente de su UI.

Si carga imágenes de la red, guárdelas en el disco y libere los bytes sin procesar después de crear el UIImage. Si las vistas de la imagen están descargadas debido a la presión de la memoria, no desea presionar la red para cargar los datos nuevamente, pero tampoco desea mantener dos copias (una NSData y la UIImage) cargadas.

Answer 2

Con el nuevo xCode 4, las herramientas procedentes de xCode 3 siguen estando allí con una mejor interfaz de usuario para crear un perfil de su aplicación, incluidas las fugas y el uso de la memoria. Te recomendaría que revises esas herramientas y corras una por una para ver qué te proporcionan. Puede acceder a estas herramientas en Xcode 4 en el menú principal y luego Producto -> Perfil

Esperanza esto ayuda

Answer 3

En instrumentos haga clic en Habilitar instantáneas automáticamente Cambiar vista a modo de regiones mapa. Busque en los nombres de ruta de los archivos, que está usando mientras su aplicación vive en vmpages y después cuando lo borre. En video, ejemplo de wwdc, estaban usando encriptación para archivo y esto fue empujarlo a vmpages, sin codificar demasiado para sugerir algo más que [limpieza de biblioteca] :-)

Answer 4

"Esto es en el 'sucio' categoría - 32 MB de memoria residente sucia ..." "También me di cuenta de un trozo de 32 MB de VM_ALLOCATE y me pregunto ..."

veo el mismo "VM_ALLOCATE (8192 páginas) 32 MB" para columnas residentes, sucias y virtuales en el rastreador de VM cuando perfilo mis aplicaciones en el simulador.

Para la comparación, he perfilado los (pequeños) aplicaciones de demostración construidos de Paul Hegarty de muy informativo supuesto iTunes U Stanford - por ejemplo, Psicóloga y la calculadora gráfica - y ver la misma entrada en cada uno.

Soy un "chico de dominio" y aún no tengo una comprensión sólida de los detalles de la gestión de la memoria, por lo que no puedo ofrecer una explicación autorizada, pero parece razonable concluir que esta asignación se debe a los elementos del Marco común a todas las aplicaciones se ejecutan en el Simulador. (No he corrido en un dispositivo.)

(FYI: Xcode 4.3 en un funcionamiento 10.7.3 MacBook Pro)