Android: error "tratando de utilizar un mapa de bits reciclado" con Bitmaps temporales

Question

Mi aplicación puede cargar imágenes bastante grandes. En un esfuerzo por ser la memoria-conservador, Estoy intentando utilizar un mapa de bits temporal para cargar y otro para la imagen final después de la transformación:

..... 
finalBitmap.recycle(); 
finalBitmap = null; 
Bitmap tempBitmap = BitmapFactory.decodeStream(fin, ...); 
finalBitmap = Bitmap.createBitmap(tempBitmap, ....); 
imgview.setImageBitmap(finalBitmap); 
..... 

Ahora, en este punto hemos terminado con tempBitmap, que era solo era necesario transportar el Bitmap descodificado al paso de transformación en createBitmap. Por lo tanto:

..... 
tempBitmap.recycle(); 
tempBitmap = null; 
..... 

Y ... se estrella con un "tratando de utilizar un mapa de bits reciclado" error específicamente por el reciclaje de tempBitmap. tempBitmap no se mostró y solo se usa allí.

¿Qué está mal aquí? ¿Debo usar "finalBitmap" a lo largo y se basan en CreateBitmap gestionarla (finalBitmap = Bitmap.createBitmap (finalBitmap, ....))? No puedo ver qué dependencia en curso en tempBitmap podría causar ese error.

Editar: Sí, la asignación nula parece dar lugar a la, eventual recolección de basura adecuado, pero estoy desconcertado por qué reciclar() en un mapa de bits temperatura es tan problemático en este caso. Me da la impresión de que createBitmap() contiene una referencia, pero ¿por qué y durante cuánto tiempo?

Answer 1

Directamente desde el Android documentation:

Devuelve un mapa de bits inmutable del subconjunto especificado de la fuente mapa de bits. El nuevo mapa de bits puede ser el mismo objeto que el origen, o puede haber una copia .

Parece que las funciones de createBitmap tienen el potencial de reutilizar el mapa de bits que proporcionó. Si ese es el caso, entonces no debe reciclar el mapa de bits temporal ya que su mapa de bits final lo está usando. Una cosa que puede hacer es

if(tempBitmap != finalBitmap) { 
    tempBitmap.recycle(); 
} 

que sólo debe reciclar el tempBitmap cuando no es el mismo que el finalBitmap. Al menos eso parece ser lo que la documentación está implicando.