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. O 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 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 do 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, 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 especialmente a tarefas com uso intenso 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 pré-buscar dados, imagens e atualizações que o usuário provavelmente quer ver no app.

Este guia sobre energia ajuda 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 algumas 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 da bateria de um dispositivo Wear OS que executa seu app, digite 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 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, 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 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 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. Proporcione uma experiência que use o modo sempre ativado, também conhecido como modo ambiente.
Acessar o sensor de GPS Alto Se possível, aguarde até que o usuário solicite o acesso ao GPS.
Manter alto o uso da CPU 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.
Ativar um wake lock Mídia Reduza a criação manual de wake locks e use WorkManager.

Diminua o tempo de tela ligada

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

  • Bloqueios de tela:evite sempre que possível. Para testar, desative a opção Tela sempre ativada nas configurações do sistema e observe se a tela apagará dentro do tempo limite.
  • Animações:minimize animações elaboradas e concentre-se em transições breves para ter uma aparência mais profissional. Especificamente, evite animações e loops de longa duração. Se uma repetição for necessária, adicione uma pausa entre ela que seja pelo menos tão longa quanto a própria animação.

  • Tempo acordado no modo ambiente:ofereça suporte à opção "Sempre ativado", se necessário, por exemplo, para casos de uso fitness. Se o app precisar ficar sempre ativado, 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 de 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 de inatividade do processo do app.

Minimizar wakelocks

Na maioria dos casos, evite qualquer operação que impeça 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 wakelock, 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 durante a execução do job em segundo plano.

O Battery Historian permite que você veja ocorrências individuais de wakelocks longos, além de resumos do número total e da duração dos wakelocks mantidos. Inspecione o número e a duração dos wake locks mantidos pelo app 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 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 de tecla no dispositivo, como este:

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

  • O app será deslizado 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 ao selecionar View > Tool Windows > Profiler:

  1. Inspecione o rastro do sistema conforme a tela é desligada e o dispositivo entra no modo ambiente.
  2. Procure trabalhos continuados 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 significativos do seu 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, é possível 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 programadas com o WorkManager permitem que você execute 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 muito tempo, porque isso pode consumir 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 > Jobs programados). Verifique 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 total de execução corresponde ao esperado e não é significativamente maior.

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 ocorrem enquanto o app está em execução ou se eles representam trabalhos periódicos 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 o 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 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 agrupamento, se definido.
  • Dados amostrados recentemente.

Testar o cancelamento do registro dos sensores

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

  1. Deslize e dispense 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 é exibido corretamente como não registrado.

Camada de dados

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

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

  • Aguarde até que o 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 atividade mostrar apenas "quilômetros percorridos" até uma casa decimal, não envie uma mudança de estado para o Wear OS sempre que o usuário mover outro medidor para frente.

Para analisar o uso da API Data Layer no seu 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 adequadamente para enviar atualizações de dados. Tome cuidado para evitar uma taxa rápida de atualizações, o que pode fazer com que o sistema programe um trabalho repetido mais rapidamente do que o usuário ou a plataforma pode acessar os dados necessários para realizar esse trabalho.
  • Não programe trabalhos 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 entre seu app principal, blocos e complicações. Isso ajuda a manter os dados consistentes em todas as plataformas da interface.