Economizar energia e bateria

A eficiência energética é especialmente importante no Wear OS. Os princípios de design do Wear OS se concentram significativamente no uso de energia do dispositivo, porque o relógio é um formato pequeno, destinado a interações curtas.

Em comparação com dispositivos móveis maiores, os dispositivos Wear OS têm baterias menores, então qualquer consumo de bateria é mais perceptível. Além disso, o usuário precisa de mais esforço para carregar um dispositivo Wear OS em comparação com um dispositivo móvel. Embora os usuários possam carregar os dispositivos móveis em vários intervalos ao longo do dia, eles precisam desconectar um dispositivo Wear OS do corpo antes de carregar o dispositivo.

Para melhorar a eficiência energética do seu app, siga estas práticas recomendadas de design:

• O design do app precisa fazer bom uso do formato do Wear OS. Ele não pode copiar diretamente o app para dispositivos móveis.
• Use o app para dispositivos móveis atual para ajudar em determinados casos de uso. Por exemplo, a Internet e a sincronização no relógio são caras. Considere se o dispositivo móvel pode fazer o trabalho pesado e se o dispositivo Wear OS recebe mudanças nos dados.
• Projete seus casos de uso para interações mais curtas.
• Considere quais eventos do Wear OS você usa e com que frequência esses eventos ocorrem.

• Sempre que possível, adie o trabalho do app até que o relógio esteja carregando. Isso se aplica especialmente a tarefas com muitos dados, como sincronização de dados e organização de bancos de dados.

  Se o dispositivo estiver carregando e tiver uma conexão Wi-Fi, programe jobs para buscar dados, imagens e atualizações que o usuário provavelmente quer ver no seu app.

Este guia de energia ajuda você a entender quando e como o sistema executa seu app e como limitar o tempo de execução e o consumo de bateria do app. Para saber mais sobre como determinadas ações são realizadas, como carregar um app ou rolar uma lista, acesse orientações relacionadas à performance, como o guia de performance do Compose no Wear OS.

Monitorar o uso da bateria ao longo do tempo

Para analisar as estatísticas de bateria de um dispositivo Wear OS que executa seu app, insira o comando abaixo em uma janela do terminal na máquina de desenvolvimento:

adb shell dumpsys batterystats

Uma biblioteca no GitHub apresenta um analisador de estatísticas de bateria, que pode ser útil para executar com esse comando.

Eventos que afetam a duração da bateria

Antes de pensar no seu app especificamente, vale a pena pensar de forma mais geral sobre os eventos que consomem energia em um dispositivo Wear OS.

A tabela abaixo mostra o efeito relativo na duração da bateria em vários eventos comuns em apps para Wear OS. O consumo de energia exato varia entre os dispositivos.

Minimizar o tempo de tela ligada

No seu app para Wear OS, siga estes princípios de uso da tela:

• Bloqueios de tela ligada:evite sempre que possível. Para testar, desative o Display sempre ativado nas configurações do sistema e observe se a tela é desligada dentro do período de tempo limite.
• Animações:minimize animações elaboradas e, em vez disso, concentre-se em transições breves para uma aparência mais profissional. Em particular, evite animações e loops de longa duração. Se um loop for necessário, adicione uma pausa entre os loops que seja pelo menos tão longa quanto a própria animação.
• Tempo de ativação no modo ambiente: ofereça suporte ao modo sempre ativado, se necessário, como para casos de uso de fitness. Se o app exigir o modo sempre ativado, siga estas recomendações para o modo ambiente.

Minimizar o uso da CPU

No seu app para Wear OS, siga estes princípios de uso da CPU:

• Mantenha o uso curto.
• Agrupe todas as operações relacionadas para maximizar o tempo em que o processo do app fica inativo.

Minimizar wakelocks

