Bitmap, Bitmap.recycle (), WeakReferences y Garbage Collection

AFAIK en Android, se recomienda hacer referencia a objetos Bitmap como WeakReferences para evitar fugas de memoria. Cuando no se mantienen más referencias duras de un objeto de mapa de bits, el recolector de basura lo recogerá automáticamente.

Ahora, si entiendo correctamente, el método Bitmap.recycle () siempre debe ser llamado para liberar un mapa de bits. Creo que esto es porque los objetos Bitmap tienen una gestión de memoria especial.

¿Es eso correcto?

Si esto es cierto, cuando se utiliza WeakReferences, debe haber pérdidas de memoria porque Bitmap.recycle () nunca se llama cuando se liberan los WeakReferences. O, de alguna manera, son WeakReferences suficiente para evitar fugas de memoria?

Gracias

No se requiere que Bitamp.recycle se llame, ya que el recolector de basura limpia bitmaps por sí solo eventualmente (siempre y cuando no haya referencias). Los mapas de bits en Android se crean en la memoria nativa, no en el montón de VM, por lo que el objeto Bitmap real en el montón de VM es muy pequeño ya que no contiene ningún dato de mapa de bits real. (EDIT: ya no es el caso a partir de Android 3.0 o superior) El tamaño real del mapa de bits seguirá contando contra su uso de montón para propósitos de GC y asegurarse de que su aplicación no utiliza demasiada memoria.

Sin embargo, el GC parece ser un poco temperamental cuando se trata de mapas de bits. Si acaba de eliminar todas las referencias difíciles, a veces (en mi caso) se cuelgan en los mapas de bits por un poco más de tiempo, quizás debido a la manera extraña de asignar / contar los objetos de mapa de bits. Bitmap.recycle parece ser bueno para conseguir que el GC recoja ese objeto más rápidamente.

De cualquier manera, no perderá memoria si no llama a Bitmap.recycle siempre y cuando no mantenga referencias duras accidentalmente. Puede encontrar OutOfMemoryErrors si intenta asignar demasiados bitmaps a la vez o mapas de bits demasiado grandes sin llamar a .recycle, sin embargo.

EDIT: Es importante tener en cuenta que a partir de Android 3.0, Bitmaps ya no se asignan en la memoria nativa. Se asignan en el montón de VM como cualquier otro objeto Java. Sin embargo, lo que dije acerca de no necesitar llamar a reciclar todavía se aplica.

  • ¿Está declarando una clase interna en una vista peligrosa?
  • Reciclaje Bitmap no libera memoria
  • Clueless Acerca de (posible) pérdida de memoria de Android
  • Comparar archivos heap dump (HPROF)
  • Fragmentos de Android en Backstack ocupan demasiada memoria
  • ¿Cómo estática clase interna con una WeakReference a la clase externa puede evitar fugas de memoria de Android? Necesito un ejemplo
  • Anónimo Oyente de la solicitud de volley causando pérdida de memoria
  • Android Weak Referencia de la clase interna
  • ProgressDialog: cómo evitar la ventana filtrada
  • Fuga de memoria en Android al intentar enviar un formulario con imagen al servidor PHP
  • RuntimeException: tipo de letra nativo no se puede hacer o pérdida de memoria para personalizado TextView carga de fuente
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.