Monitorar a qualidade técnica do app com o Android vitals

Para mais detalhes sobre uma métrica, selecione Ver detalhes () ao lado dela. Na tela seguinte, você encontra estes dados:

• Limites de mau comportamento
• Comparativos de mercado por categoria
• Comparativos de mercado detalhados
  • Próximo à parte superior da página, no card de comparação, selecione Editar grupo de apps semelhantes para alterar um grupo personalizado. Depois de criar um grupo, você pode comparar o desempenho dos apps semelhantes do Google Play selecionados ao do seu.
• Tendência de métricas ao longo do tempo

As métricas de taxa de ANR mostram uma visão geral da qualidade do app. Elas são calculadas com a normalização do número de usuários com falhas com base no uso do app. Eles são contabilizados como uma porcentagem de usuários ativos por dia, que são definidos como usuários que usam o app em um único dia em um dispositivo. Se um usuário usar o app em mais de um dispositivo em um único dia, cada dispositivo vai contribuir para o número de usuários ativos nesse dia. Se vários usuários usarem o mesmo dispositivo em um único dia, isso vai ser contabilizado como um usuário ativo.

Há três métricas de taxa de ANR:

• Taxa de ANR percebido pelo usuário: é a porcentagem de usuários ativos por dia que perceberam pelo menos um ANR. Um ANR percebido pelo usuário é um ANR que provavelmente foi observado pelo usuário. Atualmente, somente os ANRs do tipo "tempo de entrega de entradas esgotado" são contabilizados. Essa métrica é sempre menor que a taxa de ANR geral, porque é normalizada pelo uso diário, mas não conta todos os ANRs.
  A taxa de ANR percebido pelo usuário é uma das principais métricas, ou seja, ela afeta a possibilidade de descoberta do app no Google Play. Ela é importante porque os ANRs que ela conta sempre ocorrem quando o usuário está usando o app, o que causa mais interrupções.
• Taxa de ANR: é a porcentagem de usuários diários que tiveram pelo menos um ANR. Essa métrica inclui ANRs que não são classificados como percebidos pelo usuário, mas não podemos garantir que eles não estejam afetando os usuários.
• Taxa de ANRs múltiplos: é a porcentagem de usuários diários que tiveram pelo menos dois ANRs. Essa métrica ajuda a destacar loops de problemas.

Corrigir um problema

Os ANRs que contribuem para as métricas de taxa de ANR são exibidos na página Falhas e ANRs. É possível filtrar por ANRs percebidos pelo usuário nesta página.

O site Desenvolvedores Android tem orientações sobre como diagnosticar e corrigir ANRs.

As métricas de taxa de falhas mostram uma visão geral da qualidade do app. Elas são calculadas com a normalização do número de usuários com falhas com base no uso do app. Eles são contabilizados como uma porcentagem de usuários por dia, que são definidos como usuários que usam o app em um único dia em um dispositivo. Se um usuário tem mais de um dispositivo, ele é contado mais de uma vez. Por exemplo, se dois usuários utilizarem o app por dois dias, cada um em um dispositivo, isso vai produzir quatro sessões diárias.

Há três métricas de taxa de falhas:

• Taxa de falhas percebidas pelo usuário: é a porcentagem de usuários diários que tiveram pelo menos uma falha percebida pelo usuário. Uma falha percebida pelo usuário é uma falha que provavelmente foi observada pelo usuário. Por exemplo, falhas que ocorrem quando o app está exibindo uma atividade ou sendo executado como um serviço em primeiro plano. Essa métrica é sempre menor que a taxa de falhas geral, porque é normalizada pelo uso diário, mas não conta todas as falhas.
  A taxa de falhas percebidas pelo usuário é uma das principais métricas, ou seja, ela afeta a possibilidade de descoberta do app no Google Play. Isso é importante porque as falhas contadas sempre ocorrem quando o usuário está engajado com o app, causando mais interrupções. Por isso seu app não pode ultrapassar o limite de mau comportamento dessa métrica.

• Taxa de falhas: é a porcentagem dos usuários diários que tiveram pelo menos uma falha. Essa métrica inclui falhas que não são classificadas como percebidas pelo usuário, mas não podemos garantir que elas não estejam afetando os usuários.

• Taxa de falhas múltiplas: é a porcentagem de usuários diários que tiveram pelo menos duas falhas. Essa métrica ajuda a destacar loops de problemas.

