Utilisation de la mémoire (RSS anonyme + espace)

L'utilisation de la mémoire (RSS anonyme + espace d'échange) est une métrique d'Android Vitals qui reflète l'utilisation de la mémoire par votre application.

La mémoire anonyme est une mémoire non sauvegardée sur un fichier de stockage, comme les allocations de tas de mémoire et la mémoire allouée par mmap. Elle capture les allocations de mémoire dynamiques de votre application, y compris le tas de mémoire Java ou Kotlin, les allocations de tas de mémoire natives non gérées (où les données de pixels bitmap résident sur Android 8.0 (niveau d'API 26) et versions ultérieures) et les piles d'exécution de threads. Bien que le système d'exploitation puisse supprimer la mémoire sauvegardée par un fichier sous pression, il ne peut pas supprimer la mémoire anonyme.

La taille de l'ensemble résident (RSS) correspond au nombre total de pages de mémoire (partagées et non partagées) utilisées par un processus et conservées dans la RAM physique. Une page est considérée comme "partagée" si elle est accessible par plusieurs processus (par exemple, des applications qui accèdent à la même bibliothèque).

Pour la mémoire anonyme, le système peut écrire des pages dans l'espace d'échange (ou zRAM sur Android) lorsque la mémoire est sous pression. Le système peut relire ces pages à partir de l'espace d'échange si nécessaire.

Dans l'ensemble, l'utilisation de la mémoire (RSS anonyme + espace d'échange) mesure le nombre total de pages de mémoire de votre application qui ne sont pas sauvegardées par un fichier de stockage, y compris toute mémoire également conservée par le système dans l'espace d'échange. Le suivi du RSS anonyme + de l'espace d'échange vous permet de voir l'espace mémoire utilisé réel et inévitable de votre application.

Si l'utilisation de la mémoire de votre application est élevée, examinez le problème plus en détail et résolvez-le en suivant les conseils de cette page.

Identifier l'utilisation élevée de la mémoire

Android Vitals

Android Vitals partage l'utilisation de la mémoire de votre application, répartie selon les états de processus suivants :

• Premier plan : le processus de l'application est visible. Un P99 élevé affecte souvent les performances perçues par l'utilisateur (à-coups ou plantages OOM) et est fortement lié à la conservation de composants ou d'activités d'UI qui ne sont plus nécessaires.
• Services perçus par l'utilisateur : le processus de l'application s'exécute dans un état perceptible. Cela inclut les services de premier plan, les tâches accélérées et les tâches de transfert de données déclenchées par l'utilisateur. Cela peut également s'étendre aux services liés au système ou aux services liés à d'autres applications. Étant donné que ces services sont conçus pour les tâches de longue durée, la conservation de la mémoire en raison de fuites ou le non-libération des ressources peuvent augmenter la queue P99 au fil du temps.
• Arrière-plan : l'application exécute un service d'arrière-plan ou a récemment été mise en arrière-plan, mais n'est pas encore mise en cache. C'est là que les fuites de traitement en arrière-plan et les ressources non libérées peuvent s'accumuler. Étant donné que cet état de processus est moins important que les processus de premier plan ou perceptibles, essayez d'éviter de conserver de grandes quantités de mémoire dans cet état.
• En cache : l'application est dans un état mis en cache. Cet état est très sensible à la pression de la mémoire système, comme les LMK. Étant donné que le système d'exploitation peut supprimer cet état de processus à tout moment, cet état n'est fourni qu'à des fins de débogage.

Pour comprendre comment ces états de processus sont corrélés aux onTrimMemory rappels, consultez les conseils sur la libération de mémoire en réponse à des événements.

Android Vitals répartit également l'utilisation de la mémoire de votre application par buckets de RAM. La métrique d'utilisation de la mémoire s'affiche sous forme de chronologie des valeurs de centile quotidiennes, ainsi que de la valeur quotidienne la plus récente pour les 50e et 90e centiles.

Une fois que vous avez identifié votre référence de mémoire, suivez les conseils pour diagnostiquer et améliorer l’utilisation excessive de la mémoire.

Identifier les fuites de mémoire à l'aide de l'asymétrie de la queue

Pour identifier les fuites de mémoire, recherchez une divergence entre vos utilisateurs types (P50) et vos utilisateurs de queue (P90) dans Android Vitals. Bien que le gonflement général des composants augmente la mémoire de manière uniforme sur tous les centiles, les fuites de mémoire s'accumulent au fil du temps, ce qui fausse considérablement les données de queue.

Vous devez comparer vos métriques P90 et P99 à votre référence P50 par nom de processus. Si votre ratio P90/P50 dépasse 3,5, cela indique une fuite de mémoire probable lors de sessions prolongées. Dans certains cas d'utilisation, un ratio élevé n'indique pas toujours une fuite, mais vous devez évaluer le workflow spécifique pour déterminer si l'utilisation élevée de la mémoire est un comportement attendu.

Ressources

Diagnostiquer localement l'utilisation excessive de la mémoire

Pour commencer à diagnostiquer la source d'une utilisation excessive de la mémoire, vous pouvez capturer une empreinte de la mémoire avec Record heap dump (Enregistrer l'empreinte de la mémoire) dans les paramètres du développeur, Android Studio ou Perfetto. Nous vous recommandons de commencer par capturer une empreinte de la mémoire localement après avoir testé les parcours utilisateur principaux de votre application.

Nous vous recommandons tout particulièrement de tester les parcours utilisateur suivants :

• WebViews et sessions de navigateur intégrées à l'application
• Défilement infini avec de nombreux médias
• Flux de création et de modification de composants

Pour examiner les fuites de mémoire potentielles, identifiez d'abord les processus les plus consommateurs à l'aide du tableau Process name (Nom du processus) dans le tableau de bord d'utilisation de la mémoire d'Android Vitals. Ensuite, exécutez les parcours utilisateur correspondants localement et collectez des empreintes de la mémoire dans différents états de processus (visible, service de premier plan et mis en cache) pour vérifier si l'application libère de la mémoire après avoir été mise en arrière-plan.

Si vous déboguez des problèmes de mémoire à l'aide du profileur Android Studio, vous pouvez également utiliser l'intégration LeakCanary pour simplifier la détection des fuites et des bitmaps en double afin d'optimiser l'utilisation de vos images.

Une fois l'empreinte de la mémoire collectée, nous vous recommandons d'utiliser les compétences d'IA de Perfetto pour l'analyser et identifier les sources potentielles d'utilisation élevée de la mémoire.

Voici un exemple de réponse possible des compétences d'IA :

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

Ressources supplémentaires pour interpréter les empreintes de la mémoire

Les ressources suivantes fournissent plus d'informations sur l'interprétation des empreintes de la mémoire et le débogage de l'utilisation de la mémoire :

• Analyse manuelle : consultez les conseils de l'explorateur d'empreintes de la mémoire Perfetto pour découvrir comment parcourir et interpréter les visualisations d'empreintes de la mémoire dans l'UI Perfetto.
• Allocations Java/Kotlin : consultez Visualiser votre première empreinte de la mémoire ART pour obtenir une procédure pas à pas d'analyse des empreintes de la mémoire Android Runtime (ART).
• Allocations natives : consultez la documentation sur le profilage natif Perfetto pour découvrir comment collecter et analyser les profils de mémoire natifs (C/C++).
• Inspection de l'interface de ligne de commande : utilisez adb dumpsys meminfo pour obtenir une répartition rapide de l'utilisation de la mémoire de votre application sur un appareil.
• Analyse assistée par l'IA : utilisez les compétences d'IA de Perfetto pour exécuter une analyse basée sur un LLM afin de détecter les fuites de mémoire et les allocations excessives dans vos traces.
• Analyse basée sur SQL : utilisez les compétences SQL et d'analyse de traces de Perfetto pour exécuter des requêtes structurées et des scripts spécialisés afin d'analyser des données de trace complexes.

Améliorer l'utilisation de la mémoire

Consultez ces sections pour en savoir plus sur l'amélioration de l'utilisation de la mémoire de votre application :

• Réduire l'empreinte du code et des ressources de votre application
• Surveiller la mémoire disponible et l'utilisation de la mémoire
• Utiliser des constructions de code plus efficaces pour la mémoire

Pour obtenir des conseils détaillés sur la résolution des problèmes de mémoire, consultez le guide Gérer la mémoire de votre application.