Na maioria dos casos, evite operações que impeçam o app de entrar no modo de suspensão, como wakelocks. Por exemplo, em apps de saúde e fitness, treinos de longa duração não precisam de um wakelock. Use o tempo de ativação do processador ao receber callbacks da API do sensor, como ao usar Recursos de Saúde no Wear OS.

Há alguns casos em que é possível adquirir um wakelock, como quando o app faz uma das seguintes ações:

• Reproduz mídia em segundo plano.
• Usa WorkManager ou JobScheduler. O sistema mantém um wakelock em seu nome ao executar o job em segundo plano.

Para depurar wake locks localmente, use o Inspetor de tarefas em segundo plano do Android Studio, a rastreamento do sistema ou adb shell dumpsys batterystats para inspecionar ocorrências individuais de wakelocks longos, bem como resumos do número total e da duração dos wakelocks mantidos. Compare o número e a duração dos wakelocks que seu app mantém com os padrões de uso interativo do app:

• Verifique se há wakelocks inesperados.
• Se a duração for maior do que o esperado, considere se o trabalho está bloqueado em alguma dependência, como a disponibilidade da rede.

Inspecionar como o app fica inativo

Considere o que o app ativo está fazendo quando eventos importantes do dispositivo ocorrem, como os seguintes:

• A tela é desligada e o dispositivo entra no modo ambiente.

• O app é dispensado por deslize.

Para analisar a atividade do app, use as ferramentas mostradas nas seções abaixo.

Power Profiler

O Power Profiler pode ser acessado no menu do Android Studio selecionando View > Tool Windows > Profiler:

1. Inspecione o rastreamento do sistema quando a tela for desligada e o dispositivo entrar no modo ambiente.
2. Procure qualquer trabalho que continue e o nível de uso da CPU do dispositivo.

Perfetto

O Perfetto permite gravar um rastreamento e inspecionar seu app para verificar se há threads fazendo algum trabalho quando a tela é desligada, o dispositivo entra no modo ambiente ou o usuário dispensa a atividade do app.

Defina eventos personalizados para marcar os eventos significativos do app, incluindo eventos específicos do domínio. Para um app de mídia, isso inclui tarefas como buscar playlists, fazer o download de um item de mídia específico, iniciar a reprodução e interromper a reprodução. Ao definir esses eventos, você pode vê-los no Perfetto e comparar o tempo deles com o uso de CPU e energia do app.

Você também pode usar a CLI do Android para instalar a android-profiler habilidade (android skills add android-profiler), que permite que agentes de IA gravem rastreamentos do sistema Perfetto na linha de comando e analisem trilhos de energia, wake locks e estados de suspensão do dispositivo.

Analisar os jobs programados do app

Os jobs programados, usando WorkManager, permitem que você execute trabalhos em segundo plano no seu app. Embora alguns trabalhos em segundo plano precisem ser periódicos, não execute jobs com muita frequência ou por um longo período, porque isso pode consumir a bateria do dispositivo.

Use o Inspetor de tarefas em segundo plano do Android Studio (View > Janelas de ferramentas > App Inspection) ou execute adb shell dumpsys jobscheduler e adb shell dumpsys batterystats para inspecionar a execução de jobs e workers programados. Verifique a frequência de execução e a duração total:

• Se um job for executado com muita frequência, considere reduzir essa frequência.
• Verifique se o tempo total de execução corresponde ao esperado e não é significativamente maior.

Você também pode gravar um rastreamento do sistema para correlacionar a execução do job com a atividade do app em uma linha do tempo. Considere o seguinte:

• Para seu app, a duração da execução precisa fazer sentido.
• Considere se os jobs ocorrem enquanto o app está em execução ou se os jobs representam um trabalho periódico em segundo plano.

Sensores

Os dispositivos Wear OS têm muitos sensores diferentes, como GPS. Na maioria dos casos, use os Recursos de Saúde no Wear OS em vez de interagir diretamente com SensorManager. Em muitos casos, os Recursos de Saúde agrupam dados de forma inteligente para melhorar a performance da bateria.

