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

  • Teste
  • Desenvolvimento
  • Análise

O desempenho e a estabilidade estão diretamente relacionados a avaliações positivas no Google Play. Corrigir problemas e evitar maus comportamentos pode melhorar a experiência do usuário, gerar classificações mais altas e aumentar o número de instalações retidas. Além disso, reduzir o tamanho do app pode melhorar as taxas de instalação e reduzir as desinstalações.

Por que isso funciona

O "Android vitals" mostra as métricas de desempenho do app 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 mudança repentina nas principais métricas que indicam anomalias a serem investigadas, bem como comparativos de mercado para ajudar na comparação de desempenho com apps similares de sua escolha. Os apps com métricas mais altas têm maior potencial de promoção, o que melhora a classificação deles nas pesquisas da Google Play Store. As chances de eles se qualificarem para as coleções "Novos e Atualizados" e "Escolha do editor" 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 impasses ou lentidão nos processos de linha de execução 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 sessões diárias em que os usuários experimentaram mais de 50% de frames com um tempo de renderização maior que 16 ms. As interações do usuário com o app precisam ser executadas em 60 quadros por segundo sem frames perdidos ou atrasados.
  • 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 inativo 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 inativo seja suspenso.
  • Tempo de inicialização: é a porcentagem de sessões em que 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 em que 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 por que uma permissão está sendo solicitada ou consideram a solicitação desnecessária ou excessiva.
  • Tamanho do app: acompanhe o download e o tamanho no dispositivo do seu aplicativo e compare essas métricas com as de seus colegas. Além disso, veja métricas de usuários ativos e de desinstalações para dispositivos com pouco espaço de armazenamento. Receba sugestões de otimização sobre como reduzir o tamanho do app com base em uma análise dos seus lançamentos.

Práticas recomendadas

  • Pense em maus comportamentos e os erradique: durante o desenvolvimento do app, pense em como ele se comportaria em diferentes ambientes. Por exemplo, se você estiver testando o app 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 testar o app em um conjunto maior de dispositivos antes de cada lançamento.
  • Verifique o Android vitals depois de lançar uma nova versão do app: depois que você publicar o app, o recurso fornecerá métricas sobre o desempenho dele nos dispositivos de produção no mundo real. Isso permite identificar problemas e maus comportamentos que afetam os usuários em dispositivos e versões do Android específicos.
  • Identifique dispositivos com problemas: o app pode apresentar maus comportamentos somente em um dispositivo ou conjunto específico. 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 maus comportamentos somente em versões específicas do Android. Para versões mais antigas do Android que representam um número pequeno de usuários, atualize seu app para eliminar o mau comportamento ou atualize o atributo android:minSdkVersion do elemento <uses-sdk> no manifesto para um nível de API em que o app não exiba esses comportamentos. Para novas versões do Android, sempre atualize o app para corrigir os maus comportamentos em vez de configurar o atributo android:maxSdkVersion do elemento <uses-sdk> para excluí-los.
  • Use as ferramentas de relatório de erros para identificar e rastrear falhas e ANRs: use ferramentas de relatórios de erros, como o Firebase Crash Reporting ou o Crashlytics, e a depuração do Android Studio para identificar e rastrear o máximo de cenários possíveis que levam falhas e ANRs.
  • Use as APIs JobScheduling para evitar wake locks e ativações: use as APIs JobScheduling, como JobScheduler, para agendar de maneira inteligente processos e tarefas em segundo plano. Isso permite que a plataforma gerencie melhor o estado inativo e economize 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 imediatamente. Ajude os usuários a desfazer as recusas de permissão e verifique se as configurações corretas estão habilitadas para o aplicativo funcionar.
  • Use os relatórios de pré-lançamento para testar o app em dispositivos reais e identificar e corrigir problemas antes de publicar a atualização.
  • Use os Android App Bundles para aproveitar uma maneira mais eficiente de criar e disponibilizar seu app, oferecendo redução de tamanho sem precisar refatorar o código.

Exemplos