Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Caché de imágenes de Android: ¿cómo?

Creo que es preguntado y preguntado antes, pero aún así, hay cosas que no puedo entender.

He intentado dos enfoques diferentes:

  1. Mantenga todas las imágenes en la memoria, cuando se comience a exceder determinado límite, empiece a eliminarlas
  2. Permitir que Android arreglar esto con SoftReferences

En 2. es sólo la limpieza de ellos a veces el segundo que asignarlos! Y no asignar demasiado – 30-40 imágenes 50×50 píxeles.

Así que me quedo con uno. La pregunta es ¿cuál es el límite?

  1. ¿Puedo obtener información fiable del dispositivo de cuánto me queda exactamente la memoria de mapa de bits? He hecho algunas investigaciones, ver valores de DDMS, es sólo ocupar más y más espacio (si no limpio) hasta que explote. Un momento sólo quedan 200K, luego el sistema proporciona 2M más …
  2. Actualmente estoy usando alguna decisión heurística, basada en el modelo del dispositivo o en el tamaño de la pantalla. Creo que esto es un callejón sin salida en el largo plazo. Tengo excepciones de memoria en algunos teléfonos, completamente gratis en otro.
  3. ¿Hay una tercera solución, la correcta?

5 Solutions collect form web for “Caché de imágenes de Android: ¿cómo?”

Pregunta más importante: ¿ recycle() tus mapas de bits? Esto es muy importante para las aplicaciones pre-Gingerbread (tal vez post-Gingerbread también).

Ver la sesión de Administración de memoria para aplicaciones Android de Google I / O 2011 me ayudó a comprender mejor las peculiaridades del desarrollo de Android.

Ese video menciona una herramienta llamada MAT – un analizador de memoria – que es útil para determinar si tiene objetos en la memoria que se han filtrado. Es posible que tenga más de los 30-40 que cree que tiene.

Para ver y / o registrar el tamaño actual de heap, etc., sugeriría usar el código en esta respuesta acerca de las excepciones de Android Out of Memory .

El caché de imágenes fue una parte importante de una aplicación que he creado y puesto en la tienda de aplicaciones. La aplicación necesita descargar imágenes y almacenarlas en caché tanto en la memoria como en la tarjeta SD para que su alcance se extienda más allá de una sola ejecución.

La idea general era agregar las imágenes a un Caching Manager que a) almacena la imagen en un contenedor asociativo (HashMap), a través de una clave basada en los metadatos, yb) escribe el archivo de imagen en la tarjeta SD.

En condiciones de baja memoria, suelto el HashMap. Sin embargo, las imágenes todavía se pueden recuperar de la SD_Card y una vez más el caché en la memoria.

Pude hacer esto sin reciclar y todavía no veo problemas de memoria. Según lo entiendo, el reciclaje no es necesario, pero ayuda a obtener una versión anterior de la memoria utilizada para "Bitmaps" debido al hecho de que la asignación de mapas de bits, en Pre-Gingerbread sistemas operativos utilizan Native Memory. Memoria que no es parte del montón de Dalvik. Así que el recolector de basura no libera esta memoria, sino que es liberado por políticas específicas de implementación.

Esto es de la clase Cache_Manager:

 public static synchronized void addImage(Bitmap b, String urlString, boolean bSaveToFile, IMAGE_TYPES eIT, boolean bForce) { String szKey = getKeyFromUrlString(urlString, eIT); if (false == m_hmCachedImages.containsKey(szKey) || bForce) { m_hmCachedImages.put(szKey, b); if (bSaveToFile) { boolean bIsNull = false; // Write a null object to disk to prevent future query for non-existent image. if (null == b) { try { bIsNull = true; b = getNullArt(); } catch (NullPointerException e) { e.printStackTrace(); throw e; } } // Don't force null art to disk if (false == File_Manager.imageExists(szKey) || (bForce && bIsNull == false)) File_Manager.writeImage(b, szKey); } } } 

// Aquí un ejemplo de writeImage () de la clase File_Manager

 public static void writeImage(Bitmap bmp, String szFileName) { checkStorage(); if (false == mExternalStorageWriteable) { Log.e("FileMan", "No Writable External Device Available"); return; } try { // Create dirctory if doesn't exist String szFilePath = getFilesPath(); boolean exists = (new File(szFilePath)).exists(); if (!exists) { new File(szFilePath).mkdirs(); } // Create file File file = new File(szFilePath, szFileName); // Write to file FileOutputStream os = new FileOutputStream(file); bmp.compress(Bitmap.CompressFormat.PNG, 90, os); } catch (IOException e) { // Unable to create file, likely because // external storage is // not currently mounted. Log.e("FileMan", "Error writing file", e); } catch (Exception e) { e.printStackTrace(); throw e; } } 

El límite está relacionado con el tamaño de heap de VM en el dispositivo en el que se está ejecutando, ya que es diferente de dispositivo por dispositivo y OS a OS puede variar desde 16MB (total para la aplicación) hasta 256MB + (en tabletas).

Tendrá que mantenerlo bajo el extremo inferior, crear diferentes compilaciones por dispositivo o hacer que la aplicación compruebe en tiempo de ejecución cuál es la asignación y cargue las imágenes en consecuencia.

Hay métodos para comprobar la cantidad de espacio libre en el montón y su tamaño:

Esta API ref le ayudará con los métodos avilable:

http://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass

Desde una perspectiva de alto nivel, la carga y almacenamiento en caché de imágenes forma parte del marco de GreenDroid . Echale un vistazo.

Podría usar un WebView para mostrar imágenes, tiene caché incorporado. Además, es compatible con zoom de 2 dedos y desplazarse, sin ningún código especial.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.