Para analisar o uso do sensor no seu app, execute o comando abaixo em uma janela do terminal na máquina de desenvolvimento:

adb shell dumpsys sensorservice

Os resultados desse comando mostram o seguinte:

• Registros de sensores atuais e anteriores.
• Configuração do sensor, incluindo o agrupamento, se definido.
• Dados de amostra recentes.

Testar o cancelamento do registro de sensores

Para verificar se o app para de buscar dados do sensor conforme o esperado, teste os seguintes cenários:

1. Dispense o app por deslize.
2. Toque na tela com a palma da mão. Isso desliga a tela ou a coloca no modo ambiente.

Use o comando ADB da seção anterior para verificar se o sensor é mostrado corretamente como não registrado.

Camada de dados

Ao usar a API Camada de Dados, cada transmissão usa alguma energia. Em particular, se você usar essa API para enviar dados, o app precisará ser ativado para receber os dados. Por esses motivos, seja conservador com o uso dessa API.

Algumas práticas recomendadas adicionais para usar a API Camada de dados incluem o seguinte:

• Aguarde até que o app esteja ativo antes de configurar um listener usando WearableListenerService.
• Não use a API Data Layer para fazer ping no relógio periodicamente para verificar se um dispositivo ou app complementar está disponível. Ao enviar mensagens repetidamente, o app ativa o rádio e o processo do app remoto, o que consome a bateria do dispositivo mais do que o necessário. Em vez disso, use CapabilityClient para detectar a disponibilidade e os recursos do dispositivo ou envie mensagens apenas quando o estado mudar.

• Transmita mudanças de estado em vez de configurar atualizações rápidas. Essas mudanças de estado permitem que o dispositivo Wear OS realize cálculos de dados locais, como quando uma sessão de treino é iniciada.

  Transmita apenas mudanças de estado que atualizam a interface. Por exemplo, se a tela de atividades mostrar apenas "quilômetros percorridos" com uma casa decimal, não envie uma mudança de estado para o Wear OS sempre que o usuário avançar mais um metro.

Para analisar o uso da API camada de dados no seu app, execute o comando abaixo em uma janela do terminal na máquina de desenvolvimento:

adb shell dumpsys activity service WearableService

Os resultados desse comando incluem o seguinte:

• RpcService:permite ver com que frequência e quais caminhos estão sendo chamados usando MessageClient.
• DataService:permite ver com que frequência os itens de dados estão sendo definidos usando DataClient.

Apps de saúde e fitness

Se você mantém um app de fitness, use Recursos de Saúde para otimizar o uso de sensores do app.

• Para ExerciseClient, use um rastreamento do sistema, Perfetto ou adb shell dumpsys batterystats para verificar o comportamento correto no modo ambiente. Verifique se o app não é ativado com mais frequência do que a cada um ou dois minutos para receber dados ExerciseUpdate.
• Para o monitoramento geral de saúde durante todo o dia, use o PassiveMonitoringClient, conforme descrito no guia sobre como monitorar dados de saúde e fitness em segundo plano.

Blocos e complicações

Se o app oferece suporte a um bloco ou uma complicação, siga estas práticas recomendadas:

• Desative a atualização automática ou aumente a taxa de atualização para duas horas ou mais.
• Use Firebase Cloud Messaging (FCM) ou jobs programados adequadamente para enviar atualizações de dados. Evite uma taxa rápida de atualizações, o que pode fazer com que o sistema programe trabalhos repetidos em uma taxa mais rápida do que o usuário ou a plataforma podem acessar os dados necessários para realizar esse trabalho.
• Não programe o trabalho para o bloco ou complicação quando o usuário não estiver interagindo com ele.
• Use abordagens offline-first.
• Compartilhe um único banco de dados entre o app principal, os blocos e as complicações. Isso também ajuda a manter os dados consistentes nas superfícies da interface.