Corrigir um problema

O site para desenvolvedores Android oferece orientações sobre como diagnosticar e corrigir falhas.

Na página Tempo de inicialização, você vê detalhes sobre a inicialização lenta nos estados do sistema: a frio, com estado salvo e a quente. O tempo de inicialização é o período entre a inicialização do app e a exibição dos primeiros frames na tela. Também conhecido como "tempo para exibição inicial".

Talvez o app não esteja pronto para receber interações dos usuários após esse período, por exemplo, se ele tiver telas de carregamento adicionais.

Detalhes da coleta de dados

• Os tempos de inicialização são registrados somente quando um usuário aciona uma atividade.
  • Exemplo: para apps de teclado, o tempo de inicialização é igual ao tempo de inicialização do app complementar.
• Se um app é iniciado várias vezes no mesmo dia com o mesmo estado do sistema, o tempo máximo de inicialização do dia é registrado.
• Os tempos de inicialização são rastreados quando o primeiro quadro do app é carregado completamente, mesmo que não seja uma tela de interação com o usuário.
  • Exemplo: se um app iniciar com uma tela de apresentação, o tempo de inicialização será igual ao tempo necessário para exibir a tela de apresentação.

Detalhes importantes

• Sessões afetadas: é a porcentagem de sessões em que o tempo de inicialização foi lento para cada estado do sistema relacionado:
  • Inicialização a frio lenta: cinco segundos ou mais.
  • Inicialização com estado salvo lenta: dois segundos ou mais
  • Inicialização a quente lenta: um segundo ou mais
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o tempo de inicialização do app foi lento.

Corrigir um problema

Se o app tiver um número elevado de tempos de inicialização lentos, veja as soluções recomendadas no site para desenvolvedores Android.

Por que isso é importante

Com as sessões lentas, é possível entender o desempenho do frame rate do jogo, o que afeta a fluidez dele para os usuários.

Interpretar os dados do app

A página "Sessões lentas" mostra detalhes sobre a porcentagem de sessões diárias em que mais de 25% dos frames tiveram uma exibição mais lenta do que 30 ou 20 QPS, dependendo do comparativo que você selecionar. Você também pode acessar a distribuição de sessões por frame rate para o jogo. O frame rate no nível da sessão é medido no 75º percentil, ou seja, 75% dos frames têm esse valor pelo menos.

A maioria dos jogos no Google Play precisa ter 30 QPS ou mais. Isso oferece uma experiência razoável para os usuários em todos os tipos de jogos, embora alguns usuários prefiram pelo menos 60 QPS, especialmente em dispositivos mais avançados. Monitore a métrica de taxa de sessão lenta (30 QPS) para garantir que você esteja cumprindo os requisitos. Essa métrica inclui apenas sessões em que mais de 25% dos frames não chegam a 30 QPS. Por isso, ela tem tolerância à variabilidade de frame rate.

Embora 30 QPS ofereçam uma experiência razoável, pode haver momentos ou tipos de jogos em que faz sentido reduzir o frame rate. Além disso, talvez alguns usuários joguem em smartphones incompatíveis com 30 QPS. Nesses cenários, pelo menos 75% dos frames em uma sessão ainda precisam alcançar 20 QPS ou mais. Monitore a métrica de taxa de sessão lenta (20 QPS) para garantir que você esteja cumprindo os requisitos.

O Android vitals inclui métricas de sessões lentas a 30 e a 20 QPS para cada dispositivo, assim como em todos os dispositivos e sessões. Use a métrica geral para entender a experiência geral do usuário, mas preste atenção também no desempenho por dispositivo. No futuro, o Google Play vai direcionar os usuários a outras opções quando os jogos não alcançam 20 QPS no smartphone.

O Android vitals só começa a monitorar o frame rate depois de o jogo rodar por 1 minuto.

Detalhes da coleta de dados

A métrica de sessões lentas é calculada com os dados coletados pelo SurfaceFlinger. De maneira mais concreta, o frame rate de uma sessão é estimado com base no tempo entre os frames renderizados em plataformas do app e inclui frames renderizados pelo OpenGL, pelo Vulkan e pelo kit de ferramentas de interface do Android. No momento, essa métrica está disponível somente para jogos.

Os dados de frame rate para sessões lentas são coletados de dispositivos com Android 9 ou versões mais recentes.

