Economizar energia e bateria

A eficiência de energia é especialmente importante no Wear OS. Os princípios de design do Wear OS se concentram significativamente no uso de energia do dispositivo, porque o smartwatch é 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 o consumo elevado da bateria é mais perceptível. Além disso, o usuário precisa se esforçar mais 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, é necessário remover o dispositivo Wear OS do corpo antes de carregá-lo.

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

  • O design do app precisa fazer bom uso do formato Wear OS. Ele não deve copiar diretamente seu app para dispositivos móveis.
  • Use seu app para dispositivos móveis atual para ajudar em determinados casos de uso. Por exemplo, Internet e sincronização no smartwatch 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 especialmente a tarefas com muitos dados, como sincronização e organização de bancos de dados.

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

Este guia de alimentação ajuda você a entender quando e como o sistema executa seu app e como você pode 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 as orientações relacionadas ao desempenho, como o Guia de performance do Compose no Wear OS.

Monitorar o uso da bateria ao longo do tempo

Para analisar as estatísticas da 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, 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, vale a pena pensar de maneira mais geral nos 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 de acordo com o dispositivo.

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

Minimizar o tempo de ativação da tela

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

  • Bloqueios de tela:evite sempre que possível. Para testar, desative a Tela sempre ativada nas configurações do sistema e observe se a tela apaga dentro do tempo limite.
  • Animações:minimize animações elaboradas e se concentre em transições mais breves para ter 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 loops de pelo menos a mesma animação.

  • Tempo acordado no modo ambiente:oferece suporte a sempre ativado, se necessário, como para casos de uso de condicionamento físico. Se o app exigir que o app esteja sempre ativado, verifique se ele faz o seguinte quando o dispositivo está no modo ambiente:

    • Reduz a porcentagem da tela do dispositivo iluminada.
    • Não exibe 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:

  • Seja breve.
  • Agrupe todas as operações relacionadas para maximizar o tempo em que o processo do app fica ocioso.

Minimizar wakelocks

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

Em alguns casos, não há problema em adquirir um wake lock, como quando o app realiza 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.

O Battery Historian permite ver ocorrências individuais de wakelocks longos, bem como resumos do número total e da duração dos wake locks retidos. Inspecione o número e a duração dos wake locks que seu app mantém e compare essas informações com os padrões de uso interativos do app:

  • Verifique se há wakelocks inesperados.
  • Se a duração for maior 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 faz quando ocorrem eventos principais do dispositivo, como este:

  • A tela apagará e o dispositivo entrará no modo ambiente.

  • O app é dispensado ao deslizar.

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

Energy Profiler

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

  1. Inspecione o rastro do sistema conforme 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, em seguida, inspecionar o app para conferir se há alguma linha de execução executando 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úsica, 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 da CPU e da energia do app.

Analisar os jobs programados do app

As tarefas agendadas que usam o WorkManager permitem que você execute trabalhos em segundo plano no app. Embora alguns trabalhos em segundo plano precisem ser periódicos, não os execute com muita frequência ou por longos períodos, porque isso pode descarregar a bateria do dispositivo.

Use o Battery Historian para inspecionar a execução de jobs programados, tanto em geral (Estatísticas do sistema > Estatísticas do Jobscheduler) quanto por app (Estatísticas do app > Job programado). Verifique a contagem 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 mais longo.

Além disso, inspecione o gráfico do Battery Historian, analisando cada entrada 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 seu app, a duração da execução precisa fazer sentido.
  • Considere se os jobs acontecem enquanto o app está em execução ou se representam trabalho periódicos em segundo plano.

Sensores

Os dispositivos Wear OS têm muitos sensores diferentes, como o 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 maneira inteligente para melhorar o desempenho da bateria.

Para analisar o uso do sensor no app, execute o comando abaixo 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 lotes, se definido.
  • Dados de amostra recentes.

Testar o cancelamento do registro dos sensores

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

  1. Deslize para dispensar o app.
  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 Data Layer, cada transmissão usa um pouco de energia. Mais especialmente, se você usar essa API para enviar dados, seu app precisará ser ativado para recebê-los. Por esses motivos, seja conservador ao usar essa API.

Outras práticas recomendadas para usar a API Data Layer incluem o seguinte:

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

  • Transmitir 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 atualizam a interface. Por exemplo, se a tela de atividades mostrar apenas "quilômetros executados" até uma casa decimal, não envie uma mudança de estado para o Wear OS sempre que o usuário avançar mais um medidor para a frente.

Para analisar o uso da API Data Layer 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 consultar a 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.

Blocos e complicações

Se o app oferecer 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 o Firebase Cloud Messaging (FCM) ou jobs programados adequadamente para enviar atualizações de dados. Tome cuidado para evitar uma taxa de atualizações rápida, o que pode fazer com que o sistema programe um trabalho repetido em uma taxa mais rápida do que o usuário ou a plataforma consegue acessar os dados necessários para realizar esse trabalho.
  • Não programe o trabalho para o bloco ou a complicação quando o usuário não estiver interagindo com ele.
  • Use abordagens que priorizam o modo off-line.
  • Compartilhe um único banco de dados no seu app principal, blocos e complicações. Isso ajuda os dados a permanecerem consistentes em todas as plataformas da interface.