The playground

More information here

Fuites de mémoire dans Android – identifiez, traitez et évitez

Johan Olsson Suivre div> 13 avril 2016 · 9 min lecture Dans notre quête quotidienne de créer de meilleures applications, nous devons, en tant que développeurs, prendre en compte de nombreuses choses afin de rester sur la bonne voie, dont l’une est de nous assurer que nos applications ne plantent pas. Les fuites de mémoire […]
Johan Olsson
Johan Olsson

Suivre

div>

13 avril 2016 · 9 min lecture

Dans notre quête quotidienne de créer de meilleures applications, nous devons, en tant que développeurs, prendre en compte de nombreuses choses afin de rester sur la bonne voie, dont l’une est de nous assurer que nos applications ne plantent pas. Les fuites de mémoire sont une cause fréquente de plantages. Ce problème particulier peut se manifester sous diverses formes. Dans la plupart des cas, nous constatons une augmentation constante de l’utilisation de la mémoire jusqu’à ce que l’application ne puisse pas allouer plus de ressources et se bloque inévitablement. En Java, cela entraîne souvent le lancement d’une exception OutOfMemoryException. Dans de rares cas, les classes divulguées peuvent même rester assez longtemps pour recevoir des rappels enregistrés, provoquant des bugs vraiment étranges et lançant trop souvent la fameuse exception IllegalStateException.

Pour aider les autres à minimiser le temps consacré à l’analyse de code, je vais présenter quelques exemples de fuites de mémoire, comment les identifier dans Android Studio et surtout comment les supprimer.

Avertissement

Le but de cet article et de ses exemples de code est de promouvoir une compréhension plus approfondie de la gestion de la mémoire, en particulier en Java. L’architecture générale, la gestion des threads et la gestion des requêtes HTTP en cours d’exécution ne sont pas idéales pour un environnement de production et servent simplement de support du point avancé: les fuites de mémoire dans Android sont une chose à considérer.

Enregistrer des écouteurs

Cela ne devrait pas vraiment être un problème, mais trop souvent, je vois des appels à diverses méthodes de registre, mais leurs homologues non enregistrés sont introuvables. C’est une source potentielle de fuites, car ces méthodes sont clairement conçues pour être équilibrées les unes par les autres. Sans appeler la méthode unregister, l’instance conservera probablement une référence longtemps après la fin de l’objet référencé et commencera ainsi à fuir la mémoire. Dans Android, cela est particulièrement gênant si cet objet est une activité, car ils contiennent souvent une grande quantité de données. Laisse-moi te montrer à quoi ça pourrait ressembler.

Dans cet exemple, nous laissons le gestionnaire de localisation Android nous informer des mises à jour de localisation. Tout ce dont nous avons besoin pour configurer cela est le service système lui-même et un rappel pour recevoir les mises à jour. Ici, nous implémentons l’interface de localisation dans l’activité elle-même, ce qui signifie que le gestionnaire de localisation contiendra une référence à notre activité. Maintenant, si l’appareil devait être pivoté, une nouvelle activité serait créée en remplacement de l’ancienne déjà enregistrée pour les mises à jour de localisation. Étant donné qu’un service système survivra très certainement à toute activité, le LocationManager conservera toujours une référence à l’activité précédente, ce qui empêchera le garbage collector de récupérer les ressources encore liées à cette activité particulière, entraînant une fuite de mémoire. La rotation répétée de l’appareil entraînera alors des activités non récupérables pour remplir la mémoire, conduisant finalement à une exception OutOfMemoryException.

Mais pour corriger une fuite de mémoire, il faut d’abord pouvoir la trouver. Heureusement, Android Studio dispose d’un outil intégré appelé Moniteur Android que nous pouvons utiliser pour observer l’utilisation de la mémoire, entre autres choses. Tout ce que nous avons vraiment à faire est d’ouvrir le moniteur Android et d’accéder à l’onglet Moniteurs pour voir la quantité de mémoire utilisée et allouée en temps réel.

Le moniteur Android dans Android Studio 2.0

Toutes les interactions provoquant l’allocation des ressources seront reflétées ici, ce qui en fait un endroit idéal pour suivre l’utilisation des ressources de votre application. Afin de trouver notre fuite de mémoire, nous devons savoir ce que contient la mémoire à un moment où nous soupçonnons que la mémoire a été divulguée. Pour cet exemple particulier, tout ce que nous avons à faire est de démarrer notre application, de faire pivoter le périphérique une fois, puis d’appeler l’action Dump Java Heap (à côté de la mémoire, la troisième icône à gauche). Cela générera un fichier hprof, qui contient un instantané de mémoire au moment où nous avons appelé l’action. Après quelques secondes, Android Studio ouvre automatiquement le fichier, ce qui nous donne une représentation visuelle soignée de la mémoire pour une analyse facile.

Je n’irai pas en profondeur sur la façon de naviguer dans l’énorme tas de mémoire. Au lieu de cela, je vais diriger votre attention sur les tâches de l’analyseur dans le coin supérieur droit de la capture d’écran ci-dessous. Tout ce que vous avez à faire pour détecter la fuite de mémoire introduite dans l’exemple ci-dessus est de vérifier Détecter les activités divulguées, puis d’appuyer sur play pour que l’activité divulguée apparaisse sous Résultats d’analyse.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.