5
Sé que antes de API 10 de Android, era importante llamar al recycle() para Bitmap s que ya no se usan, ya que los datos brutos reales se almacenan en la memoria nativa.¿Qué significa llamar a bitmap.recycle() en la API 11+?
Sin embargo, a partir de la API 11, Bitmap s se almacenan en el montón, así que mi pregunta es:
¿Sigue siendo necesario llamar recycle() en Bitmap s si la API es lo suficientemente grande (al menos 11)? ¿Qué hace si lo llamo en tal API?
Cuando dices "era importante llamar a recycle() antes de API 10" ¿eso significa que si no lo haces, la memoria nunca se liberará? Los documentos oficiales dicen que es "recomendado", pero si asigna el mapa de bits en la memoria nativa no entiendo cómo se puede liberar sin una llamada para reciclar(). – Tiago
@Tiago Puede ver esta conferencia: https://www.youtube.com/watch?v=_CruQY55HOk#t=656. Los mapas de bits ocuparon muy poco espacio en el montón, pero sus datos de píxeles no lo hicieron (aún formaba parte del mecanismo OOM del montón), por lo que el GC no sabía cuán buena/mala era la situación, y si no era así. Si se activa al crear mapas de bits múltiples, puede obtener fácilmente OOM. Es por eso que es importante llamar a "reciclar" para que limpie los mapas de bits lo antes posible (porque el GC no hizo bien su trabajo). –
Ah, ya veo. Eso explica mucho. Es bastante extraño que la excepción OutOfMemory cuente tanto para el montón como para la memoria nativa, mientras que el GC solo vería el montón. Una vez desde Honeycomb + los datos de píxel de los mapas de bits también están en el montón, entonces el GC puede hacer bien su trabajo. ¡Qué desastre, jeje! ¡Gracias por aclararlo! – Tiago