Painel de exibição

• Frame rate representativo: é o desempenho de frame rate do jogo em dispositivos com o Android 9 ou versões mais recentes, calculado no 75º percentil. Isso significa que 75% das sessões tiveram frame rate igual ou superior a esse 75% das vezes.
• Taxa de sessão lenta ao longo do tempo: é uma série temporal que mostra a porcentagem de sessões consideradas lentas.
• Distribuição de frame rate: é o histograma que mostra o 75º percentil do frame rate em todas as sessões. Isso significa que 75% dos frames em uma sessão foram mais rápidos do que o frame rate usado para agrupar a sessão.

Corrigir um problema

Se o app tiver um número elevado de sessões lentas, veja as soluções recomendadas no site para desenvolvedores Android.

Interpretar os dados do app

Na página "Excesso de frames lentos", você encontra detalhes sobre a porcentagem de sessões diárias em que mais de 50% de frames não atingiram o tempo de renderização do dispositivo. As interações do usuário com o app precisam ser executadas a 60 quadros por segundo sem frames perdidos ou atrasados.

Detalhes da coleta de dados

O Google registra o tempo de renderização de cada frame renderizado pelo app ao usar o framework do kit de ferramentas de IU. Os frames renderizados usando o OpenGL ou o Vulkan diretamente não são registrados.

Painel de exibição

Quando você selecionar uma linha, verá os dados divididos em percentuais.

• Sessões afetadas: é a porcentagem de sessões diárias em que mais de 50% dos frames tiveram um tempo de renderização maior que 16 ms. Uma sessão diária é um dia em que o app foi usado. Por exemplo, se dois usuários utilizarem o app por dois dias, serão quatro sessões diárias.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: 90%/99% do total de frames teve um tempo de renderização menor do que o número mostrado. Esses números são baseados em todos os frames coletados.

Ao clicar em uma entrada na tabela, você vê o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, confira se a maioria dos frames do app tem um tempo de renderização de até 16 ms.

Os dados abaixo do gráfico transmitem o desempenho de renderização do app e podem ajudar você a encontrar a causa raiz de algum problema com o tempo de renderização. Por exemplo, se a porcentagem de "Latência de entrada alta" for alta, confira o código do app que processa a entrada do usuário. Para mais informações sobre essas métricas, acesse testar o desempenho da IU.

• Vsyncs perdidos: para todos os frames renderizados em mais de 16 ms, é o número de eventos Vsync perdidos dividido pela quantidade de frames.
• Latência de entrada alta: para todos os frames renderizados em mais de 16 ms, é o número de eventos de entrada que levaram mais de 24 ms dividido pela quantidade de frames.
• Linha de execução de interface lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de interface levou mais de 8 ms para ser concluída dividido pela quantidade de frames.
• Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o envio de comandos de desenho à GPU levou mais de 12 ms dividido pela quantidade de frames.
• Uploads de bitmap lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o bitmap levou mais de 3,2 ms para fazer upload para a GPU dividido pela quantidade de frames.

Corrigir um problema

Se o app tiver um número elevado de frames com tempo de renderização acima de 16 ms, confira as soluções recomendadas no site para Desenvolvedores Android.

Interpretar os dados do app

Na página "Excesso de frames lentos", você encontra detalhes sobre a porcentagem de sessões diárias em que mais de 50% de frames não atingiram o tempo de renderização do dispositivo. As interações do usuário com o app precisam ser executadas a 60 quadros por segundo sem frames perdidos ou atrasados.

Detalhes da coleta de dados

O Google registra o tempo de renderização de cada frame renderizado pelo app ao usar o framework do kit de ferramentas de IU. Os frames renderizados usando o OpenGL ou o Vulkan diretamente não são registrados.

Painel de exibição

Quando você selecionar uma linha, verá os dados divididos em percentuais.

• Sessões afetadas: é a porcentagem de sessões diárias em que mais de 50% dos frames tiveram um tempo de renderização maior que 16 ms. Uma sessão diária é um dia em que o app foi usado. Por exemplo, se dois usuários utilizarem o app por dois dias, serão quatro sessões diárias.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: 90%/99% do total de frames teve um tempo de renderização menor do que o número mostrado. Esses números são baseados em todos os frames coletados.

