¿Necesito reciclar BitmapDrawable?
Según http://developer.android.com/training/displaying-bitmaps/manage-memory.html
En Android 2.3.3 (API nivel 10) e inferior, se recomienda usar recycle (). Si está mostrando grandes cantidades de datos de mapa de bits en su aplicación, es probable que se encuentre con errores OutOfMemoryError. El método recycle () permite que una aplicación recupere memoria lo antes posible.
Me preguntaba, para BitmapDrawable , ¿necesito realizar la limpieza como
bitmapDrawable.getBitmap().recycle()
Si ya no es necesario?
Es mejor reciclar mapas de bits cuando no está en uso. Puede cargar bimaps en onResume () y reciclar lo mismo en onPause ().
Así que para reducir el consumo de memoria y evitar fugas de memoria, es mejor reciclar mapas de bits cuando no están en uso.
También echa un vistazo a la charla de gestión de memoria en el enlace
http://www.youtube.com/watch?v=_CruQY55HOk
Editar:
Una cita del enlace que publicaste. (Puede comprobar bajo el encabezado Administrar memoria en Android 2.3.3 y inferior)
En Android 2.3.3 (API nivel 10) e inferior, se recomienda usar recycle () .
A partir de los mapas de bits de HoneyComB se almacenan en HEAP en lugar de su montón de mapas de bits nativos.
Android 3.0 (API Level 11) introduce el campo BitmapFactory.Options.inBitmap. Si esta opción está establecida, los métodos de decodificación que toman el objeto Opciones intentarán reutilizar un mapa de bits existente al cargar contenido. Esto significa que la memoria del mapa de bits se reutiliza, lo que resulta en un rendimiento mejorado, y la eliminación de la asignación de memoria y desasignación
http://developer.android.com/training/displaying-bitmaps/manage-memory.html
La documentación le dice
Esta es una llamada avanzada, y normalmente no es necesario que se llame, ya que el proceso GC normal liberará esta memoria cuando no hay más referencias a este mapa de bits.
Así que voy con: no, no es necesario que lo llame. Libere sus recursos de mapa de bits, sin embargo, al aclarar las referencias que tiene.
El enlace que agregó casi le dice por qué podría haber ayudado antes y después:
En Android 2.3.3 (API nivel 10) e inferior, los datos de píxeles de respaldo para un mapa de bits se almacenan en la memoria nativa. Está separado del mapa de bits en sí, que se almacena en el montón de Dalvik. Los datos de píxeles en la memoria nativa no se liberan de una manera predecible, lo que puede causar que una aplicación exceda brevemente sus límites de memoria y bloqueo. A partir de Android 3.0 (Nivel de API 11), los datos de píxeles se almacenan en el montón de Dalvik junto con el mapa de bits asociado.