Monitorar o desempenho técnico do app com o Android vitals

Com o Play Console, é possível ver dados que ajudam você a entender e melhorar a estabilidade, o tempo de renderização e o uso da bateria do app.

Os dados a seguir foram coletados de usuários que ativaram o compartilhamento automático de dados de uso e diagnóstico de um subconjunto de dispositivos Android e versões de SO. Para mais informações sobre como os usuários do Android ativam o compartilhamento de dados, acesse a Central de Ajuda de Contas.

Recolher tudo Expandir tudo

Tipos de dados 

Uso da bateria
  • Ativações excessivas
  • Wake locks parciais travados
  • Wake locks parciais travados (em segundo plano)
  • Buscas excessivas por Wi-Fi em segundo plano 
  • Uso excessivo da rede em segundo plano
Estabilidade
  • Taxa de ANR
  • Taxa de múltiplos ANRs
  • Taxa de falhas
  • Taxa de múltiplas falhas
Tempo de inicialização do app
  • Inicialização a frio lenta
  • Inicialização morna lenta
  • Inicialização a quente lenta
Tempo de renderização
  • Frames excessivamente lentos
  • Frames excessivamente congelados
Permissões
  • Permissões negadas

Encontrar e analisar os dados do app

O período listado na página Android vitals inclui todos os dados disponíveis para seu app e não pode ser personalizado. Os dados do Android vitals têm como base o horário do Pacífico (PT, na sigla em inglês).

Importante: se não houver dados disponíveis, o app não tem pontos de dados suficientes nos filtros especificados para identificar problemas. 

Para encontrar e analisar dados do app no Android vitals, siga estas etapas:

  1. Abra o Play Console.
  2. Selecione um app.
  3. No menu à esquerda, selecione Qualidade > Android vitals > Visão geral.
  4. Escolha como você quer visualizar os dados do app.
Analise o painel Visão geral e as páginas de métricas detalhadas.

Principais métricas

Na parte superior da página Visão geral, você verá dados sobre as principais métricas do app. Elas detalham o desempenho e podem afetar a visibilidade e a classificação do app no Google Play. Veja algumas das principais métricas:

  • Taxa de ANR
  • Taxa de falhas
  • Wake locks parciais travados (em segundo plano)
  • Ativações excessivas

Se o app tiver algum problema crítico de desempenho que exija atenção, incluindo métricas acima dos limites de mau comportamento e alterações importantes nos dados de desempenho (conhecidas como anomalias), use essa página para identificar rapidamente as áreas que podem melhorar. Para receber notificações por e-mail quando forem detectadas alterações significativas nas métricas de ANR, cluster de falhas ou Android vitals, acesse Configuração > Notificações.

Importante: todos os apps precisam identificar e corrigir problemas para permanecer abaixo dos limites de mau comportamento e proporcionar a melhor experiência do usuário.

Procurar por todas as métricas

No meio da página Visão geral, você pode ver informações de todas as métricas por tipo de dados. Para filtrar a tabela, escolha as dimensões e o período desejados.

Para cada métrica, é possível analisar a porcentagem de sessões do app afetadas nos períodos atual e anterior. Para comparar o desempenho do seu app com o de outros no Google Play, veja também a diferença em relação à média de apps semelhantes.

Ver métricas detalhadas

Para mais detalhes sobre uma métrica, selecione Ver detalhes. Na tela seguinte, você poderá ver estes dados:

  • Anomalias encontradas nos dados de desempenho
  • 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 esse grupo, você pode comparar seu desempenho com o de outros apps do Google Play selecionados.
  • Métricas por artefato, dispositivo, versão do Android, comparativo de mercado ou período
    • Para ver mais detalhes, é possível expandir cada linha das tabelas selecionando a seta para baixo no lado direito.
Filtrar por maus comportamentos

Na parte superior da página Visão geral, é possível que algumas métricas estejam sinalizadas com um ícone vermelho de erro . Isso significa que o número exibido está alto em comparação com outros apps, ou seja, um mau comportamento.

Selecione Ver detalhes no card com o ícone para ver quais APKs do app são afetados pelo mau comportamento.

Detalhes sobre métricas

Wake locks travados e parciais travados (segundo plano)

