Corruption de Mémoire
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dernière mise à jour
Cet article vous a-t-il été utile ?
Chaque application a besoin de mémoire comme ressource pour faire son travail. Pour garantir que chaque application Android dispose de suffisamment de mémoire, le système Android doit gérer efficacement l’allocation de mémoire. Le runtime Android déclenche le Garbage Collection (GC) lorsque la mémoire est insuffisante. Le but de GC est de récupérer de la mémoire en nettoyant les objets qui ne sont plus utiles. Il y parvient en trois étapes.
Il Parcourt toutes les références d'objets en mémoire à partir des racines GC et marque les objets actifs qui ont des références à partir des racines GC.
Tous les objets non marqués (déchets) sont effacés de la mémoire.
Les objets vivants sont réorganisés.
En bref, tout ce qui sert l'utilisateur doit être conservé en mémoire et tout le reste doit être effacé de la mémoire pour libérer des ressources.
Cependant, lorsque le code est mal écrit et que les objets inutilisés sont référencés d'une manière ou d'une autre à partir d'objets accessibles, GC marque les objets inutilisés comme objets utiles et n'est donc pas en mesure de les supprimer. C'est ce qu'on appelle une fuite de mémoire.
Sous Android, la réactivité des applications est surveillée par les services système Activity Manager et Window Manager. Android affiche la boîte de dialogue ANR pour une application particulière lorsqu'il détecte l'une des conditions suivantes:
Il y a un délai de réponse supérieur à 5 secondes après un événement (key press, screen touch...) Un Broadcast Receiver n'a pas fini de s'executer après 10 secondes.
Avec :
Leak Canary crée des références faibles aux activités de votre application. (Vous pouvez également le personnaliser en ajoutant des montres à d'autres objets.) Il vérifie ensuite si la référence est effacée après GC. Sinon, il vide le tas dans un fichier .hprof et l'analyse pour confirmer s'il y a une fuite. S'il y en a un, il affiche une notification et dans une application distincte, il affiche l'arborescence de référence de la façon dont la fuite se produit.
Avec Android Studio:
Compiler et lancer le debug build sur un appareil ou emulateur connecté à l'hôte.
Accédez à l'activité suspecte, puis revenez à l'activité précédente qui fera apparaître l'activité suspecte de la pile de tâches.
Dans Android Studio -> Fenêtre Android Monitor -> section Memory, cliquez sur le bouton Initiate GC. Cliquer ensuite sur le bouton Dump Java Heap.
Android Studio va alors ouvrir le dump .hprof. Dans le viewer du fichier, il y a plusieurs moyens de vérifier la présence de fuites mémoire. Il est possible d'utiliser l'outil Analyzer Tasks dans le coin en haut à droite pour détecter les fuites d'activités automatiquement. Une autre possibilité est de switcher vers la vue Package Tree View dans le coin en haut à gauche et de vérifier que la colonne Total Count pour les objets activités contient moins d'une instance. (Le cas contraire signifiant qu'il y a une fuite)
Une fois la fuite trouvée, il faut ensuite trouver dans le Reference Tree l'objet référencant l'activité qui devrait avoir été supprimée.
Il existe de nombreuses façons de provoquer une fuite de mémoire dans Android. Pour résumer, il existe principalement trois catégories.
Fuite d'activité vers une référence statique
Fuite d'activité vers un worker thread
Fuite du thread lui-même
Fuite d'activité vers une référence statique Fuite d'activité vers un worker thread Fuite du thread lui-même Lien utile: https://github.com/frank-tan/SinsOfMemoryLeaks
TODO
