Discussion :

[gabrielS]

Bonjour,

lors du chargement d'une image, après plusieurs lancements de la même application, l'application crashe avec comme erreur : "Java.lang.OutOfMemoryError".

J'ai cru comprendre que les images n'étaient pas chargées au même endroit que les autres ressources du code, mais je ne comprends pas comment pallier le problème.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public void deinitPicture()
{
  _referencePicture.destroyDrawingCache(); // ne marche pas, la memory heap
                                           // grandit quand meme a chaque nouvelle ouverture/fermeture de l'application
  _referencePicture = null; // pas utile parce que fait par la VM ?
}

Merci de vos réponses

[nicroman]

Bonjour,

Avant de se lancer dans du code d'optimisation (qui ne fera que décaler le problème et non le résoudre), il faut trouver d'ou vient le memory-leak...
Et là on n'a pas beaucoup de code pour le deviner...
Ce qu'il faut savoir c'est qu'une application n'est pas quittée de suite quand la dernière activité est fermée... donc toutes les statiques, tous les threads peuvent créer des memory-leaks inattendus si il ne sont pas bien gérés... Le plus "classique" des memory leak, est l'utilisation d'un context en statiques..

Le GC de dalvik tourne sensiblement comme les autres GC
http://dubroy.com/blog/google-io-mem...-android-apps/

[gabrielS]

Bonjour,
J'ai trouvé un moyen de 'détruire' l'image, mais je ne suis pas certain que ce soit le bon.
Au final, l'application ne plante plus en tout cas :

je vous donne ma solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public void deinitPicture()
{
  _referencePicture.setImageResource(0);
  // au lieu de _referencePicture.destroyDrawingCache
}

et le memory leak vient de l'initialisation/désinitialisation de l'image. En gros, ça buggait juste après initPicture() qui fait juste un _referencePicture.setImageResource(R.drawable.XXXX);
Le problème venait du fait que en quittant l'appli, l'image n'était pas détruite, j'ai donc résolu avec le SetimageResource(0) lorsque je quitte l'appli, mais je pense qu'il existe d'autres moyens (destroyDrawingCache reste mystérieux pour moi, je pensais justement que c'était ce qu'il me fallait, mais je m'en sors autrement ).
A savoir, je n'ai plus de fuite de mémoire avec l'appel à setImageResource(0).

Merci tout de même

[nicroman]

Je continue de penser qu'il y a toujours un memory-leak....

Une image (j'imagine de type "Bitmap") est un "holder" vers un tableau de byte (byte[])... Ce tableau peut être désalloué à tout moment en appelant Bitmap.recycle(), mais bien entendu, l'objet Bitmap ne peut plus être utilisé par la suite...

Le GC s'occupe de ça tout seul comme un grand si il n'y a plus de référence à la Bitmap... donc si le faire à la main est utile quand on travaille avec une dizaine de grosses bitmap, il ne servira à rien pour un problème de memory-leak... pour la bonne raison est que ce tableau de byte[] n'est référencé *que* par Bitmap donc même si on appelle "recycle", on va continuer de leaker l'objet "Bitmap", et c'est *ca* qu'il faut corriger... d'autant qu'en général, ce n'est pas l'objet "Bitmap" qui est leaké, mais la vue (et donc tout le contexte avec l'activité). Et avec aussi peu de code, il est difficile d'aider....

[gabrielS]

Argh ui en effet, j'ai encore une fuite de mémoire (Grow Heap (frag case) to 36.368MB) et la fois d'après, j'ai Grow Heap (frag case) to 36.371MB et ça monte de 0.003 MB à chaque lancement de l'application...

et pour avoir plus de détails d'un point de vue code, c'est en fait une ImageView et non une Bitmap qui bouffe ma mémoire petit à petit.

Voila l'extrait du LogCat :

08-17 15:58:05.760: E/AndroidRuntime(28464): java.lang.OutOfMemoryError
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:577)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:445)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:775)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.content.res.Resources.loadDrawable(Resources.java:1968)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.content.res.Resources.getDrawable(Resources.java:677)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.widget.ImageView.resolveUri(ImageView.java:542)
08-17 15:58:05.760: E/AndroidRuntime(28464): at android.widget.ImageView.setImageResource(ImageView.java:315)

(ceci ce fait lorsque je fait un ImageView.setresource(R.id.xx)... Effectivement je ne sais pas d'où ça vient, et le fait de mettre la ressource à zéro a juste permis de réduire significativement la fuite de mémoire à chaque pas.. je ne sais pas comment la supprimer en entier


Pour encore plus de précision niveau Code, j'ai une Activity qui possède un GUIManager (qui s'occupe de toute l'interface graphique), et c'est dans cette classe que je fais initPicture() et deinitPicture() qui set la bonne ressource à l'image.

[nicroman]

Le OOM arrive pour dire, "c'est trop tard, y a eu trop de leak"....

Mais il nous faudrait du code pour chercher... par exemple, le GUIManager (???) me semble un bon début...

Ensuite, c'est simple....
Lancer 3 fois l'appli
Faire un memory-dump (dans le DDMS il y a un bouton pour ca).
Et regarder les objets instanciés à soi (en partant par exemple des ImageView encore instancés, et voir qui les maintient en vie)

Si MAT est installé dans Eclipse, le dump va automatique l'ouvrir
Aller directement à l'acceuil, puis histogram
Et taper dans le champ en dessous de "Class Name" le nom du package
Et bim, il y aura toutes les instances des classes "à soi"