O uso da memória (RSS anônimo + troca) é uma métrica do Android vitals que reflete o uso da memória do seu app.
A memória anônima não é apoiada por um arquivo no armazenamento, como alocações de heap e memória alocada por mmap. Isso captura as alocações de memória dinâmicas do seu app, incluindo o heap Java ou Kotlin, alocações de heap nativas não gerenciadas (em que os dados de pixels de bitmap ficam no Android 8.0 (nível da API 26) e mais recentes) e pilhas de execução de linhas de execução. Embora o SO possa descartar a memória apoiada por arquivos sob pressão, ele não pode descartar a memória anônima.
Resident Set Size (RSS) é o número total de páginas de memória (compartilhadas e não compartilhadas) usadas por um processo que são mantidas na RAM física. Uma página é considerada "compartilhada" se for acessada por mais de um processo (como apps que acessam a mesma biblioteca).
Para memória anônima, o sistema pode gravar páginas no espaço de troca (ou zRAM no Android) quando a memória está sob pressão. O sistema pode ler essas páginas de volta da troca, se necessário.
No total, o uso da memória (RSS anônimo + troca) é uma medida do número total de páginas de memória do seu app que não são apoiadas por um arquivo no armazenamento, incluindo qualquer memória que também esteja sendo preservada pelo sistema na troca. O rastreamento de RSS anônimo + troca garante que você veja o consumo de memória verdadeiro e não removível do seu app.
Se o uso da memória do seu app for alto, investigue mais e corrija o problema usando as orientações nesta página.
Identificar o uso elevado da memória
Android vitals
O Android vitals compartilha o uso da memória do seu app dividido pelos seguintes estados de processo:
- Primeiro plano: o processo do app está visível. Um P99 alto aqui geralmente afeta o desempenho percebido pelo usuário (instabilidade ou falhas de memória insuficiente) e é fortemente impulsionado por componentes ou atividades de interface não removidos.
- Serviço em primeiro plano: o app está executando um serviço em primeiro plano. Como esses serviços são projetados para tarefas de longa duração, eles são candidatos principais a vazamentos cumulativos de ciclo de vida que aumentam agressivamente a cauda do P99 ao longo do tempo.
- Segundo plano: o app está executando um serviço em segundo plano ou foi colocado em segundo plano recentemente , mas ainda não foi armazenado em cache. É aqui que os vazamentos de processamento em segundo plano se acumulam.
- Armazenado em cache: o app está em um estado armazenado em cache. Esse estado é altamente sensível à pressão de memória do sistema, como LMKs. Como o SO pode remover esse estado de processo à vontade, ele é fornecido apenas para fins de depuração.
Para entender como esses estados de processo se correlacionam com onTrimMemory callbacks,
consulte as orientações sobre como liberar memória em resposta a eventos.
O Android vitals também divide o uso da memória do seu app por buckets de RAM. A métrica de uso da memória é mostrada como uma linha do tempo de valores percentis diários, juntamente com o valor diário mais recente para os percentis 50 e 90.
Depois de identificar a linha de base de memória, siga as orientações para diagnosticar e melhorar o uso da memória excessivo.
Identificar vazamentos de memória usando a assimetria da cauda
Para ajudar a identificar vazamentos de memória, procure uma divergência entre os usuários típicos (P50) e de cauda (P90) no Android vitals. Embora o inchaço geral de recursos aumente a memória de maneira uniforme em todos os percentis, os vazamentos de memória se acumulam ao longo do tempo, distorcendo muito os dados da cauda.
Compare as métricas P90 e P99 com a linha de base P50 pelo nome do processo. Se a proporção de P90 para P50 exceder 3,5 vezes, isso indica um possível vazamento de memória durante sessões estendidas. Para determinados casos de uso, uma proporção elevada nem sempre indica um vazamento, mas você precisa avaliar o fluxo de trabalho específico para determinar se o uso da memória elevado é o comportamento esperado.
Recursos
Diagnosticar o uso da memória excessivo localmente
Para começar a diagnosticar a origem do uso da memória excessivo, você pode capturar um heap dump com a opção Gravar heap dump nas configurações do desenvolvedor, no Android Studio ou no Perfetto. Recomendamos começar capturando um heap dump localmente após testar as principais jornadas do usuário do seu app.
Recomendamos especialmente testar as seguintes jornadas do usuário:
- Webviews e sessões de navegador no app
- Rolagem infinita com muitos arquivos de mídia
- Fluxos de criação e edição de recursos
Para investigar possíveis vazamentos de memória, primeiro identifique os processos de maior consumo usando a tabela Nome do processo no painel de uso da memória do Android vitals. Em seguida, execute as jornadas do usuário correspondentes localmente e colete heap dumps em diferentes estados de processo (visível, serviço em primeiro plano e armazenado em cache) para verificar se o app libera memória após ser colocado em segundo plano.
Se você estiver depurando problemas de memória usando o Android Studio Profiler, também poderá usar a integração do LeakCanary para simplificar a detecção de vazamentos e a detecção de bitmaps duplicados para otimizar o uso de imagens.
Depois de coletar o heap dump, recomendamos usar as habilidades de IA do Perfetto para analisar o heap dump e identificar possíveis fontes de uso da memória elevado.
Confira um exemplo de resposta das habilidades de 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.
Recursos extras para interpretar heap dumps
Os recursos a seguir fornecem mais informações sobre como interpretar heap dumps e depurar o uso da memória:
- Análise manual: use as orientações do Perfetto Heap Dump Explorer (link em inglês) para aprender a navegar e interpretar visualizações de heap dump na interface do Perfetto.
- Alocações Java/Kotlin:leia Visualizar seu primeiro heap dump do ART para conferir um tutorial detalhado sobre como analisar heap dumps do Android Runtime (ART).
- Alocações nativas:consulte a documentação do Perfetto Native Profiling (link em inglês) para aprender a coletar e analisar perfis de memória nativos (C/C++).
- Inspeção da CLI:use adb dumpsys meminfo para ter um detalhamento rápido do uso da memória do seu app em um dispositivo.
- Análise assistida por IA: aproveite as habilidades de IA do Perfetto para executar análises com tecnologia LLM para ajudar a detectar vazamentos de memória e alocações excessivas nos seus rastros.
- Análise baseada em SQL: use as habilidades de SQL e análise de rastros do Perfetto para executar consultas estruturadas e scripts especializados para analisar dados de rastros complexos.
Melhorar o uso da memória
Consulte estas seções para saber mais sobre como melhorar o uso da memória do seu app:
- Reduzir o consumo de código e recursos do app
- Monitorar a memória disponível e o uso da memória
- Usar mais construções de código com eficiência de memória
Para orientações detalhadas sobre como corrigir problemas de memória, consulte o guia Gerenciar a memória do app.