Gestión de la memoria de Android: Densidad de pantalla, tamaños de imagen solicitados y montón disponible

Adivina qué, otro Android-Bitmap-OOM pregunta!

Fondo

Mientras que la prueba de estrés de nuestra aplicación se ha observado que es posible OutOfMemory asignación de la memoria de proceso de la aplicación después de un uso sostenido y pesado (como runner mono) con excepciones OutOfMemory se registran en el stacktrace resultante. La aplicación descarga imágenes (alrededor de 3 a la vez) cuando se selecciona una página bajo ViewPager . Puede haber más de 280 imágenes disponibles para descargar cuando se ejerce la duración y el aliento de la aplicación. La aplicación utiliza Picasso por Square para su descarga de imágenes de abstracción. En particular, en ningún momento en el código de nuestra aplicación estamos manipulando Bitmaps directamente … confiamos en que los empleados de Square Inc. muy talentosos lo están haciendo mejor que nosotros.

Aquí hay una foto

El gráfico siguiente muestra las asignaciones de montón a lo largo del tiempo registradas bajo el mensaje de registro dalvikvm-heap . Los puntos rojos indican un usuario que trae un nuevo conjunto de artículos en la aplicación con el fin de reforzar la cantidad de trabajo pendientes y el estrés de la aplicación …

DALVIKVM asignaciones de montón http://snag.gy/FgsiN.jpg Figura 1: asignaciones de montón de Nexus One; Los OOMs se producen a 80MB +

Investigación hasta la fecha

Contra un Nexus S, Nexus 4, Wildfire, HTC Incredible y una miríada de otros dispositivos de prueba, las pruebas anecdóticas han demostrado que la gestión de la memoria es suficiente con el DVM GC 'mantenerse al día' con el trabajo de elevación que está completando la aplicación. Sin embargo, en los dispositivos de gama alta, como el Galaxy S II, III, IV y HTC One, el OOM son frecuentes. De hecho, dado suficiente trabajo para hacer, me imagino que todos nuestros dispositivos eventualmente mostraría el fracaso.

La pregunta

Existe claramente una relación entre la densidad de la pantalla (los tamaños de imagen solicitados se basan en el tamaño del ImageView), la asignación de la memoria del proceso y el número de imágenes en un tamaño dado que daría como resultado que la aplicación exceda los límites de montón. Estoy a punto de embarcarme en cuantificar esta relación, pero quisiera que la comunidad SO se fijara en este problema y (a) de acuerdo o en desacuerdo que la relación vale la pena y (b) proporcionar literatura que indique la mejor manera de establecer esta relación.

Es importante tener en cuenta que si destruimos la calidad de la imagen, nuestro OOM desaparece, pero por desgracia el UX es más pobre y es por eso que queremos cortar con el uso más efectivo del montón disponible.


Nota de lado: Aquí está la parte del código responsable de cargar estas imágenes en las vistas que se han establecido;

 picassoInstance.load(entry.getKey()) .resize(imageView.getMeasuredWidth(), imageView.getMeasuredHeight()) .centerCrop() .into(imageView); 

El 'asombro de la calidad de imagen' mencionado anteriormente es simplemente dividir el imageView.getMeasured... por un número como '4'.

2 Solutions collect form web for “Gestión de la memoria de Android: Densidad de pantalla, tamaños de imagen solicitados y montón disponible”

Primero usted necesita manejar la asignación de las memorias, su un problema grande en androide pues los mapas de bits toman porciones de memorias, para esa asignación de la memoria se puede reducir siguiendo maneras

  1. Poner todas las imágenes que son enormes en tamaño de carpeta de activos en lugar de ponerlos en la carpeta de drawabable. Porque los recursos dibujables toman memoria para almacenarlos en caché. Si usted carga de la carpeta del activo la imagen no almacenará en caché. Y tomará menos memoria.

    1. Estudio Lrucache que utilizan para la gestión de memoria eficiente.
    2. Poner recursos en pequeños formatos para que el cheque TinyPNG
    3. Si sus imágenes son demasiado grandes en la resolución, a continuación, intente utilizar archivos SVG para las imágenes y cargar archivos SVG en lugar de la imagen. Compruebe este SVG PARA ANDROID

Finalmente no soy muy bueno en inglés espero que pueda ayudarle.

Este post es un poco viejo, pero también tuve este problema recientemente. Tal vez esto ayudará a alguien más. General Resumen de este hilo masivo / Lo que me ayudó.

-Asegúrese de que está utilizando una Instancia Singleton de Picasso

-Utilizar ajuste ()

-Para imágenes grandes o muchas imágenes o cuando se utiliza en un FragmentPager / StatePager probablemente debería usar skipmemorycache () y / o la declaración largeHeap

Lea el hilo para más consejos. En el momento en que se publicó esta pregunta, nadie había publicado este número en picassos github.

https://github.com/square/picasso/issues/305

Buena suerte Espero que esto ayude y codificación feliz.

  • A / Looper: No se pudo crear el tubo de estela. Errno = 24
  • Rotar correctamente las imágenes web utilizando Picasso de Square
  • UIL, Picasso - Las imágenes en adaptador siempre se recargan cuando se detiene el desplazamiento
  • Cómo agregar un token de autenticación en el encabezado de la biblioteca Picasso
  • ¿Cómo puedo acceder a la imagen en caché de Picasso para hacer una intención de compartir?
  • ¿Cómo optimizo mejor Picasso en un GridView?
  • Redimensionar la imagen a todo el ancho y la altura fija con Picasso
  • Imágenes que no se cargan con Picasso sin error
  • HorizontalGridView / RecyclerLa posición de desplazamiento se restablece una vez que la imagen de Picasso se carga
  • Picasso "Cambiar tamaño y centerCrop" o ImageView "centerCrop"?
  • Cómo borrar el caché de una URL específica de caché de Picasso
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.