La memoria sucia de ImageIO no se borra automáticamente con iOS

memory-management memory-leaks

Question

Estoy creando una aplicación que es un tipo de galería: muestra diferentes contenidos multimedia como un visor de pantalla completa. El instrumento de asignaciones muestra que el parámetro Live Bytes no crece más de 40 Mb al usar la aplicación. Mientras tanto, la aplicación se está matando al 100% después de deslizar las páginas 20-30 veces. Revisé el parámetro de la memoria sucia y descubrí que era 10 veces más grande que el tamaño de los bytes en vivo. Y la mayor parte de esa memoria sucia consumió Image IO:

Captura de pantalla http://i40.tinypic.com/25ge51i.jpg

EDITAR, otra captura de pantalla:

Captura de pantalla http://i40.tinypic.com/9t1mh5.png

Los picos de asignación anteriores están cambiando el contenido de video / imagen. El problema es que la memoria sucia crece casi linealmente y necesito liberarla de alguna manera.

Ahora sobre el diseño de aplicaciones. La pantalla de aplicación tiene una vista de desplazamiento horizontal. La vista de desplazamiento contiene videos u objetos de collage que contienen múltiples imágenes. Para ahorrar memoria, solo se crean tres páginas a la vez: la página actual y las páginas a la izquierda / derecha. Por lo tanto, las páginas siempre se crean y eliminan sobre la marcha al deslizar la vista de desplazamiento.

Todas las imágenes se cargan utilizando el método [UIImage imageWithContentOfFile: path] . El objeto de collage almacena instancias de UIImage dentro de imagesArray. En el método dealloc, el atributo imagesArray se borra.

Entonces, preguntas:

• ¿Es un tipo de error del sistema en [UIImage imageWithContentOfFile?]
• ¿Es Image IO cache?
• ¿Puedo borrarlo?

Answer 1

Además de la respuesta de David H, recomendaría a cualquier persona que esté experimentando este problema que compruebe si los UIDocument su Controlador de vista, Modelo, UIDocument (si lo usa) se llaman cuando no son necesarios.

Si no desasigna correctamente estas clases y contienen los datos de imagen / VDO / contenido que UIKit hace referencia a ellos, esto puede dar lugar a este escenario en el que la VM: ImageIO uso de la memoria de VM: ImageIO siempre aumenta y, sin embargo, no observa ninguna pérdida de memoria. cuando utiliza instrumentos, ya que estos contenidos ahora son retenidos internamente por UIKit.

También experimenté este mismo problema dos veces, y en mi caso resultó que el desinicializador de mi Modelo nunca fue llamado debido a problemas no relacionados. Al solucionar esos problemas no relacionados y asegurarme de que mi Modelo está desasignado, estos VM: ImageIO continuo crecimiento desaparecieron.

Answer 2

Poniendo esto aquí como demasiado grande para un comentario, solo algunas ideas:

1) una forma de retener objetos por error es tener objetos en vistas que se ocultan pero no se eliminan de su supervisión (y, por lo tanto, se mantienen retenidos)

2) si haces algo con UIImageView, etc. en cualquier hilo, no en el hilo principal, pueden suceder cosas malas (como esto)

3) copia tu proyecto para que puedas jugar libremente con él, y prueba un montón de cosas:

• En lugar de múltiples imágenes, siempre cargue la misma imagen, pero deje las otras partes de su código tal como están, ¿cambian las cosas?

• En cualquier subclase que cree que retendría / retendría imágenes, coloque un mensaje de registro en el dealloc para ver si, de hecho, esos objetos se desasignan.

• subclase UIImageView, úselo para las imágenes y registre el dealloc

• subclase UIImage, úselo para estas imágenes, registre el dealloc

4) Me está costando mucho creer que imageio tiene un defecto que haría esto, pero lo que podría hacer es cambiar a usar imageWithData y cargar los datos usted mismo. Use la bandera F_NOCACHE cuando realmente lea los datos. Hay otro código en SO sobre cómo hacer esto, puede buscarlo (respondí una pregunta).

Si puede crear un proyecto de demostración con este defecto, sería mucho más fácil de depurar que simplemente adivinar qué hacer. El registro de la clase que obtiene dealloc''d es un largo camino, ya que verá inmediatamente lo que no se está liberando y luego se enfocará mejor en el problema.