Android: pre y post-HONEYCOMB montón de uso debido a los mapas de bits?

Estoy desarrollando una aplicación con gran intensidad de gráficos para Android 2.2 y versiones posteriores.

Sé que a partir de Honeycomb, mapas de bits se almacenan en VM_HEAP en lugar de su montón de mapa de bits nativo.

¿Esto influye en el uso efectivo de la memoria de mi aplicación? Quiero decir, por ejemplo, si mi aplicación para los dispositivos pre-Honeycomb utiliza X MB del montón de VM, y tiene mapas de bits de Y MB (almacenados en montón nativo), entonces espero que no comience a usar X + Y MB del montón de VM Si está instalado en un Honeycomb o un dispositivo más nuevo.

Esto no suena lógico. En su lugar, supongo que el tamaño de mapa de bits se cuentan contra los límites de VM incluso antes de Honeycomb, de lo contrario, ¿por qué aparecería el error "tamaño de mapa de bits supera el presupuesto de VM"? Así que están almacenados en su montón nativo, pero todavía se cuenta en contra de VM_HEAP tamaño máximo).

También estaba preocupado, pero recibí una respuesta de Google mientras tanto, lo que confirmó mi siguiente suposición:

"Esto no suena lógico.Por el contrario, supongo que el tamaño del mapa de bits se cuenta en contra de los límites de VM incluso antes de Honeycomb, de lo contrario, ¿por qué aparecería" tamaño de mapa de bits supera el presupuesto de VM "errores aparecen en su montón nativo, Contra VM_HEAP tamaño máximo). "

Respuesta de Romain Guy (ingeniero de Android Framework):

"Su aplicación utilizará la misma cantidad de memoria pre y post Honeycomb".

AFAIK Fue cambiado en panal. Los mapas de bits se almacenan ahora en su montón de dalvik (VM_HEAP) y no en montón nativo como en versiones anteriores. (Tal vez porque no querían depender de SKia GC más)

Uno ahora necesita tener cuidado de administrar bitmaps más seriamente como los mapas de bits que funcionan bien en 2.2 podría dar una excepción de OOM en 3.0 como la misma imagen está tomando más píxeles en una tableta (no puede aplicarse a 4.0, no está seguro).