As páginas Wake locks parciais travados e Wake locks parciais travados (segundo plano) mostram wake locks parciais obtidos pelo app por meio da 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 a duração máxima do wake lock parcial por sessão de bateria para mostrar quantas sessões são afetadas por um wake lock longo. Por exemplo, se um usuário acionar dois wake locks de uma hora, o Google 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ó estarão disponíveis se no máximo um app com o mesmo sharedUserId estiver instalado.

Detalhes importantes

  • Sessões afetadas: é a porcentagem de sessões de bateria diárias em que houve pelo menos um wake lock de mais de uma hora.
  • Número de sessões: é o número aproximado de sessões registradas.
  • 90º/99º percentual: 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.

Ativações excessivas

A página Ativações excessivas mostra as ativações do Alarm Manager acionadas pelo app. Você 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 fornecer 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ó estarão 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 refere-se ao 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: é o número aproximado de sessões registradas.
  • 90º/99º percentual: 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.

Excesso de verificações de Wi-Fi (segundo plano)

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 das sessões de bateria em que houve mais de quatro verificações de Wi-Fi por hora.
  • Número de sessões: é o número aproximado de sessões registradas.
  • 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 o app apresente um número elevado de verificações de Wi-Fi em segundo plano, veja as soluções recomendadas no site para desenvolvedores Android

Uso excessivo da rede

A página Uso excessivo da rede (segundo plano) mostra quando uma grande quantidade de dados de rede está associada a um serviço em segundo plano. Quando o uso da rede móvel ocorre 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 das sessões de bateria em que o uso diário de rede em segundo plano superou os 50 MB.
  • Número de sessões: é o número aproximado de sessões registradas.
  • 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 apresente um uso elevado de rede em segundo plano, veja as soluções recomendadas no site para desenvolvedores Android.

Taxas de ANR e multi-ANR

Entender os dados do app

Nas páginas Taxa de ANR e Taxa de multi-ANR, você verá dados semelhantes aos exibidos na página ANRs e falhas do app. Na página "Android vitals", os dados de ANR são combinados com os de uso para criar uma métrica normalizada.

Detalhes da taxa de ANR

  • Sessões impactadas: é a porcentagem de sessões diárias em que ocorreu pelo menos um ANR. Uma sessão diária refere-se a 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.
  • Sessões sem ANR: é a porcentagem de sessões diárias em que os usuários não foram afetados por ANRs. Uma sessão diária refere-se a um dia em que o app foi usado.
  • Número de sessões: é o número aproximado de sessões registradas.
  • 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).

Detalhes da taxa de multi-ANR

  • Sessões afetadas: é a porcentagem de sessões diárias em que houve pelo menos dois ANRs. Uma sessão diária refere-se a 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.
  • Sessões não afetadas: porcentagem de sessões diárias em que houve um ANR ou menos. Uma sessão diária refere-se a um dia em que o app foi usado.
  • Número de sessões: é o número aproximado de sessões registradas.

Corrigir um problema

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

Taxas de falhas e de múltiplas falhas

Entender os dados do app

Nas páginas Taxa de falhas e Taxa de múltiplas falhas, você verá dados semelhantes aos exibidos na página ANRs e falhas do app. Na página Android vitals, os dados de falhas são combinados com os dados de uso para criar uma métrica normalizada.

Detalhes da taxa de falhas

  • Sessões afetadas: é a porcentagem de sessões diárias em que houve pelo menos uma falha. Uma sessão diária refere-se a 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.
  • Sessões sem falhas: é a porcentagem de sessões diárias em que os usuários não foram afetados por falhas. Uma sessão diária refere-se a um dia em que o app foi usado.
  • Número de sessões: é o número aproximado de sessões registradas.
  • 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).

Detalhes da taxa de múltiplas falhas

  • Sessões afetadas: é a porcentagem de sessões diárias em que houve pelo menos duas falhas. Uma sessão diária refere-se a 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.
  • Sessões não afetadas: porcentagem de sessões diárias em que houve uma falha ou menos. Uma sessão diária refere-se a um dia em que o app foi usado.
  • Número de sessões: é o número aproximado de sessões registradas.

Corrigir um problema

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

Frames excessivamente lentos

Entender os dados do app

Na página Frames excessivamente lentos, você verá detalhes sobre a porcentagem de sessões diárias em que os usuários tiveram mais de 50% de frames com um tempo de renderização maior que 16 ms. As interações do usuário com o app devem ser executadas a 60 frames por segundo, sem frames perdidos ou atrasados.

Detalhes da coleta de dados

