Bitmaps dans Android

Question

J'ai quelques questions concernant les objets Bitmap, la mémoire et leur taxonomie générale.

1. Qu'est-ce qu'un bitmap en mémoire ou natif ?
2. En quoi la mémoire Bitmap est-elle différente de la mémoire Heap ?

Answer 1

La mémoire qui soutient un objet Bitmap est allouée en utilisant du code natif ( malloc() ), plutôt que le système Java new mot-clé. Cela signifie que la mémoire est gérée directement par le système d'exploitation, plutôt que par Dalvik.

La seule différence réelle entre le tas natif et le tas de Dalvik est que le tas de Dalvik est ramassé, alors que le tas natif ne l'est pas.

Pour ces raisons, il n'y a pas beaucoup de différence. Lorsque votre objet Bitmap est mis au rebut, son destructeur recyclera la mémoire associée dans le tas natif.

Fuente:

• http://osdir.com/ml/AndroidDevelopers/2009-03/msg00023.html
• Android:platform/frameworks/base/graphics/java/Android/graphics/Bitmap.java
• Android:platform/frameworks/base/core/jni/Android/graphics/Bitmap.cpp

Answer 2

Il y a une subtilité importante ici : bien que les pixels Bitmap soient alloués dans le tas natif, certaines astuces spéciales de Dalvik font qu'ils sont comptabilisés dans le tas Java. Ceci est fait pour deux raisons :

(1) Pour contrôler la quantité de mémoire allouée par une application. Sans la comptabilité, une application pourrait allouer une énorme quantité de mémoire (puisque l'objet Bitmap lui-même est très petit mais peut retenir une quantité arbitrairement grande de mémoire native), dépassant la limite de 16MB ou 24MB du tas.

(2) Pour aider à déterminer le moment du GC. Sans la comptabilisation, vous pourriez allouer et libérer des références sur, disons, 100 objets Bitmap ; le GC ne s'exécuterait pas, parce que ces objets sont minuscules, mais ils pourraient en fait représenter un grand nombre de mégaoctets d'allocations réelles qui ne sont pas actuellement GCés en temps opportun. En comptabilisant ces allocations dans le tas Java, le ramasseur de déchets s'exécutera au moment où il pense que la mémoire est utilisée.

Notez qu'à bien des égards, il s'agit d'un détail d'implémentation ; il est très probable qu'il puisse changer à l'avenir, bien que ce comportement de base soit conservé sous une forme ou une autre, car ce sont deux caractéristiques importantes pour la gestion des allocations de bitmaps.

Answer 3

D'après les déploiements dans la nature, j'ai trouvé les dispositifs suivants :

• Les appareils qui se limitent à 16 MiB de java heap (les bitmaps sont presque illimités).
• Dispositifs qui limitent à 16 MiB de (java heap + stockage bitmap natif)
• Les appareils qui se limitent à 24 MiB de java heap (les bitmaps sont presque illimités).
• Dispositifs qui limitent à 24 MiB de (java heap + stockage bitmap natif)

Les appareils à haute résolution ont tendance à avoir 24 MiB et peuvent être détectés avec Runtime.getRuntime().maxMemory(). Il y a aussi des appareils de 32MiB maintenant, et certains des téléphones rootés ont 64MiB par défaut. Auparavant, je me suis embrouillé plusieurs fois pour essayer de comprendre ce qui se passait. Je pense que tous les appareils comptent les bitmaps dans la limite du heap. Mais il est très difficile de faire des généralisations sur la flotte Android.

C'est un problème TRÈS désagréable sur Android, et très déroutant. Cette limite et ses comportements sont mal documentés, compliqués et extrêmement peu intuitifs. Ils varient également selon les appareils et les versions du système d'exploitation, et comportent plusieurs bogues connus. Une partie du problème est que les limites ne sont pas précises - en raison de la fragmentation du tas, vous atteindrez le OOM bien avant la limite réelle et vous devrez prudemment laisser un méga ou deux de tampon. Pire encore, j'ai plusieurs appareils où il y a un défaut de segmentation native (100% un bug dans Android lui-même) qui se produit avant que vous obteniez l'exception java OOM, ce qui rend doublement important de ne jamais atteindre la limite puisque vous ne pouvez même pas attraper le crash natif. Pour plus de détails sur mes investigations, consultez ce poste . Dans ce même billet, j'explique comment mesurer l'utilisation par rapport à la limite et éviter les plantages.

La taille du tas de java est Runtime.getRuntime().totalMemory().

Il n'y a pas de moyen facile de mesurer la taille du stockage natif des bitmaps. Le tas natif global peut être mesuré avec Debug.getNativeHeapAllocatedSize(), mais seuls les bitmaps comptent dans la limite (je pense).

Answer 4

Nous pouvons augmenter la taille du tas en utilisant android:largeheap="true" dans votre fichier manifeste. Cela résoudra certains de vos problèmes.