Tutoriel sur les fuites de mémoire sous Android

Chaque thread possède sa propre pile, seules des données de types primitifs peuvent être stockées dans celle-ci, seul le thread propriétaire de cette pile pourra accéder à ces données. De ce fait logiquement la taille de la pile restera faible. Si vous arrivez à faire déborder cette zone mémoire, une exception sera levée de type StackOverflowError.

Par exemple, nous retrouvons les appels des procédures et classes dans la pile propre au thread. Pour ce faire, nous pouvons les récupérer directement par la méthode getStackTrace() de la classe Thread ou plus facilement, si vous voulez afficher la pile d'appels dans la console, via la méthode statique Log.getStackTraceString(Throwable t);

Cette zone mémoire est partagée par l'ensemble de l'application, celle-ci contient les objets. Par conséquent tout objet créé depuis l'application est sauvegardé dans cet espace mémoire et est accessible à l'ensemble de l'application. La libération de cet espace mémoire se fait par le ramasse-miette  (Garbage Collector). Elle est réalisée lorsque l'objet en question n'a pas de raison valable d'être gardé en mémoire. Celle-ci étant déterminée par la non-utilisation de la donnée en mémoire.

On pourrait décomposer cette zone mémoire comme ceci :

• la Young Generation

  • Eden Space : l'espace depuis lequel la mémoire est initialisée pour allouer la plupart des objets ;
  • le Survivor Space : l'espace qui contient les objets qui ont survécu au garbage de l'Eden Space ;

• la Old Generation

  • Tenured Generation : l'espace qui contient les objets qui ont existé pendant un moment dans la Survivor Space.

Si vous arrivez à faire déborder cette zone mémoire, une exception sera levée de type OutOfMemoryError.

Le ramasse-miette pourra de ce fait bouger la mémoire des objets comme bon lui semble, ne vous inquiétez pas, cela est complètement transparent pour le développeur Java.

Par exemple si nous appelons la méthode hashCode d'un objet qui nous retourne l'adresse interne de l'objet, celui-ci ne bougera pas, car sa valeur est sauvegardée lors d'une réallocation faite par le ramasse-miette.

Nous avons deux concepts pour la mémoire sous Java :

• ShallowHeap  : est la mémoire prise par un objet simple, par exemple pour un Integer cela sera 4 octets, pour un long 8, etc. Bien sûr pour les objets complexes, la taille de l'objet sera ajustée par un alignement de 8 octets ;
• RetainedHeap  : est la somme de la mémoire des objets retenue par un objet. En d'autres termes, quand l'objet sera supprimé, il libérera la retainedHeap.

Pour plus de compréhension, imaginez le graphe d'objets suivants, où chaque objet possède une shallowHeap de 100 et pointe les uns vers les autres selon le schéma ci-dessous. Nous mettons alors la valeur (R) de la retainedHeap de chaque objet.

Il existe deux autres espaces qui ne sont pas présents dans la heap, mais qui font partie de la gestion de la mémoire de Java (HotSpot Java JM) :

• la Permanent Generation : elle contient la représentation des données comme les classes et les méthodes des objets. Elle contient le byteCode et les données lues du fichier .class. C'est sur cet espace que s'effectue la réflexion ;
• la Code Cache : elle contient la mémoire qui est utilisée pour la compilation et le stockage du code natif.

Attention : depuis Java 8 , nous avons une nouvelle représentation de la HotSpot, la Permanent Generation a disparu pour laisser place à la MetaSpace. Voici les améliorations :

http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html

Pour générer ce fichier, il existe plusieurs méthodes que nous allons voir.

II-C-1-a. Code▲

@Override
public void onCreate() {
   super.onCreate();
   /**
   * Full path to a directory assigned to the package for its    persistent data. 
   * catch any error in the current Thread and dump the memory if an    outofmemoryerror 
   * can save the dump file in other path, as sdcard
   */
   Thread.currentThread().setUncaughtExceptionHandler(
new HeapDumpingUncaughtExceptionHandler(getApplicationInfo().dataDir));
}