Ao clicar em uma entrada na tabela, você vê o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, confira se a maioria dos frames do app tem um tempo de renderização de até 16 ms.

Os dados abaixo do gráfico transmitem o desempenho de renderização do app e podem ajudar você a encontrar a causa raiz de algum problema com o tempo de renderização. Por exemplo, se a porcentagem de "Latência de entrada alta" for alta, confira o código do app que processa a entrada do usuário. Para mais informações sobre essas métricas, acesse testar o desempenho da IU.

• Vsyncs perdidos: para todos os frames renderizados em mais de 16 ms, é o número de eventos Vsync perdidos dividido pela quantidade de frames.
• Latência de entrada alta: para todos os frames renderizados em mais de 16 ms, é o número de eventos de entrada que levaram mais de 24 ms dividido pela quantidade de frames.
• Linha de execução de interface lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de interface levou mais de 8 ms para ser concluída dividido pela quantidade de frames.
• Comandos de desenho lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o envio de comandos de desenho à GPU levou mais de 12 ms dividido pela quantidade de frames.
• Uploads de bitmap lentos: para todos os frames renderizados em mais de 16 ms, é o número de vezes que o bitmap levou mais de 3,2 ms para fazer upload para a GPU dividido pela quantidade de frames.

Corrigir um problema

Se o app tiver um número elevado de frames com tempo de renderização acima de 16 ms, confira as soluções recomendadas no site para Desenvolvedores Android.

As páginas Wake locks parciais travados e Wake locks parciais travados (segundo plano) mostram wake locks parciais obtidos pelo app com a classe "PowerManager". Um wake lock parcial garante que a CPU esteja funcionando, mas que a luz de fundo do teclado e da tela possa ser desativada.

Detalhes da coleta de dados

• Para fins de privacidade, as tags de identificação dos wake locks parciais são mantidas anônimas.
• Os dados sobre wake locks parciais são coletados quando o dispositivo não está sendo carregado e a tela está desligada.
• Os dados sobre wake locks parciais travados (segundo plano) só são coletados quando o app está em funcionando em segundo plano.
• O Google calcula o tempo máximo do wake lock parcial por sessão de duração da bateria para mostrar quantas sessões são afetadas por um wake lock longo. Por exemplo, se um usuário acionar wake locks de duas horas, o Google vai usar um valor máximo de uma hora de wake lock.
• No caso de apps que definem o sharedUserId no arquivo de manifesto, os dados só vão estar disponíveis se no máximo um app com o mesmo sharedUserId estiver instalado.

Detalhes importantes

• Sessões afetadas: porcentagem de sessões diárias em que houve pelo menos um wake lock de mais de uma hora.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que os usuários foram afetados por wake locks parciais com duração maior do que o número exibido.
• Limite de mau comportamento: se o app tem uma taxa de ocorrência igual ou superior ao limite mostrado, ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações).

Corrigir um problema

Se o app tiver um número alto de wake locks parciais travados, acesse o site para desenvolvedores Android e veja as soluções recomendadas.

A página Ativações excessivas mostra as ativações do Alarm Manager acionadas pelo app. Você vai ver os dados de ativação das classes ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.

Detalhes da coleta de dados

• Para fins de privacidade, as tags de identificação das ativações são mantidas anônimas.
• As ativações são coletadas quando o dispositivo não está carregando.
• Para mostrar uma métrica normalizada, o número de ativações é comparado ao tempo de uso da bateria. O Google calcula o número de ativações por usuário a cada hora para mostrar quantas pessoas são afetadas por uma alta taxa de ativações.
• No caso de apps que definem o sharedUserId no arquivo de manifesto, os dados só vão estar disponíveis se no máximo um app com o mesmo sharedUserId estiver instalado.

Detalhes importantes

• Sessões afetadas: é a porcentagem de durações da bateria em que houve mais de 10 ativações por hora. A duração da bateria é a agregação de todos os relatórios de bateria recebidos em um determinado período de 24 horas. No Android 10, um relatório de bateria cobre o intervalo entre duas cargas de menos de 20% a mais de 80% ou de qualquer valor a 100%. No Android 11 e versões mais recentes, um relatório de bateria se refere a um período fixo de 24 horas. O Google coleta os dados somente quando o dispositivo não está sendo carregado.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o número de ativações por hora foi maior que o valor exibido.
• Limite de mau comportamento: se o app tem uma taxa de ocorrência igual ou superior ao limite mostrado, ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações).

