Bitmap, Bitmap.recycle (), WeakReferences et Garbage Collection

AFAIK sur Android, il est recommandé de faire référence à Bitmap Objects en tant que WeakReferences afin d'éviter les fuites de mémoire. Lorsqu'aucune référence plus rigide n'est conservée sur un objet bitmap, le collecteur d'ordures va le collecter automatiquement.

Maintenant, si je comprends bien, la méthode Bitmap.recycle () doit toujours être appelée pour libérer un Bitmap. Je pense que c'est parce que les objets Bitmap ont une gestion spéciale de la mémoire.

  • Développement d'une application similaire à "Google Now" - est-il possible d'utiliser la reconnaissance vocale sans entrée de clé?
  • Android: comment stocker de manière persistante un Spanned?
  • FragmentStatePagerLargeur de mémoire de l'adaptateur (fragments imbriqués avec le viewpager)
  • Mettre à jour la luminosité de l'affichage sur Android après la modifier par programme
  • Boîte de dialogue de l'arrière et de progression de l'Android
  • Réagir Les transitions natives de l'Android sont très lentes
  • Est-ce exact?

    Si cela est vrai, lorsque vous utilisez WeakReferences, il doit y avoir des fuites de mémoire car Bitmap.recycle () n'est jamais appelé lorsque WeakReferences est libéré. Ou, en quelque sorte, les références faibles sont-elles suffisantes pour éviter les fuites de mémoire?

    Merci

    One Solution collect form web for “Bitmap, Bitmap.recycle (), WeakReferences et Garbage Collection”

    Bitamp.recycle n'est pas obligé d'être appelé, car le collecteur d'ordures nettoiera les bitmaps à sa fin éventuellement (tant qu'il n'y a pas de références). Les Bitmaps dans Android sont créés dans la mémoire native, et non sur le VM heap, de sorte que l'objet Bitmap réel sur le VM Heap est très petit puisqu'il ne contient aucune donnée de bitmap réelle. (EDIT: pas plus le cas à partir d'Android 3.0+) La taille réelle du bitmap sera toujours comptée contre votre utilisation de tas pour les besoins de GC et assurez-vous que votre application n'utilise pas trop de mémoire.

    Cependant, le GC semble être modeste quand il s'agit de Bitmaps. Si vous supprimez simplement toutes les références rigoureuses, il serait parfois (dans mon cas) de rester sur les Bitmaps un peu plus longtemps, peut-être à cause de la manière étrange où les objets bitmap sont alloués / comptés. Bitmap.recycle semble être bon pour que le GC récupère cet objet plus rapidement.

    Quoi qu'il en soit, vous ne viderez pas la mémoire si vous n'appeliez pas Bitmap.recycle tant que vous ne conservez pas les références dures accidentellement. Vous pouvez rencontrer OutOfMemoryErrors si vous essayez d'allouer trop de bitmaps à la fois ou des bitmaps trop importants sans appeler .recycle.

    EDIT: Il est important de noter que depuis l'Android 3.0, les Bitmaps ne sont plus attribués à la mémoire native. Ils sont attribués sur le tas de VM comme tout autre objet Java. Cependant, ce que j'ai dit de ne pas avoir besoin d'appeler recyclage s'applique toujours.

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.