¿Por qué Android 4.0 / Ice Cream Sandwich asigna tanta memoria heap?

Me di cuenta de que en mi Galaxy Nexus que android.content.res.Resources está asignando alrededor de 11MB. He descubierto esto como yo estaba en el proceso de creación de perfiles de las cosas con DDMS y la opción " Dump HPROF file " opción. Por lo tanto, pasé dos horas tratando de ver si la asignación se debía a algo en mi código o bibliotecas de apoyo. Quité todos mis datos, un montón de clases, todas mis bibliotecas, y no vio ningún cambio. Después de colocar un punto de interrupción en mi código al principio del método onCreate() de la actividad, mostró que la asignación de 11 MB ya está presente.

Después de ser completamente confundido, decidí conectar mi Nook Color enraizado corriendo CM7 para ver lo que estaba informando para el uso de memoria inicial para la aplicación exacta misma. La peor memoria de caso "Problema sospechoso" reportado por la MAT pesa en un mero 896KB.

¿Es ICS que pesa mucho? ¿Me estoy perdiendo de algo? Por lo que puedo decir, mi aplicación está funcionando correctamente, pero tener el uso de montón de indicar el 97% de lleno me ha preocupado por posibles fallos.

Si ayuda, MAT indica que los objetos primarios que consumen toda la memoria son Bitmaps, BitmapDrawables y NinePatchDrawables . No entiendo de dónde provienen estas asignaciones.

Pre-Honeycomb (<3.0), los mapas de bits se asignaron en montón nativo y no aparecieron en volcados de Dalvik como se muestra por Eclipse MAT, etc. Esta asignación nativa todavía contribuía a límites máximos de pila de Dalvik para una aplicación y todavía causaba recolección de basura. se ejecutan aproximadamente al tiempo correcto cuando se aproxima a una situación de memoria baja. Este uso se puede medir con Debug.getNativeHeapAllocatedSize() .

Desde Android 3.0 (incluyendo ICS), ahora asigna los datos de píxeles para bitmaps en arrays de bytes normales en el montón de Dalvik. Los efectos prácticos de esto son un mejor / simplificado comportamiento de recolección de basura para Bitmaps (ya que pueden tratarse de una manera más ortodoxa) y la capacidad de rastrear las asignaciones de mapa de bits en volcados de pila de Dalvik.

No creo que el uso real de memoria para una aplicación en particular sea significativamente diferente entre pre-Honeycomb y los lanzamientos más recientes, y que esto es sólo una cuestión de una práctica de contabilidad alternativa.

Análisis de memoria para Android

BitMaps en Android