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 é a memória sem arquivo de backup no armazenamento, como alocações de heap e memória alocada por mmap. Isso captura as alocações de memória dinâmica do app, incluindo o heap Java ou Kotlin, alocações de heap nativo não gerenciadas (em que os dados de pixel do 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 com backup de arquivo 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 app que não têm backup de 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 real e não removível do app.
Se o uso da memória do 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 app detalhado pelos seguintes estados de processo:
- Em 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 OOM) e é fortemente impulsionado pela retenção de componentes ou atividades da interface que não são mais necessários.
- Serviço perceptível: o processo do app está em execução em um estado perceptível. Isso inclui serviços em primeiro plano, jobs acelerados e dados iniciados pelo usuário de transferência de jobs. Ele também pode se estender a serviços vinculados ao sistema ou serviços vinculados por outros apps. Como esses serviços são projetados para tarefas de longa duração, manter a memória devido a vazamentos ou falha ao liberar recursos pode aumentar a cauda do P99 ao longo do tempo.
- Em segundo plano: o app está executando um serviço em segundo plano ou foi recentemente colocado em segundo plano, mas ainda não está em cache. É aqui que os vazamentos de processamento em segundo plano e os recursos não liberados podem se acumular. Como esse estado de processo é menos importante do que os processos em primeiro plano ou perceptíveis, tente evitar reter grandes quantidades de memória nesse estado.
- Em cache: o app está em um estado 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 detalha o uso da memória do 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 é um 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 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 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 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 adicionais 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 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 para aprender a coletar e analisar perfis de memória nativos (C/C++).
- Inspeção da CLI:use adb dumpsys meminfo para conferir um detalhamento rápido do uso da memória do 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 traces.
- Análise baseada em SQL: use as habilidades de análise de trace e SQL do Perfetto para executar consultas estruturadas e scripts especializados para analisar dados de trace complexos.
Melhorar o uso da memória
Consulte estas seções para saber mais sobre como melhorar o uso da memória do 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.