Como é o consumo de memória RAM em DAPs Android

A memória RAM em DAPs (Digital Audio Player) Android tem sido uma preocupação recorrente. O motivo disso é a busca por uma experiência mais fluida ao utilizar os aplicativos de música ou simplesmente para navegar pelo sistema operacional. Entretanto, a quantidade de memória RAM pode não ser uma barreira tão crítica quanto a maioria dos usuários pensam.

Aplicativos de streaming de música como Spotify, Apple Music e Tidal não exigem tanta memória RAM. Se for aberto somente um aplicativo por vez, dificilmente 3GB de memória RAM irá limitar de forma crítica a fluidez na navegação ou na reprodução das faixas.

Entretanto, existem aspectos que geram o consumo maior de memória RAM. Os aplicativos do Google e os serviços/recursos do Android podem afetar a fluidez na navegação pelo sistema operacional e pelos apps de música. Se o fabricante do Digital Audio Player não otimizar isso, pode haver problemas de performance.

Além disso, a utilização de uma versão mais recente do Android proporciona uma utilização melhor da memória RAM. Porém, é necessário avaliar a compatibilidade com drivers para o funcionamento adequado dos componentes do hardware e do software, além da exigência de maior poder de processamento para rodar novos recursos do sistema operacional.

Como o Android gerencia a execução de aplicativos?

O responsável por gerenciar a execução de aplicativos no Android é o ActivityManagerService (AMS). Ele lida com a duração das atividades e serviços, ajusta as prioridades de cada processo e funciona em conjunto com o LMKD (Low Memory Killer Daemon) para encerrar processos quando há pouca memória RAM disponível.

O LMKD é responsável por monitorar o uso de memória RAM e decidir quais processos devem ser finalizados. O objetivo e manter a estabilidade do sistema operacional. Para funcionar, o Low Memory Killer Daemon utiliza os seguintes mecanismos:

• Monitoramento de memória RAM: utiliza informações de memória e pode ser configurado para agir com base no “vmpressure level” (nível de pressão de memória), que é classificado em low (baixo), medium (médio) e critical (crítico).
• Limiares configuráveis: o encerramento de um processo se baseia em limiares de memória (low memory thresholds), que são definidos nas políticas “lowmemorykiller”. Os limites são definidos em relação à quantidade de memória livre ou níveis de pressão de memória (vmpressure).
• Classificação de processos por prioridade (OOM score): cada processo tem uma pontuação OOM (Out Of Memory) calculada com base na importância e prioridade. O LMKD irá encerrar processos com maior OOM score (menos importantes para manter o funcionamento do sistema operacional estável).
• Considera o PSI (Pressure Stall Information): o LMKD utiliza dados do PSI.

O PSI mede o tempo em que o sistema está sendo atrasado (stalling) por não haver recursos suficientes disponíveis (CPU livre, memória RAM suficiente, leitura/escrita de dados disponível). Na prática, ele ajuda a evitar que quedas de desempenho, “travadinhas” (jank/stutter) e quedas de FPS, melhorando a responsividade geral. Para isso ele monitora três recursos principais.

O OOM score (Out-Of-Memory score) é a pontuação utilizada pelo LMKD no Android para determinar quais processos devem ser encerrados primeiros quando a memória RAM disponível estiver baixa. Quanto maior for a pontuação, maior será a chance do processo ser encerrado.

O Android irá atribuir a pontuação (OOM score) com base no nível de prioridade (adj) do processo e na quantidade de memória utilizada.

O adj (adjustment level) é a forma como o Android classifica os processos de acordo com a sua importância para o usuário e para o sistema. Ele irá determinar qual processo deverá ser protegido ou descartado primeiro no momento em que a memória disponível estiver baixa.

Há uma hierarquia para os níveis de adj e funciona da seguinte forma:

• adj “-1000” – Processos críticos do sistema, que nunca devem ser encerrados – OOM score “- 1000”
• adj “0” – App ou serviço em primeiro plano (Foreground Service ou FGS), que está interagindo com o usuário – OOM score “0”
• adj “1” – App visível (Visible app), que é um processo visível, mas não está interagindo diretamente – OOM score “100”
• adj “2” – App percebido (Perceptible app) indiretamente (tocando música) – OOM score “200”
• adj “3-6” – Serviços em segundo plano (background) – OOM score “300-600”
• adj “7-8” – App anterior (Previous app) ou último app usado antes do atual – OOM score “700-800”
• adj “9” – App em cache (Cached app), que não está em uso no momento – OOM score “900”
• adj “15” – App vazio (Empity app), que não tem atividade ou serviços ativos – OOM score “1000”

