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

L'utilisation de la mémoire (RSS anonyme + espace d'échange) est une métrique 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. 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. 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.

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.

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 (jank 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 gonfler 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 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.

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.