Notícias sobre produtos

Otimize a bateria do app usando a métrica de wake lock do Android Vitals

Leitura de 7 minutos
Alice Yuan
Engenheira de relações com desenvolvedores

A duração da bateria é um aspecto crucial da experiência do usuário, e os bloqueios de ativação têm um papel importante. Você está usando demais? Nesta postagem do blog, vamos explicar o que são bloqueios de despertar, quais são as práticas recomendadas para usá-los e como entender melhor o comportamento do seu app com a métrica do Play Console.

Uso excessivo de wake locks parciais no Android vitals

Agora o Play Console monitora o consumo elevado da bateria, com foco no uso excessivo de wake locks parciais, como um indicador principal de desempenho.

Esse recurso aumenta a importância da eficiência da bateria junto com os indicadores de estabilidade das métricas principais atuais: falhas e ANRs excessivos percebidos pelo usuário. Definimos um limite de mau comportamento para wake locks em excesso. A partir de 1º de março de 2026, se o título não atender a esse limite de qualidade, ele poderá ser excluído de plataformas de descoberta em destaque, como as recomendações. Em alguns casos, podemos mostrar um aviso na página de detalhes do app para indicar aos usuários que o app pode causar consumo elevado da bateria.

warning.png

O aviso de wake lock excessivo na visão geral do Android vitals.

Para dispositivos móveis, a métrica Android vitals se aplica a wake locks não isentos adquiridos enquanto a tela está desligada e o app está em segundo plano ou executando um serviço em primeiro plano. O Android vitals considera o uso de wake locks parciais excessivo se:

  • Os bloqueios de despertar são mantidos por pelo menos duas horas em um período de 24 horas.
  • Ele afeta mais de 5% das sessões do app, em média, durante 28 dias.

Os wake locks criados pelas APIs iniciadas pelo usuário audio, location e JobScheduler são isentos do cálculo de wake lock.

Como funcionam os wake locks

Um wake lock é um mecanismo que permite que um app mantenha a CPU de um dispositivo em execução mesmo quando o usuário não está interagindo ativamente com ele. 

Um wake lock parcial mantém a CPU em execução mesmo que a tela esteja desligada, impedindo que ela entre em um estado de "suspensão" de baixo consumo de energia. Um wake lock completo mantém a tela e a CPU em execução.

Há dois métodos para adquirir bloqueios de ativação parciais:

  • O app adquire e libera manualmente o wake lock usando as APIs PowerManager para um caso de uso específico. Geralmente, isso é adquirido em conjunto com um serviço em primeiro plano, uma API de ciclo de vida da plataforma destinada a operações perceptíveis pelo usuário.
  • Como alternativa, o wake lock é adquirido por outra API e atribuído ao app devido ao uso da API. Saiba mais sobre isso na seção de práticas recomendadas.

Embora os wake locks sejam necessários para tarefas como concluir o download de um arquivo grande iniciado pelo usuário, o uso excessivo ou inadequado pode causar um consumo elevado da bateria. Já vimos casos em que os apps mantêm wake locks por horas ou não os liberam corretamente, o que leva a reclamações dos usuários sobre o consumo elevado da bateria, mesmo quando eles não estão interagindo com o app.

Práticas recomendadas para o uso de bloqueio de despertar

Antes de explicar como depurar o uso excessivo de wake lock, confira se você está seguindo as práticas recomendadas. 

Considere estas quatro perguntas essenciais.


1. Você já pensou em outras opções de wake lock?

Antes de considerar a aquisição de um wake lock parcial manual, siga este fluxograma de tomada de decisão:

wakelock.png

Fluxograma para decidir quando adquirir manualmente um wake lock

  1. A tela precisa ficar ligada?
  2. O aplicativo está executando um serviço em primeiro plano?
    • Não: não é necessário adquirir manualmente um wake lock.
  3. A suspensão do dispositivo prejudica a experiência do usuário?
    • Não: por exemplo, atualizar uma notificação depois que o dispositivo é ativado não exige um wake lock.
    • Sim: se for essencial impedir que o dispositivo seja suspenso, como uma comunicação contínua com um dispositivo externo, continue.
  4. Já existe uma API mantendo o dispositivo ativo para você?
  5. Se você respondeu a todas essas perguntas e determinou que não há alternativa, adquira manualmente um wake lock.

