Android – Bitmap y gestión de la memoria?

He visto en una gran cantidad de muestras, que los desarrolladores llaman a recycle() en mapa de bits, y luego se establece en null . ¿Por qué es necesario, el recolector de basura no se encarga de liberar el mapa de bits?

 Bitmap bitmap = BitmapFactory.decodeStream(inputStream); bitmap.recycle(); bitmap = null; 

Únete al club. Es algo que hace pero no del todo.

La cosa es que en las versiones anteriores a Honeycomb de Android, la memoria de mapas de bits se asignó desde la memoria no administrada, lo que genera todo tipo de problemas. Todavía se publica pero desde el finalizador de la implementación de objeto de mapa de bits. Lo que significa que tomará al menos 2 pasadas de GC para recogerlo. También si por cualquier razón el finalizador no ejecuta – usted consiguió la imagen. Otra cosa es – es realmente difícil de rastrear – DDMS no lo ve y tampoco MAT

Para Android 3.0 esto se ha cambiado y los mapas de bits se implementan sobre arreglos de byte administrados, pero para los teléfonos antiguos …

Bitmap.recycle (); Libere el montón nativo que se utiliza en mapas de bits. Y establecerlo en nulo es ayudar al GC a recopilar rápidamente su referencia.

Desde documentos en http://developer.android.com/reference/android/graphics/Bitmap.html#recycle%28%29 .


Libere el objeto nativo asociado con este mapa de bits y desactive la referencia a los datos de píxeles. Esto no liberará los datos de píxeles de forma sincrónica; Simplemente permite que se recoja basura si no hay otras referencias. El mapa de bits está marcado como "muerto", lo que significa que lanzará una excepción si getPixels () o setPixels () se llama y no dibujará nada. Esta operación no se puede revertir, por lo que sólo se debe llamar si está seguro de que no hay otros usos para el mapa de bits. Esta es una llamada avanzada, y normalmente no es necesario que se llame, ya que el proceso GC normal liberará esta memoria cuando no hay más referencias a este mapa de bits.


Así que no parece ser necesario llamar. La única vez que he escuchado una necesidad de establecer manualmente un objeto a null es si es una variable estática (o alguna variable que no saldrá del ámbito fácilmente) y desea forzarla a no tener memoria. Tal vez si usted está asignando continuamente bitmaps rápidamente puede haber una necesidad de tratar de forzar la recolección de basura, pero para la mayoría de los casos probablemente no es necesario.

Este artículo de los documentos de desarrollo de android tiene mucha información sobre este tema. Mientras estás en él también revisa el artículo sobre el almacenamiento en caché si vas a usar varios mapas de bits.

  • Android GC - LogCat siempre muestra actividad de GC
  • ¿Qué significan GC_FOR_MALLOC, GC_EXPLICIT y otros GC_ * en Android Logcat?
  • El servicio detenido está haciendo la recolección de basura constante
  • Garbage Collection causa: MediaPlayer finalizado sin ser lanzado
  • Recogida de basura GridView de Android (GC_EXTERNAL_ALLOC) <1K excesivamente, causando una interfaz de usuario muy intermitente
  • 17.8 MiB asignación de montón para un simple "Hello World" proyecto?
  • SoftReference obtiene recolección de basura demasiado temprano
  • ¿Por qué se filtran hilos en Android?
  • Colección de cuerdas y basura
  • En una aplicación React Native JavaScript, ¿por qué cambiaría el comportamiento de Android GC si creaba una variable temporal en lugar de devolver un valor directamente?
  • Android, veo que el montón crece, pero quiero que pare
  • Interesting Posts
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.