Corrigir um problema

Se o app tiver ativações frequentes, veja as soluções recomendadas no site para desenvolvedores Android.

A página Excesso de verificações de Wi-Fi (segundo plano) mostra quando as verificações de Wi-Fi exigem um uso elevado da bateria.

Detalhes da coleta de dados

Os dados sobre a verificação de Wi-Fi são coletados quando o dispositivo não está carregando e o app está em segundo plano.

Detalhes importantes

• Sessões afetadas: é a porcentagem de durações da bateria em que houve mais de quatro buscas por Wi-Fi por hora.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o número de buscas por Wi-Fi em segundo plano por hora foi maior que o valor exibido.

Corrigir um problema

Caso seu app apresente um número alto de verificações de Wi-Fi em segundo plano, confira as soluções recomendadas no site para desenvolvedores Android.

A página Uso excessivo da rede mostra quando uma grande quantidade de dados de rede está associada a um serviço em segundo plano. Por causa do uso da rede móvel em segundo plano, os usuários não têm fácil acesso aos controles para interromper a transferência de dados.

Detalhes da coleta de dados

Os dados sobre o uso da rede móvel são coletados quando o dispositivo não está carregando e o app está em segundo plano.

Detalhes importantes

• Sessões afetadas: é a porcentagem de durações da bateria em que o uso diário de rede em segundo plano foi maior que 50 MB.
• Número de sessões: número aproximado de sessões gravadas.
• 90º/99º percentil: corresponde a 10%/1% das sessões diárias em que o uso diário de rede em segundo plano foi maior do que o número exibido.

Corrigir um problema

Caso o app tenha um uso elevado de rede em segundo plano, veja as soluções recomendadas no site para desenvolvedores Android.

Na página Permissões negadas, você pode conferir detalhes sobre a porcentagem de sessões de permissão diárias em que os usuários negaram permissões. Uma sessão de permissão diária é um dia em que o app solicitou pelo menos uma permissão do usuário.

Detalhes da coleta de dados

Os dados sobre permissões negadas são coletados quando os usuários respondem a solicitações de permissões no seu app.

Detalhes importantes

• Negações: porcentagem de sessões diárias de permissão em que os usuários negaram permissões.
• Não perguntar novamente: é a porcentagem de sessões de permissão diárias em que as permissões foram negadas pelos usuários ao selecionarem a opção "Não perguntar novamente".
• Total de sessões: é o número aproximado de sessões registradas.

Corrigir um problema

Se o app tiver um número elevado de permissões negadas, veja as soluções recomendadas no site para desenvolvedores Android.

O Google Play definiu limites de mau comportamento na taxa de ANR percebido pelo usuário:

• Mau comportamento geral: pelo menos 0,47% dos usuários ativos por dia percebem um ANR em todos os modelos de dispositivos.

• Mau comportamento por dispositivo: pelo menos 8% dos usuários ativos por dia percebem um ANR em um único modelo de dispositivo.

Para melhorar a taxa de ANR, corrija os clusters de ANR indicados na página Falhas e ANRs. Quanto maior o número de usuários afetados, maior é a contribuição do cluster à taxa de ANR.

Se aspectos específicos do hardware ou software do dispositivo contribuírem para a taxa de ANR, o Android vitals vai notificar você. Você também pode ver associações por conta própria na página Visão geral de alcance e dispositivos (Lançamento >Alcance e dispositivos >Visão geral).

O Google Play definiu limites de mau comportamento na taxa de falhas percebidas pelo usuário:

• Mau comportamento geral: pelo menos 1,09% dos usuários ativos por dia percebem uma falha em todos os modelos de dispositivos.

• Mau comportamento por dispositivo: pelo menos 8% dos usuários ativos por dia percebem uma falha em um único modelo de dispositivo.

Para melhorar a taxa de falhas, corrija os clusters de falhas subjacentes indicadas na página Falhas e ANRs. Quanto maior o número de usuários afetados, maior é a contribuição do cluster à taxa de falhas.

Se aspectos específicos do hardware ou software do dispositivo contribuírem para a taxa de falhas, o Android vitals vai notificar você. Você também pode conferir associações por conta própria na página Visão geral de alcance e dispositivos (Lançamento > Alcance e dispositivos > Visão geral).