2. Você está nomeando o wake lock corretamente?

Ao adquirir bloqueios de despertar manualmente, a nomenclatura adequada é importante para a depuração:

  • Não inclua informações de identificação pessoal (PII) no nome, como endereços de e-mail. Se PII for detectado, o wake lock será registrado como _UNKNOWN, dificultando a depuração.
  • Não nomeie seu wake lock de forma programática usando nomes de classes ou métodos, já que eles podem ser ofuscados por ferramentas como o Proguard. Em vez disso, use uma string codificada.
  • Não adicione contadores ou identificadores exclusivos às tags de wake lock. A mesma tag precisa ser usada sempre que o wake lock for executado para permitir que o sistema agregue o uso por nome, facilitando a detecção de comportamentos anormais.

3. O wake lock adquirido é sempre liberado?

Se você estiver adquirindo um wake lock manualmente, verifique se a liberação dele sempre é executada. Não liberar um wake lock pode causar um consumo elevado da bateria. 

Por exemplo, se uma exceção não capturada for gerada durante processamentoWork(), a chamada release() nunca vai acontecer. Em vez disso, use um bloco try-finally para garantir que o wake lock seja liberado, mesmo que ocorra uma exceção.

Além disso, é possível adicionar um tempo limite ao wake lock para garantir que ele seja liberado após um período específico, evitando que seja mantido indefinidamente.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Você pode reduzir a frequência de ativação?

Para solicitações periódicas de dados, reduzir a frequência com que o app ativa o dispositivo é fundamental para a otimização da bateria. Alguns exemplos de redução da frequência de ativação:

  • WorkManager:aumente o intervalo periódico em PeriodicWorkRequests.
  • SensorManager:aproveite o agrupamento em lote especificando maxReportLatencyMs ao registrar o listener.
  • Provedor de localização combinada:
    • Reduza a frequência de recuperação de localização usando getLastLocation para a localização em cache mais recente.
    • Use setPriority(PRIORITY_PASSIVE) para um método de atualização que consome menos bateria.
    • Além disso, você pode aproveitar o mecanismo de agrupamento de localizações definindo um intervalo mínimo de atualização com setMinUpdateIntervalMillis.

Confira mais detalhes na documentação de práticas recomendadas de wake lock.

Depurar o uso excessivo de wake locks

Mesmo com as melhores intenções, o uso excessivo de wake lock pode ocorrer. Se o app for sinalizado no Play Console, confira como depurar:

Identificação inicial com o Play Console

O painel de wake lock parcial excessivo do Android vitals oferece detalhamentos dos nomes de wake lock não isentos associados ao seu app, mostrando sessões e durações afetadas. Lembrete para usar a documentação e identificar se o nome do wake lock é mantido pelo app ou por outra API.

breakdowns2.png

O painel do Android vitals com wake locks parciais excessivos rolou para baixo até a seção de detalhamentos para mostrar as tags de wake lock excessivas.

Depuração de bloqueios de ativação excessivos mantidos por workers/jobs

É possível identificar wake locks mantidos pelo worker com este nome:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

A lista completa de variações de nomes de wake lock mantido pelo worker está disponível na documentação. Para depurar esses bloqueios de despertar, use o Inspetor de tarefas em segundo plano para depurar localmente ou aproveite getStopReason para depurar problemas no campo. 

Inspetor de tarefas em segundo plano do Android Studio

taskinspector.png


Captura de tela do Inspetor de tarefas em segundo plano, em que foi possível identificar um worker "WeatherSyncWorker" que tentou várias vezes e falhou.

Para depurar problemas de WorkManager localmente, use essa ferramenta em um emulador ou dispositivo conectado (nível da API 26 ou mais recente). Ela mostra uma lista de workers e seus status (concluído, em execução, enfileirado), permitindo inspecionar detalhes e entender as cadeias de workers. 

Por exemplo, ele pode revelar se um worker está falhando ou tentando novamente com frequência devido a limitações do sistema. 

