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

L'utilisation de la mémoire (RSS anonyme + espace d'échange) est une métrique 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ù résident les données de pixels Bitmap 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 sous pression. Le système peut relire ces pages à partir de l'espace d'échange si nécessaire.

Au total, l'utilisation de la mémoire (RSS anonyme + espace d'échange) est une mesure du nombre total de pages de mémoire de votre application qui ne sont pas sauvegardées sur un fichier de stockage, y compris toute mémoire qui est également conservée par le système dans l'espace d'échange. Le suivi de la taille de l'ensemble résident anonyme (RSS) et de l'espace d'échange vous permet de voir l'empreinte mémoire réelle et non supprimable 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.

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 du 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, 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. Pour comprendre comment ces états de processus sont corrélés aux rappels onTrimMemory, consultez les conseils sur la libération de mémoire en réponse aux événements.

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 votre utilisation des images.

Une fois l'empreinte de la mémoire collectée, nous vous recommandons d'utiliser la compétence Android Profiler pour analyser l'empreinte de la mémoire 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
Utilisation de la mémoire bitmap