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 pequeno formato, 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 exige mais esforço para carregar um dispositivo Wear OS do que um dispositivo móvel. Embora os usuários possam carregar os dispositivos móveis em vários intervalos ao longo do dia, eles precisam retirar o dispositivo Wear OS do corpo antes de carregar.

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

  • O design do app precisa aproveitar bem o formato do Wear OS. Ele não pode copiar diretamente o app para dispositivos móveis.
  • Use seu 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 eles ocorrem.

  • Sempre que possível, adie o trabalho do app até que o relógio esteja carregando. Isso se aplica principalmente a tarefas com uso intensivo de 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 fazer preempção de dados, imagens e atualizações que o usuário provavelmente vai querer ver no 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 ações específicas 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, digite o comando abaixo em uma janela de terminal na máquina de desenvolvimento:

adb shell dumpsys batterystats

Uma biblioteca no GitHub apresenta um analisador de estatísticas da bateria (link em inglês), que pode ser útil para ser executado com esse comando.

Eventos que afetam a duração da bateria

Antes de pensar especificamente no seu app, é importante pensar de maneira 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 exato de energia varia de acordo com o dispositivo.

Evento Impacto na duração da bateria Como mitigar
Acessar a rede, incluindo LTE e Wi-Fi Muito alto Adie o acesso à rede não essencial até que o dispositivo esteja carregando.
Ativar a tela e iniciar o modo interativo Alta Não incentive o usuário a manter a tela ligada por mais tempo do que necessário. Ofereça uma experiência que use o modo sempre ativado, também conhecido como modo ambiente.
Acessar o sensor de GPS Alta Se possível, aguarde até que o usuário solicite o acesso ao GPS.
Manter alto o uso da CPU Alta Consome fluxos usando o Jetpack Compose.
Acessar o sensor de frequência cardíaca Médio Use o tempo de ativação do processador ao receber callbacks da API do sensor, como ao usar Health Services no Wear OS.
Acessar outro dispositivo por Bluetooth Médio Mantenha as sessões curtas.
Manter um wakelock Médio Reduza a criação manual de wakelocks e use WorkManager.

Minimizar o tempo de tela ligada

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

  • Bloqueios de tela ligada:evite sempre que possível. Para testar, desative a opção Tela sempre ativada nas configurações do sistema e observe se a tela se apaga dentro do período de tempo limite.
  • Animações:minimize animações elaboradas e se concentre em transições breves para uma aparência mais profissional. 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 condicionamento físico. Se o app exigir a ativação permanente, verifique se ele faz o seguinte quando o dispositivo está no modo ambiente:

    • Reduz a porcentagem iluminada da tela do dispositivo.
    • Não mostra animações.
    • Não atualiza o conteúdo da tela, exceto durante um callback onAmbientUpdate().

Minimizar o uso da CPU

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

  • Mantenha o uso curto.
  • Faça o agrupamento de operações relacionadas para maximizar o tempo em que o processo do app está 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, os 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 os Serviços 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:

  • Toca 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.

O Battery Historian permite conferir ocorrências individuais de wakelocks longos, além de resumos do número total e da duração dos wakelocks que estão sendo mantidos. Inspecione o número e a duração dos wakelocks que o app mantém e compare essas informações com os padrões de uso interativo do app:

  • Verifique se há wake locks 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 estes:

  • A tela se apaga e o dispositivo entra no modo ambiente.

  • O app é encerrado com um deslize.

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

Power Profiler

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

  1. Inspecione o rastro do sistema quando a tela é desligada e o dispositivo entra 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 rastro e inspecionar o app para conferir se há alguma linha de execução 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 eventos importantes do app, incluindo eventos específicos do domínio. Para um app de música, isso incluiria tarefas como buscar playlists, fazer o download de um item de mídia específico, iniciar e interromper a reprodução. Ao definir esses eventos, você pode acessá-los no Perfetto e comparar o tempo deles com o uso de energia e CPU do app.

Analisar os jobs programados do app

Os jobs programados, usando o WorkManager, permitem que você realize trabalhos em segundo plano no 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 esgotar a bateria do dispositivo.

Use o Battery Historian para inspecionar a execução de jobs programados, em geral (Estatísticas do sistema > Estatísticas do Jobscheduler) e por app (Estatísticas do app > Job agendado). Confira a contagem total e a duração total:

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

Além disso, inspecione o gráfico do Battery Historian, analisando cada entrada do JobScheduler. Quando você mantém o ponteiro sobre uma entrada específica, o Battery Historian mostra o proprietário do job em execução. Considere o seguinte:

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

Sensores

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

Para analisar o uso do sensor no app, execute o seguinte comando em uma janela de 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 agrupamento, se definido.
  • Dados de amostra recentes.

Testar o cancelamento do registro de sensores

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

  1. Deslize para fechar o app.
  2. Toque na tela com a palma da mão. Essa ação desliga a tela ou a coloca no modo ambiente.

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

Camada de dados

Ao usar a API Data Layer, cada transmissão consome energia. Em particular, se você usar essa API para enviar dados, o app precisará ser ativado para receber os dados. Por esses motivos, use essa API de forma conservadora.

Confira algumas práticas recomendadas para usar a API Data Layer:

  • Aguarde até que o app esteja ativo antes de configurar um listener usando WearableListenerService.

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

    Transmita apenas mudanças de estado que atualizem a interface. Por exemplo, se a tela de atividade mostrar apenas "quilômetros percorridos" com um dígito 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 Data Layer no app, execute o seguinte comando em uma janela de 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ê tem um app de saúde e fitness, use os Recursos de saúde para otimizar o uso de sensores pelo app.

Blocos e complicações

Se o app for compatível com 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 o Firebase Cloud Messaging (FCM) ou jobs programados corretamente para enviar atualizações de dados. Evite uma taxa rápida de atualizações, que pode fazer com que o sistema programe trabalhos repetidos a uma taxa mais rápida do que o usuário ou a plataforma pode acessar os dados necessários para realizar esse trabalho.
  • Não programe trabalho para o bloco ou a complicação quando o usuário não estiver interagendo com ele.
  • Use abordagens off-line.
  • Compartilhe um único banco de dados entre o app principal, os blocos e as complicações. Isso ajuda a manter os dados consistentes em todas as plataformas da interface.