Posible BUG en Android Clase ImageDownloader: sHardBitmapCache NO estática cuando debería ser?

He estado tratando de aprender lo más posible sobre el desarrollo de Android con un enfoque específico en el rendimiento ya que muchas aplicaciones en la tienda de Play hoy son lentas. He encontrado / dirigido a muchos artículos / videos.

Un artículo específico sobre el almacenamiento en caché de imágenes está en: http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html

• No puedo seleccionar mi cliente de Android en la perspectiva de DDMS de eclipse
• ¿Cuál es la tasa de bits de lectura NFC efectiva usando comandos de APDU?
• Android - ListView con imágenes se desplaza demasiado lento incluso sin ningún procesamiento en el método getView del adaptador
• En Android; ¿Es mejor aplicar un OnClickListener o usar android: onClick?
• ¿Puedo activar multidex en la compilación de depuración de Android solamente?

El autor tiene el código disponible en: http://code.google.com/p/android-imagedownloader/source/browse/trunk/src/com/example/android/imagedownloader/ImageDownloader.java

Qué Google parecía tomar una versión de en y poner en sus clases de la muestra en: http://developer.android.com/resources/samples/XmlAdapters/src/com/example/android/xmladapters/ImageDownloader.html

En general, es sólido, excepto por lo que creo que es una falla en el almacenamiento en caché. Utiliza un caché blando / duro que pone / obtiene cosas en el caché duro porque el sistema de Android restablece la caché suave a menudo.

Mirando el código sin embargo, uno comienza a preguntarse si la memoria caché dura conseguiría puesta a cero accidentalmente cada vez que la clase del padre se instancia.

Primero la caché suave:

// Soft cache for bitmaps kicked out of hard cache private final static ConcurrentHashMap<String, SoftReference<Bitmap>> sSoftBitmapCache = new ConcurrentHashMap<String, SoftReference<Bitmap>>(HARD_CACHE_CAPACITY / 2); 

Ahora eche un vistazo al caché duro:

  // Hard cache, with a fixed maximum capacity and a life duration private final HashMap<String, Bitmap> sHardBitmapCache = new LinkedHashMap<String, Bitmap>(HARD_CACHE_CAPACITY / 2, 0.75f, true) { @Override protected boolean removeEldestEntry(LinkedHashMap.Entry<String, Bitmap> eldest) { if (size() > HARD_CACHE_CAPACITY) { // Entries push-out of hard reference cache are transferred to soft reference cache sSoftBitmapCache.put(eldest.getKey(), new SoftReference<Bitmap>(eldest.getValue())); return true; } else return false; } }; 

El caché duro no es estático , mientras que el caché suave es estático. Por lo tanto, la instancia de caché duro y por lo tanto los elementos se borran con la vida de la instancia de la clase.

La razón por la que creo que esto es cierto es que me di cuenta de mi aplicación con un ListView / ImageView, estaba descargando la imagen cada vez y nunca caché. Todo estaba hecho asincrónicamente, pero todavía golpeaba la red cada vez. Log.d() esto poniendo una declaración de Log.d() dentro de mi método que golpea la tela y viendo cuando / cómo con frecuencia fue llamada.

Agregando la palabra clave estática solucionado el problema y mi aplicación es mucho más performant.

No estoy seguro de por qué este es el caso, ya que sólo hay una instancia de la clase ImageDownloader en mi adaptador, como se muestra en el ejemplo:

 private final ImageDownloader imageDownloader = new ImageDownloader(); 

LA PREGUNTA

Con todo lo dicho, ¿alguien más ha experimentado esto ??? O soy una combinación de loco / equivocado de alguna manera. No soy Java / Android / JVM / Dalvik / WeakReference / SoftReference experto, pero algo parece un poco apagado. No sé por qué sHardBitmapCache no se hizo estática, pero cuando hice el cambio de mi aplicación dejó de golpear la web tanto (ahorro en los costos de datos / drenaje de la batería / mejoras de rendimiento) .