SoftReference obtiene recolección de basura demasiado temprano

Estoy en mi camino con la implementación de un mecanismo de caché para mi aplicación de Android.

Utilizo SoftReference , como muchos ejemplos que he encontrado. El problema es que cuando se desplaza hacia arriba o hacia abajo en mi ListView , la mayoría de las imágenes ya están borradas. Puedo ver en LogCat que mi aplicación es basura recogida cada vez que la aplicación carga nuevas imágenes. Esto significa que la mayoría de las imágenes no visibles en el ListView se han ido.

Por lo tanto, cada vez que vuelvo a una posición anterior (donde realmente descargó imágenes antes) tengo que descargar las imágenes una vez más – no están en caché .

También he investigado este tema. De acuerdo con Mark Murphy en este artículo , parece que hay (o fue?) Un error con la SoftReference . Algunos otros resultados indican lo mismo (o el mismo resultado); SoftReference s se están eliminando demasiado pronto.

¿Hay alguna solución de trabajo?

SoftReference son la pobre cache de los hombres. La JVM puede mantener a esas referencias vivas más tiempo, pero no tiene que hacerlo. Tan pronto como ya no hay una referencia difícil, la JVM puede recolectar basura un Objeto de referencia suave. El comportamiento de la JVM que está experimentando es correcto, ya que la JVM no tiene que mantenerlo durante más tiempo. Por supuesto, la mayoría de las JVM intentan mantener vivo el objeto de referencia suave hasta cierto punto.

Por lo tanto, SoftReferences es una especie de caché peligroso. Si realmente desea garantizar un comportamiento de almacenamiento en caché, necesita una caché real. Como una caché LRU . Especialmente si usted está almacenando en caché es funcionamiento-crítico, usted debe utilizar una memoria caché apropiada.

Desde el sitio de Android Training:

http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

En el pasado, una implementación de caché de memoria popular era una caché de mapa de bits SoftReference o WeakReference, sin embargo esto no se recomienda. A partir de Android 2.3 (API Nivel 9), el recolector de basura es más agresivo con la recolección de referencias suaves / débiles que los hace bastante ineficaces . Además, antes de Android 3.0 (nivel de API 11), los datos de respaldo de un mapa de bits se almacenaron en la memoria nativa que no se libera de forma predecible, lo que puede hacer que una aplicación exceda brevemente sus límites de memoria y bloqueo.

Más información en el enlace.

Deberíamos usar LruCache en su lugar.

Cache cada imagen en el almacenamiento persistente en lugar de sólo en la memoria.

La respuesta de Gamlor es correcta en su situación. Sin embargo, para obtener información adicional, consulte Preguntas frecuentes del GC , pregunta 32.

La VM del servidor Java HotSpot utiliza el tamaño de montón máximo posible (como se establece mediante la opción -Xmx) para calcular el espacio libre restante.

La máquina cliente Java HotSpot Client utiliza el tamaño de montón actual para calcular el espacio libre.

Esto significa que la tendencia general es que el Servidor VM crezca el montón en lugar de limpiar referencias suaves, y -Xmx por lo tanto tiene un efecto significativo en cuando las referencias blandas se recolectan basura.

  • Referencia débil para la llamada de red mala idea?
  • La actividad principal no es la basura recogida después de la destrucción porque es referenciada por InputMethodManager indirectamente
  • Android - Bitmap y gestión de la memoria?
  • Posibilidad de pérdida de memoria no controlada
  • Android adecuada limpieza / eliminación
  • Recolector de basura en Android
  • Cómo solucionar java.lang.OutOfMemoryError: Límite de sobrecarga de GC excedido error en android studio
  • ¿Cómo puedo evitar los retrasos de recolección de basura en juegos Java? (Mejores Prácticas)
  • Creación de perfiles y optimización de un juego Android
  • Formatea una dirección MAC en Android / Java sin crear basura innecesaria
  • ¿Por qué la basura de Android recopila tantas veces con Jacksons ObjectMapper?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.