/**
* Save the dump file in the given path
*
*/
public class HeapDumpingUncaughtExceptionHandler implements Thread.UncaughtExceptionHandler {

   private static final String HPROF_DUMP_BASENAME = "Android2ee.dalvik-hprof";
   private final String dataDir;

   public HeapDumpingUncaughtExceptionHandler(String dataDir) {
      this.dataDir = dataDir;
   }

   @Override
   public void uncaughtException(Thread thread, Throwable ex) {
      Log.w(getClass().getSimpleName(), "uncaughtException :" + dataDir);
      String absPath = new File(dataDir,       HPROF_DUMP_BASENAME).getAbsolutePath();
      // Dump the memory when we have an OutOfMemoryError
      if(ex.getClass().equals(OutOfMemoryError.class)) {
         try {
            // Dump "hprof" data to the specified file. This may cause a GC.
            Debug.dumpHprofData(absPath);
         } catch (IOException e) {
            Log.e(getClass().getSimpleName(),e.getMessage()) ;
         }
      }
   }
}

platform-tools/hprof-conv infile outfile

II-C-1-b. DDMS▲

Une méthode plus simple existe et consiste à utiliser le DDMS fourni par le SDK d'Android. Depuis le DDMS, vous trouverez deux actions qui sont Update Heap et Dump HPROF File. Il vous suffira alors de d'abord mettre à jour la Heap (via le bouton Update Heap) puis de cliquer sur le bouton Dump HPROF File. Ce fichier sera alors généré , pas besoin de le convertir pour ce cas-là.

Avant de récupérer la capture d'image de votre mémoire, vous pouvez provoquer un GC grâce au bouton « Cause GC » que vous trouverez depuis le DDMS.

Pour analyser ce fichier, vous aurez besoin de l'outil MAT (Memory Analyser Tool), qui est un plugin pour Eclipse.

Pour installer cet outil, il vous faudra récupérer le lien de la dernière release ici.

Ensuite depuis votre Eclipse, allez dans Help→ Instal New Software… Entrez ensuite cette URL http://download.eclipse.org/mat/1.4/update-site/.

Vous aurez également besoin de BIRT pour pouvoir afficher les graphiques depuis MAT. Pour cela, vous devrez entrer cette URL : http://download.eclipse.org/birt/update-site/4.3. BIRT est un outil open source pour créer des visualisations de données et des rapports qui peuvent être intégrés dans des applications client enrichi et Web.

II-C-2-a. Fonctionnement de MAT▲

Il vous suffit d'ouvrir le fichier hprof (généré ou non généré : MAT se chargera de cela pour vous) depuis Eclipse. Vous aurez alors une demande du type de rapport que vous voulez avoir comme ceci :

Leak Suspects Report : permet de vérifier que vous n'avez pas de fuite mémoire.

Component Report : permet d'analyser un ensemble de mémoires (duplication, collection , etc.).

Pas de stress, vous pourrez basculer entre les types depuis MAT.

MAT vous générera ensuite les données et vous obtiendrez quelque chose du genre :

Depuis cette page, vous avez différentes options accessibles depuis le menu :

• OverView : permet de voir une vue générale sur le rapport généré.
• Histogram : permet de voir l'ensemble des objets alloués sous forme de tableau.
• Dominator Tree : permet de voir l'ensemble des classes présentées dans le tas sous forme de tableau.
• Open Object Query Language : permet sous forme de requêtes SQL de rechercher des objets.
• Thread name, etc. : si possible, nous renvoie sous forme de tableau la liste des threads vivants.
• Run Expert System : est un sous-menu disponible vous permettant de générer d'autres rapports, les ouvrir,  ou les exécuter.
• Open Query Browser : des requêtes SQL prédéfinies pour vous faciliter la vie dans votre recherche dans le tas.