Consulte a documentação do Inspetor de tarefas em segundo plano para mais detalhes.

WorkManager getStopReason

Para depurar workers com bloqueios de ativação excessivos em campo, use WorkInfo.getStopReason() no WorkManager 2.9.0 ou mais recente ou, para o JobScheduler, JobParameters.getStopReason() disponível no SDK 31 ou mais recente. 

Essa API ajuda a registrar o motivo da interrupção de um worker (por exemplo, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), identificando problemas como tempos limite frequentes devido ao esgotamento da duração do ambiente de execução.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Consulte Otimizar o uso da bateria para APIs de programação de tarefas para mais detalhes.

Depurar outros tipos de wake locks excessivos

Em cenários mais complexos que envolvem wake locks mantidos manualmente ou APIs que mantêm o wake lock, recomendamos usar a coleta de rastreamento do sistema para depurar.

Coleta de rastreamento do sistema

Um rastreamento do sistema  é uma ferramenta de depuração eficiente que captura um registro detalhado da atividade do sistema durante um período, fornecendo insights sobre o estado da CPU, a atividade da linha de execução, a atividade de rede e métricas relacionadas à bateria, como duração do trabalho e uso de wake lock.

É possível capturar um rastreamento do sistema usando vários métodos: 

powermgmt.png

Ative a categoria "power:PowerManagement" do Atrace na interface do Perfetto, na guia "Apps e serviços do Android". 

Independente do método escolhido, é fundamental garantir que você esteja coletando a categoria "power:PowerManagement" do Atrace para ativar a visualização dos rastreamentos de estado do dispositivo. 

Inspeção da interface do Perfetto e análise de SQL

Os rastros do sistema podem ser abertos e inspecionados na interface do Perfetto. Ao abrir o rastreamento, você vai encontrar uma visualização de vários processos em uma linha do tempo. As faixas em que vamos focar neste guia são as que estão em "Estado do dispositivo".

perfetto.png


Fixe as faixas em "Estado do dispositivo", como "App principal", "Estado da tela", "Wake locks longos" e "Jobs", para identificar visualmente os intervalos de wake lock de longa duração.

Cada bloco lista o nome do evento, quando ele começou e quando terminou. No Perfetto, isso é chamado de fração.

Para uma análise escalonável de vários rastreamentos, use a análise de SQL do Perfetto. Uma consulta SQL pode encontrar todos os bloqueios de despertar classificados por duração, ajudando a identificar os principais contribuintes para o uso excessivo.

Confira um exemplo de consulta que soma todas as tags de wake lock que ocorreram no rastreamento do sistema, ordenadas pela duração total:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Usar o ProfilingManager para coleta de rastreamento em campo

Para problemas difíceis de reproduzir, o ProfilingManager (adicionado no SDK 35) é uma API programática que permite aos desenvolvedores coletar rastreamentos do sistema em campo com gatilhos de início e fim. Ele oferece mais controle sobre os pontos de acionamento de início e fim da coleta de perfis e impõe a limitação de taxa no nível do sistema para evitar o impacto no desempenho do dispositivo. 

Confira a documentação do ProfilingManager para mais etapas sobre como implementar a coleta de rastreamento do sistema em campo, incluindo como capturar um rastreamento, analisar dados de criação de perfil e usar comandos de depuração local de forma programática.

Os rastreamentos do sistema coletados usando o ProfilingManager são semelhantes aos coletados manualmente, mas os processos do sistema e de outros apps são omitidos do rastreamento.

Conclusão

A métrica de wake lock parcial em excesso no Android vitals é apenas uma pequena parte do nosso compromisso contínuo de ajudar os desenvolvedores a reduzir o consumo elevado da bateria e melhorar a qualidade dos apps. 

Ao entender e implementar corretamente os wake locks, você pode otimizar significativamente o desempenho da bateria do app. Usar APIs alternativas, seguir as práticas recomendadas de wake lock e usar ferramentas de depuração eficientes, como o Inspetor de tarefas em segundo plano, rastreamentos do sistema e o ProfilingManager, é fundamental para garantir o sucesso do app no Google Play.

Escrito por:

Continuar lendo