Usar o Android vitals para melhorar o desempenho e a estabilidade do app

  • Teste
  • Desenvolvimento
  • Análise

O desempenho e a estabilidade estão diretamente associados com boas avaliações no Google Play. A correção dos problemas e a prevenção de maus comportamentos pode melhorar a experiência do usuário, gerar classificações mais altas e ampliar o número de instalações retidas.

Por que isso funciona

O Android vitals inclui métricas de desempenho de apps relacionadas a estabilidade, energia, atraso, tempos de inicialização e recusas de permissão. O acompanhamento dessas métricas permite identificar e corrigir comportamentos inadequados de apps que afetam diretamente a experiência do usuário. Você também verá quando houver uma alteração repentina nas principais métricas que indiquem anomalias a ser investigadas, bem como comparativos de mercado, para que você possa avaliar o desempenho do seu app em relação a outros semelhantes. Os apps cujas métricas são mais altas têm maior potencial para promoção, o que melhora a classificação nas pesquisas da Google Play Store. As chances de eles se qualificarem para as coleções Novos e Atualizados e Escolhas dos editores no Google Play e serem indicados para o Google Play Awards também aumentam.

Principais métricas

  • Estabilidade | Taxa de ANR: é a porcentagem de usuários que tiveram pelo menos um evento "o app não está respondendo" (ANR) durante uma sessão diária. Geralmente, os ANRs são causados por deadlocks ou lentidão nos processos de thread de IU e segundo plano (broadcast receivers).
  • Estabilidade | Taxa de falhas: é a porcentagem de usuários que tiveram pelo menos um evento de falha durante uma sessão diária. Geralmente, as falhas são causadas por exceções não tratadas, esgotamento de recursos, declarações com falha ou outros estados inesperados.
  • Tempo de renderização | 16 ms (60 fps): é a porcentagem de usuários que tiveram mais de 15% de frames com um tempo de renderização maior que 16 ms em um dia. Os apps que demoram muito para renderizar cada frame antes de ele ser desenhado começarão a travar. É improvável que aumentos ocasionais e pequenos no tempo de renderização sejam notados, mas os tempos de renderização de 150 ms causam uma intermitência perceptível.
  • Tempo de renderização | 700 ms: é a porcentagem de usuários que tiveram mais de 1 em 1.000 frames com um tempo de renderização maior que 700 ms por dia. Como acima, tempos de renderização longos prejudicam a experiência do usuário, fazendo com que seu app pareça menos uniforme. Os frames que levam 700 ms ou mais para renderizar podem fazer com que o app pareça congelado para o usuário.
  • Bateria | Wake locks parciais: é a porcentagem de usuários que tiveram ao menos um wake lock de mais de uma hora em qualquer dia específico. Wake locks parciais travados impedem que um dispositivo ocioso entre em modo de suspensão e economize bateria.
  • Bateria | Ativações: é a porcentagem de usuários que tiveram mais de 60 ativações por hora desde que o dispositivo foi totalmente carregado. Ativações frequentes causadas por alarmes que executam operações baseadas em tempo fora do ciclo de vida do app impedirão que um dispositivo ocioso seja suspenso.
  • Tempo de inicialização: é a porcentagem de sessões durante as quais os usuários passaram por um período de inicialização lento a frio ou a quente. Inicializações lentas podem ser causadas por vários problemas, mas geralmente indicam a execução de cargas de trabalho pesadas ou lógica complexa ao inicializar o app.
  • Recusas de permissão: é a porcentagem de sessões diárias de permissão durante as quais os usuários recusam permissões ou selecionam Não perguntar novamente. As recusas de permissão podem indicar que as pessoas não entendem porque uma permissão está sendo solicitada ou consideram a solicitação desnecessária ou excessiva.

Práticas recomendadas

  • Pense em comportamentos ruins e os erradique: durante o desenvolvimento do app, pense em como ele se comportaria em diferentes ambientes. Por exemplo, se você estiver desenvolvendo um app e testando seu desempenho em um dispositivo completo e de última geração, pense em como ele funcionaria em um dispositivo de baixo custo com capacidade limitada de energia, memória, largura de banda e CPU/GPU. Use os relatórios de pré-lançamento para ampliar o conjunto de dispositivos em que o app é testado antes de cada lançamento.
  • Verifique o Android vitals depois de lançar uma nova versão do app: depois de publicar o app, o Android vitals fornecerá métricas sobre o desempenho dos seus dispositivos de produção no mundo real. Isso permite identificar problemas e comportamentos ruins que afetam os usuários em dispositivos específicos e nas versões do Android.
  • Identifique dispositivos com problemas: o app pode apresentar comportamentos ruins somente em um dispositivo específico ou em um conjunto de dispositivos. Dependendo da gravidade do impacto na experiência do usuário e do número de dispositivos e usuários afetados, é possível optar por atualizar a segmentação por dispositivo do app para excluir esses dispositivos até que uma correção seja disponibilizada.
  • Identifique o problema nas versões do Android: o app pode apresentar comportamentos inadequados somente em versões específicas do Android. Para versões mais antigas do Android que representam um pequeno número de usuários, atualize o app para eliminar o mau comportamento ou atualize o atributo android:minSdkVersion do elemento <uses-sdk> no manifesto do app para um nível de API em que seu aplicativo não apresente quaisquer comportamentos ruins. Para novas versões do Android, sempre atualize o app para corrigir os comportamentos inadequados em vez de configurar o atributo android:maxSdkVersion do elemento <uses-sdk> para excluir versões mais novas do Android.
  • Use as ferramentas de relatório de erros para identificar e rastrear falhas e ANRs: use ferramentas de relatório de erros, como o Firebase Crash Reporting ou Crashlytics, e a depuração do Android Studio para identificar e rastrear o máximo de cenários possíveis que levam a falhas e ANRs.
  • Use as JobScheduling APIs para evitar wake locks e ativações: use as JobScheduling APIs, como JobScheduler, para agendar de maneira inteligente processos e tarefas em segundo plano. Isso permite que a plataforma gerencie melhor o estado ocioso para economizar bateria.
  • Use as APIs FrameMetrics para identificar tempos de renderização lentos: use o FrameMetrics para avaliar tempos de renderização com granularidade alta e frame por interação para dispositivos em produção. Isso permite identificar interações ou eventos específicos que estão causando problemas em dispositivos de produção, em vez de confiar em dispositivos de teste conectados via USB.
  • Siga as práticas recomendadas para solicitações de permissão: oriente o usuário antes de solicitar uma permissão e garanta que os usuários se beneficiem da permissão imediata. Em seguida, ajude os usuários a desfazer as recusas de permissão. Além disso, certifique-se de que os usuários tenham as configurações certas ativadas para o app funcionar e, quando precisar da localização, crie uma solicitação de configuração de localização para garantir que as configurações apropriadas do dispositivo estejam ativadas.
  • Use os relatórios de pré-lançamento para testar o app em dispositivos reais e identificar e corrigir problemas antes de publicar sua atualização.

Exemplos