Economizar energia e bateria

A eficiência energética é especialmente importante no Wear OS. O design do Wear OS princípios de IA focam 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. Por isso, qualquer consumo de bateria é mais perceptível. Além disso, exige mais esforço do usuário para carregar um dispositivo Wear OS em comparação com um dispositivo móvel. Embora os usuários possam cobrar seus 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. Ela não devem copiar diretamente seu aplicativo 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 relógio são caras; considere se o dispositivo móvel pode fazer o trabalho pesado, e o dispositivo Wear OS recebe ou 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 antes que ocorram mudanças.

  • 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 organizar bancos de dados.

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

Este guia de energia ajuda 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 alcançadas, como carregar um aplicativo ou percorrer um lista, acesse orientações relacionadas à performance, como o Compose no Wear OS guia de desempenho.

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, insira o a seguir 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 executar 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. sobre os eventos que consomem energia em um dispositivo Wear OS.

A tabela a seguir 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 Alta Não incentive o usuário a manter a tela ligada por mais tempo necessários. Proporcione uma experiência que use sempre ativado padrão, 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 Consumo de fluxos usando o Jetpack Compose.
Acessar o sensor de frequência cardíaca Médio Usar o tempo de ativação do processador quando recebimento de callbacks da API do sensor, como ao usar Recursos de saúde ativados Wear OS.
Acessar outro dispositivo por Bluetooth Médio Mantenha as sessões curtas.
Ativar um wake lock Médio Reduzir a criação e o uso manuais de wakelocks 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 Sempre ativado é mostrado nas configurações do sistema e observe se a tela desliga dentro o tempo limite.
  • Animações:minimize animações elaboradas e concentre-se no resumo. e transições para passar uma imagem mais profissional. Em especial, evite usar animações e repetições. Se uma repetição for necessária, adicione uma pausa entre as repetições que seja pelo menos tão longa quanto a própria animação.

  • Tempo acordado no modo ambiente:ofereça suporte à configuração "Sempre ativado", se necessário, por exemplo, de exercícios físicos. Caso seu app precise estar sempre ligado, verifique se ele 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 uma onAmbientUpdate().

Minimizar o uso de CPU

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

  • Seja breve.
  • Agrupar todas as operações relacionadas para maximizar o tempo de processamento do app está inativo.

Minimizar wakelocks

Na maioria dos casos, evite quaisquer operações que impeçam o aplicativo de entrar em suspensão, como como wakelocks. Por exemplo, nas áreas de saúde e apps fitness, treinos de longa duração não é necessário um wake lock. Usar 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 seu app realiza uma das seguintes ações:

  • Reproduz mídia em segundo plano.
  • Usa WorkManager ou JobScheduler. (O sistema mantém wake lock em seu nome ao executar o job em segundo plano.)

O Battery Historian permite que você veja ocorrências individuais de durações longas wakelocks, bem como resumos do número total e da duração dos wakelocks que serão realizadas. Inspecionar o número e a duração dos wake locks que o app possui e compara essas informações com os padrões de uso interativo dos seus aplicativo:

  • Verifique se há wake locks inesperados.
  • Se a duração for maior que o esperado, considere se o trabalho é bloqueados em algumas dependências, como a disponibilidade da rede.

Inspecionar como o app fica inativo

Considere o que o app ativo faz quando ocorrem eventos principais no dispositivo, como o seguinte:

  • 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 Visualizar > Janelas de ferramentas > Criador de perfil:

  1. Inspecionar o rastro do sistema conforme a tela é desligada e o dispositivo entra ambiente integrado.
  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 ver se há se há linhas de execução que funcionam quando a tela desliga, o dispositivo entre no modo ambiente ou o usuário dispense a atividade do app.

Defina eventos personalizados para marcar eventos importantes do seu app, incluindo: eventos específicos do domínio. Para um app de música, isso incluiria tarefas como buscar listas de reprodução, fazer o download de um item de mídia específico, iniciar e interromper a reprodução a reprodução. Ao definir esses eventos, eles podem ser consultados no Perfetto e comparados o tempo de uso da CPU e do uso de energia do app.

Analisar os jobs programados do app

Jobs programados, usando o WorkManager, permitem que você execute trabalhos em segundo plano nos seus app. Embora alguns trabalhos em segundo plano devam ser periódicos, não execute jobs também com frequência ou por muito tempo, porque isso pode descarregar a bateria do dispositivo.

Use o Battery Historian para inspecionar a execução de tarefas programadas, ambas geral (Estatísticas do sistema > Estatísticas do Jobscheduler) e por app (Estatísticas do app > Job agendado). 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 corresponde ao significativamente mais longa.

Além disso, inspecione o gráfico do Battery Historian, analisando cada JobScheduler. entrada. 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 o jobs representam trabalhos periódicos em segundo plano.

Sensores

Os dispositivos Wear OS têm muitos sensores diferentes, como GPS. Na maioria dos casos, use 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 o desempenho da bateria.

Para analisar o uso do sensor no app, execute o comando a seguir em um 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 verificar se o app para de buscar dados do sensor como esperado, teste o cenários a seguir:

  1. Deslize e dispense o app.
  2. Toque na tela com a palma da mão. Isso desliga a tela ou coloca a tela 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

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

Algumas práticas recomendadas adicionais para o uso da API Data Layer incluem as 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. Esses estados mudanças permitem que o dispositivo Wear OS faça cálculos de dados locais, como quando começou uma sessão de treino.

    Transmita apenas mudanças de estado que atualizam a interface. Por exemplo, se sua a tela de atividade mostra 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 move outro medidor. para a frente.

Para analisar o uso da API Data Layer no seu app, execute o seguinte comando em um 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 chamadas usando MessageClient.
  • DataService: permite ver com que frequência os itens de dados são 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 otimizá-lo. o uso de sensores pelo app.

Blocos e complicações

Caso seu app seja compatível com um bloco ou uma complicação, siga estas recomendações práticas recomendadas:

  • Desative a atualização automática, ou aumente a taxa de atualização para duas horas ou mais longas.
  • Use o Firebase Cloud Messaging (FCM) ou adequadamente programado jobs 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 trabalhos repetidos mais rapidamente o usuário ou a plataforma possam acessar os dados necessários para realizar esse trabalho.
  • Não programar o trabalho do bloco ou da complicação quando o usuário não estiver interagir 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 de interface.