O Google coleta o tempo de renderização de cada frame renderizado pelo app ao usar a biblioteca UI Toolkit, e não ao usar o OpenGL diretamente.

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 refere-se a 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: é o número aproximado de sessões registradas.
  • 90º/99º percentual: 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ê verá o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, verifique se a maioria dos frames do app apresenta 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, verifique 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 IU lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de IU 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 processados 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 um tempo de renderização maior do que 16 ms, veja as soluções recomendadas no site para desenvolvedores Android.

Frames excessivamente congelados

Na página Frames excessivamente congelados, você verá detalhes sobre a porcentagem de sessões diárias em que os usuários tiveram mais de 0,1% de frames com um tempo de renderização maior que 700 ms. As interações do usuário com o app devem ser executadas a 60 frames por segundo, sem frames perdidos ou atrasados.

Detalhes da coleta de dados

O Google coleta o tempo de renderização de cada frame renderizado pelo app ao usar a biblioteca UI Toolkit, e não ao usar o OpenGL diretamente.

Painel de exibição

Ao expandir uma linha de dimensão, você verá os dados divididos em percentuais.

  • Sessões afetadas: é a porcentagem de sessões diárias em que mais de 0,1% dos frames teve um tempo de renderização maior que 700 ms. Uma sessão diária refere-se a 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: é o número aproximado de sessões registradas.
  • 90º/99º percentual: 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.

Quando você clicar em uma entrada na tabela, verá o gráfico "Distribuição do tempo de renderização da IU". Ao analisar o gráfico, certifique-se de que a maioria dos frames do app esteja abaixo de 700 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, veja o código do seu app que lida com 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 IU lenta: para todos os frames renderizados em mais de 16 ms, é o número de vezes que a linha de execução de IU 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 processados 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 um tempo de renderização maior do que 700 ms, veja as soluções recomendadas no site para desenvolvedores Android.

Tempo de inicialização do app

Na página Tempo de inicialização do app, você verá detalhes sobre a inicialização lenta nos estados do sistema: a frio, com o app aberto em segundo plano e a quente.

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 tiver sido iniciado várias vezes no mesmo dia a partir do mesmo estado do sistema, o tempo máximo de inicialização do dia será registrado.
  • Os tempos de inicialização são rastreados quando o primeiro quadro do app é carregado completamente, mesmo que não seja uma tela com que os usuários interajam.
    • 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 respectivo estado do sistema:
    • Inicialização a frio lenta: cinco segundos ou mais
    • Inicialização lenta com o app aberto em segundo plano: dois segundos ou mais
    • Inicialização a quente lenta: um segundo ou mais
  • Número de sessões: é o número aproximado de sessões registradas.
  • 90º/99º percentual: 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.

Permissões negadas

Na página Permissões negadas, você pode ver detalhes sobre a porcentagem de sessões de permissão diárias durante as quais os usuários negaram permissões. Uma sessão de permissão diária refere-se a 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: é a porcentagem de sessões diárias de permissão com resposta negativa dos usuários.
  • Não perguntar novamente: é a porcentagem de sessões diárias de permissão em que os usuários a negaram selecionando "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.

Analisar seus dados com dimensões

Para ajudar você a organizar, segmentar e analisar as informações, todos os dados do app são detalhados pelas seguintes dimensões:

  • Artefato: versão do app
  • Versão do Android (SDK): a versão do SO Android informada pelo dispositivo do usuário
  • Tipo de dispositivo: o tipo de dispositivo usado para executar o app (por exemplo, "Smartphone", "Tablet", "TV" ou "Wearable")
  • Modelo do dispositivo: a denominação de marketing e o nome do dispositivo do usuário, como "Google Nexus 7/Flo"
  • Nome do bloqueio de wake lock: as tags que foram definidas programaticamente ao usar a API PowerManager no app
  • Nome da ativação: as tags que foram definidas programaticamente ao usar a API StackManager no app
  • Nome da atividade de ANR: nome totalmente qualificado da classe de atividade em que ocorreu o ANR (se disponível)
  • Tipo de ANR: momento em que o ANR ocorreu, por exemplo, ao executar um serviço (se disponível)

Conteúdo relacionado

Veja as práticas recomendadas e use o Android vitals para melhorar o desempenho e a estabilidade do seu app.

Isso foi útil?
Como podemos melhorá-lo?

Precisa de mais ajuda?

Faça login e veja mais opções de suporte para resolver o problema rapidamente.