Toda vez que o usuário trocar de app, o adj é recalculado em tempo real de forma automática.

O que acontece quando abrimos um aplicativo de música no Android?

Ao abrir um aplicativo de música no Android pela primeira vez, ele é classificado como sendo um app em primeiro plano (foreground). Isso faz com que o AMS defina o adj e o OOM score como “0”. Com isso, o app tem alta prioridade para não ser encerrado e o LMKD não irá “matá-lo”.

Quando você desliga a tela, mas mantem o app de música reproduzindo uma faixa, o AMS define o adj como “1” (aplicativo visível) ou “2” (aplicativo percebido indiretamente) e o OOM score 100 ou 200, dependendo do caso. Desta forma, o app de música permanecerá ativo, a menos que o sistema precise liberar memória.

Ao pausar a música e não interagir com o app de música durante um certo tempo, a tipo de processo mudará para “serviços em segundo plano” (background). Isso fará com que o AMS reduza o adj um nível entre 3 e 6 e o OOM score vá para algo entre 300 e 600. Desta forma, já é possível que o processo possa ser escolhido para ser encerrado caso o sistema precise liberar memória.

Mais controle na execução de apps em 1º e 2º plano no Android 13

No Android 13 foi implementado um novo recurso chamado FGS Task Manager (Foreground Services Task Manager), que dá ao usuário mais visibilidade e controle sobre apps que executam tarefas prolongadas em segundo plano (background), mesmo que tecnicamente estejam rodando em primeiro plano (foreground).

O FGS Task Manager surgiu em resposta a alguns aplicativos que utilizam os serviços em primeiro plano para se manterem “vivos” indefinidamente, driblando as restrições do Android para atividades em segundo plano.

Isso faz com que apareça uma notificação para o usuário sempre que um app executa processos em primeiro plano por tempo prolongado (geralmente mais de 20 minutos). Além disso, o usuário tem a opção de interromper (parar) esses aplicativos sem precisar entrar nas configurações.

Diferenças no comportamento do AMS no Android 10, 12 e 13

Os DAPs Android comercializados atualmente utilizam em sua maioria o Android 10, o Android 12 e o Android 13. As versões mais recentes do sistema operacional possuem um ActivityManagerService (AMS) melhor, fazendo com que o consumo de recursos seja mais inteligente e traga uma experiência mais fluida para o usuário. Confira abaixo as diferenças.

Gerenciamento de processos (adj/OOM)

• Android 10: Mais básico, com prioridades por tipo (foreground, background, etc.)
• Android 12: Mais refinado, com melhor diferenciação entre tipos de background (segundo plano).
• Android 13: Ajustes mais dinâmicos, considerando mais contexto e estado real de uso.

Aplicativos em primeiro plano (Foreground Services ou FGS)

• Android 10: Não há categoria específica para este tipo de app.
• Android 12: Introduziu-se tipos (MEDIA_PLAYBACK, LOCATION, etc.).
• Android 13: Validação obrigatória de tipo + FGS Task Manager (controle do usuário).

Notificações e influência no adj

• Android 10: Notificações mantêm o processo vivo, sem distinção de importância.
• Android 12: Igual ao Android 10.
• Android 13: Notificações com baixa prioridade não garantem mais adj alto.

Gestão de processos inativos

• Android 10: Básica, reativa.
• Android 12: Melhoria no tracking via Watchdog e GC.
• Android 13: Proativa, com detecção mais precisa de processos inúteis e limpeza rápida.

Monitoramento de uso de recursos

• Android 10: Estatísticas básicas (battery/CPU)
• Android 12: Mais métricas, integração com o BatteryStats.
• Android 13: AMS participa ativamente da decisão de manter ou matar processos por consumo excessivo.

Controle do usuário sobre processos ativos

• Android 10: Limitado.
• Android 12: Leve indicação via notificações.
• Android 13: FGS Task Manager mostra processos vivos e permite encerramento direto.

Conclusão

As versões mais recentes do Android ganharam melhorias relacionadas ao gerenciamento de recursos (memória RAM, processamento da CPU e GPU, leitura e escrita de dados da memória interna ou externa). Somando isso a otimização realizada pelas fabricantes nos Digital Audio Players (DAPs), como foi explicado neste artigo, a experiência do usuário tende a ser boa, mesmo utilizando um chipset (“processador”) mais antigo.

Recomendação de artigos relacionados ao tema:
• Por que utilizar um DAP (Digital Audio Player)?
• A evolução dos chipsets e a otimização do Android em DAPs