Android: ¿Cómo funciona el reciclaje de mapas de bits ()?

Digamos que he cargado una imagen en un objeto de mapa de bits como

Bitmap myBitmap = BitmapFactory.decodeFile(myFile);

Ahora, ¿qué pasará si cargo otro mapa de bits como

myBitmap = BitmapFactory.decodeFile(myFile2);

¿Qué pasa con el primer myBitmap? ¿Se recolecta la basura o tengo que recolectarla manualmente antes de cargar otro mapa de bits? myBitmap.recycle()?

Además, ¿existe una mejor manera de cargar imágenes grandes y mostrarlas una tras otra mientras se reciclan en el camino?

El primer mapa de bits no se recolecta como basura cuando decodifica el segundo. Garbage Collector lo hará más tarde cuando lo decida. Si desea liberar memoria lo antes posible, debe llamar recycle()justo antes de decodificar el segundo mapa de bits.

Si desea cargar una imagen realmente grande, debe volver a muestrearla. Aquí hay un ejemplo: Extraño problema de falta de memoria al cargar una imagen en un objeto de mapa de bits .

Creo que el problema es el siguiente: en las versiones anteriores a Honeycomb de Android, los datos de mapa de bits sin procesar no se almacenan en la memoria de la máquina virtual sino en la memoria nativa. Esta memoria nativa se libera cuando el Bitmapobjeto java correspondiente es GC'd.

Sin embargo , cuando se queda sin memoria nativa, el dalvik GC no se activa, por lo que es posible que su aplicación use muy poca memoria de Java, por lo que el dalvik GC nunca se invoca, pero usa toneladas de memoria nativa para mapas de bits. que eventualmente causa un error OOM.

Al menos esa es mi suposición. Afortunadamente, en Honeycomb y versiones posteriores, todos los datos de mapas de bits se almacenan en la VM, por lo que no debería tener que usarlos recycle()en absoluto. Pero para los millones de 2.3 usuarios (la fragmentación sacude el puño ), debe usar recycle()siempre que sea posible (una molestia enorme). O, alternativamente, puede invocar el GC en su lugar.

Deberá llamar a myBitmap.recycle () antes de cargar la siguiente imagen.

Dependiendo de la fuente de su myFile (por ejemplo, si es algo que no tiene control sobre el tamaño original), al cargar una imagen en lugar de simplemente volver a muestrear un número arbitrario, debe escalar la imagen al tamaño de visualización.

if (myBitmap != null) {
    myBitmap.recycle();
    myBitmap = null;
}
Bitmap original = BitmapFactory.decodeFile(myFile);
myBitmap = Bitmap.createScaledBitmap(original, displayWidth, displayHeight, true);
if (original != myBitmap)
    original.recycle();
original = null;

Guardo en caché displayWidth y displayHeight en una estática que inicialicé al comienzo de mi actividad.

Display display = getWindowManager().getDefaultDisplay();
displayWidth = display.getWidth();
displayHeight = display.getHeight();

Una vez que el mapa de bits se había cargado en la memoria, de hecho se hizo con datos de dos partes. La primera parte incluye información sobre el mapa de bits, la otra parte incluye información sobre los píxeles del mapa de bits (está compuesto por una matriz de bytes). La primera parte existe en la memoria usada de Java, la segunda parte existe en la memoria usada de C ++. Puede usar la memoria del otro directamente. Bitmap.recycle () se utiliza para liberar la memoria de C ++. Si solo hace eso, el GC recopilará la parte de java y la memoria de C siempre se usará.

Timmmm tenía razón.

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

Además, antes de Android 3.0 (API nivel 11), los datos de respaldo de un mapa de bits se almacenaban en la memoria nativa que no se publica de una manera predecible, lo que podría provocar que una aplicación exceda brevemente sus límites de memoria y se bloquee.