Quels outils et méthodes Android fonctionnent le mieux pour détecter les fuites de mémoire / ressources? [fermé]

J'ai développé une application Android, et je suis au stade du développement d'une application pour téléphone où tout semble bien fonctionner et où vous voulez déclarer la victoire et le navire, mais vous savez qu'il doit juste y avoir des fuites de mémoire et de ressources là-dedans; et il n'y a que 16 Mo de tas sur Android et il est apparemment étonnamment facile de fuir dans une application Android.

J'ai regardé autour de moi et jusqu'à présent, je n'ai pu trouver des informations que sur «hprof» et «traceview» et aucun des deux n'a reçu beaucoup de critiques favorables.

Quels outils ou méthodes avez-vous rencontrés ou développés et souhaitez-vous partager peut-être dans un projet OS?

L'une des erreurs les plus courantes que j'ai trouvées lors du développement d'applications Android est l'erreur «java.lang.OutOfMemoryError: Bitmap Size Exceeds VM Budget». J'ai trouvé cette erreur fréquemment sur les activités utilisant beaucoup de bitmaps après avoir changé d'orientation: l'activité est détruite, créée à nouveau et les mises en page sont «gonflées» à partir du XML consommant la mémoire VM disponible pour les bitmaps.

Les bitmaps de la disposition d'activité précédente ne sont pas correctement désalloués par le garbage collector car ils ont croisé des références à leur activité. Après de nombreuses expériences, j'ai trouvé une assez bonne solution à ce problème.

Tout d'abord, définissez l'attribut "id" sur la vue parente de votre mise en page XML:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent"
     android:id="@+id/RootView"
     >
     ...

Ensuite, sur la méthode onDestroy () de votre activité, appelez la méthode unbindDrawables () en passant une référence à la vue parent puis effectuez un System.gc ()

@Override
protected void onDestroy() {
    super.onDestroy();

    unbindDrawables(findViewById(R.id.RootView));
    System.gc();
}


private void unbindDrawables(View view) {

    if (view.getBackground() != null) {
        view.getBackground().setCallback(null);
    }

    if (view instanceof ViewGroup) {
        for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
            unbindDrawables(((ViewGroup) view).getChildAt(i));
        }

        ((ViewGroup) view).removeAllViews();
    }
}

Cette méthode unbindDrawables () explore l'arborescence des vues de manière récursive et:

1. Supprime les rappels sur tous les drawables d'arrière-plan
2. Supprime les enfants sur chaque groupe de vues

Obtenez l'analyseur de mémoire Eclipse ( http://www.eclipse.org/mat/ ) Vérifiez http://kohlerm.blogspot.com/2010/02/android-memory-usage-analysis-slides.html et http: // kohlerm.blogspot.com/search/label/memory

Principalement pour les voyageurs Google du futur:

La plupart des outils java ne sont malheureusement pas adaptés à cette tâche, car ils n'analysent que le JVM-Heap. Chaque application Android dispose également d'un tas natif, qui doit également tenir dans la limite d'environ 16 Mo. Il est généralement utilisé pour les données bitmap, par exemple. Ainsi, vous pouvez vous heurter assez facilement à des erreurs de mémoire insuffisante même si votre JVM-Heap est d'environ 3 Mo, si vous utilisez beaucoup de drawables.

La réponse de @ hp.android fonctionne bien si vous ne travaillez qu'avec des arrière-plans bitmap mais, dans mon cas, j'avais BaseAdapterun ensemble de ImageViews pour un GridView. J'ai modifié la unbindDrawables()méthode comme conseillé pour que la condition soit:

if (view instanceof ViewGroup && !(view instanceof AdapterView)) {
  ...
}

mais le problème est alors que la méthode récursive ne traite jamais les enfants du AdapterView. Pour résoudre ce problème, j'ai plutôt fait ce qui suit:

if (view instanceof ViewGroup) {
  ViewGroup viewGroup = (ViewGroup) view;
  for (int i = 0; i < viewGroup.getChildCount(); i++)
    unbindDrawables(viewGroup.getChildAt(i));

  if (!(view instanceof AdapterView))
    viewGroup.removeAllViews();
}

afin que les enfants de AdapterViewsoient toujours traités - la méthode n'essaye tout simplement pas de supprimer tous les enfants (ce qui n'est pas pris en charge).

Cela ne résout pas tout à fait le problème, car ils ImageViewgèrent un bitmap qui n'est pas leur arrière-plan. J'ai donc ajouté ce qui suit. Ce n'est pas idéal mais ça marche:

if (view instanceof ImageView) {
  ImageView imageView = (ImageView) view;
  imageView.setImageBitmap(null);
}

Globalement, la unbindDrawables()méthode est alors:

private void unbindDrawables(View view) {
  if (view.getBackground() != null)
    view.getBackground().setCallback(null);

  if (view instanceof ImageView) {
    ImageView imageView = (ImageView) view;
    imageView.setImageBitmap(null);
  } else if (view instanceof ViewGroup) {
    ViewGroup viewGroup = (ViewGroup) view;
    for (int i = 0; i < viewGroup.getChildCount(); i++)
    unbindDrawables(viewGroup.getChildAt(i));

    if (!(view instanceof AdapterView))
      viewGroup.removeAllViews();
  }
}

J'espère qu'il existe une approche plus raisonnée pour libérer de telles ressources.

Bonne discussion Google I / O (2011) sur la gestion de la mémoire sous Android, ainsi que des détails sur les outils et les techniques de profilage de la mémoire:
http://www.youtube.com/watch?v=_CruQY55HOk

Valgrind a été porté sur Android (sponsorisé par Mozilla). Voir Valgrind sur Android - État actuel et prise en charge de l'exécution de Valgrind pour Android sur ARM (commentaire 67).

Eh bien, ce sont les outils qui correspondent aux formats uniques utilisés par Android ... Je pense que ce qui ne vous satisfait peut-être pas, c'est le cadre de code de test sous-jacent utilisé.

Avez-vous essayé de tester des zones de code simulées à l'aide de Android Mock Framework?