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 par un fichier de stockage, comme les allocations de tas et la mémoire allouée par mmap. Cela 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 natif non gérées (où les données de pixels bitmap sont stockées sur Android 8.0 (niveau d'API 26) et versions ultérieures) et les piles d'exécution des threads. Bien que l'OS puisse supprimer la mémoire associée à des fichiers en cas de pression, il ne peut pas supprimer la mémoire anonyme.

La taille de l'ensemble résident (RSS, Resident Set Size) correspond au nombre total de pages 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 consultée 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 sollicitée. Si nécessaire, le système peut relire ces pages à partir de l'espace d'échange.

Globalement, l'utilisation de la mémoire (RSS anonyme + swap) est une mesure du nombre total de pages de mémoire de votre application qui ne sont pas sauvegardées dans un fichier de stockage, y compris toute mémoire qui est également conservée par le système dans le swap. Le suivi anonyme RSS + swap vous permet de voir l'espace mémoire utilisé réel et non expulsable 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 instructions de cette page.

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

Android Vitals

Android Vitals indique l'utilisation de la mémoire de votre application en fonction des é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 influencé par les activités ou les composants d'UI non évincés.
  • Service de premier plan : l'application exécute un service de premier plan. Étant donné que ces services sont conçus pour les tâches de longue durée, ils sont de bons candidats pour les fuites cumulatives de cycle de vie qui gonflent de manière agressive 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'a pas encore été mise en cache. C'est là que les fuites de traitement en arrière-plan se produisent.
  • En cache : l'application est en cache. Cet état est très sensible à la pression exercée sur la mémoire système, comme les arrêts pour cause de mémoire insuffisante. Étant donné que l'OS peut expulser cet état de processus à volonté, cet état n'est fourni qu'à des fins de débogage.

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

Android Vitals décompose également l'utilisation de la mémoire de votre application par groupes de RAM. La métrique sur l'utilisation de la mémoire s'affiche sous la forme d'un graphique chronologique des valeurs de centiles quotidiens, ainsi que 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 du skew de queue

Pour identifier les fuites de mémoire, recherchez une divergence entre vos utilisateurs typiques (P50) et vos utilisateurs de fin de spectre (P90) dans Android Vitals. Alors que le gonflement général des ressources 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 fortement les données de fin 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 des sessions prolongées. Dans certains cas d'utilisation, un ratio élevé n'indique pas toujours une fuite. Toutefois, 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 une utilisation excessive de la mémoire en local

Pour commencer à diagnostiquer la source d'une utilisation excessive de la mémoire, vous pouvez capturer une empreinte de la mémoire avec 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 un vidage de tas en local après avoir testé les principaux parcours utilisateur de votre application.

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

  • WebViews et sessions de navigateur intégré dans l'application
  • Défilement infini avec de nombreux éléments multimédias
  • Flux de création et de modification de composants

Pour examiner les éventuelles fuites de mémoire, commencez par identifier les processus les plus gourmands à l'aide du tableau Nom du processus dans le tableau de bord Android Vitals sur l'utilisation de la mémoire. Ensuite, exécutez les parcours utilisateur correspondants en local et collectez les vidages de tas 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 la détection des bitmaps en double afin d'optimiser votre utilisation des images.

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

Voici un exemple de réponse que les compétences d'IA pourraient fournir :

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 vidages de tas

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

Améliorer l'utilisation de la mémoire

Consultez ces sections pour savoir comment améliorer l'utilisation de la mémoire de votre application :

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.

Précédent
Tueurs de mémoire faible (LMK)
Suivant
Wakelocks partiels figés