Monitorar o desempenho técnico dos apps com o Android vitals

Com o Play Console, é possível visualizar dados que ajudarão 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ósticos de um subconjunto de dispositivos e versões do SO Android. 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
  • wake locks travados
  • wake locks travados (segundo plano)
  • ativações excessivas
  • excesso de verificações de Wi-Fi (segundo plano)
  • uso excessivo da rede (segundo plano)
Estabilidade
  • taxa de ANRs
  • taxa de multi-ANR
  • taxa de falhas
  • taxa de multifalhas
Tempo de renderização
  • renderização lenta (16 ms)
  • Frames de IU congelados (700 ms)
Tempo de inicialização do app
  • Inicialização lenta com o app fechado
  • Inicialização lenta com o app aberto em segundo plano
  • Inicialização lenta com o app aberto
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).

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

Encontrar e analisar dados do app no Android vitals:

  1. Faça login no Play Console.
  2. Selecione um app.
  3. No menu à esquerda, clique em Android vitals > Visão geral.
  4. Escolha como 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 seu app. Essas métricas são relacionadas a desempenho e podem afetar a visibilidade e a classificação do app no Google Play. As principais métricas incluem:

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

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ções > Preferências.

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 dados de todas as métricas por tipo de dados. Para filtrar a tabela, escolha as dimensões e o período de tempo que você quer visualizar.

Para cada métrica, você pode analisar a porcentagem de sessões do app afetadas do período atual e do período anterior. Para comparar o desempenho do seu app com o de outros apps no Google Play, veja também a diferença deles em relação à mediana.

Visualizar métricas detalhadas

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

  • anomalias encontradas nos dados de desempenho (apenas nas principais métricas)
  • limites de mau comportamento (apenas nas principais métricas);
  • comparativos de mercado por categoria;
  • comparativos de mercado detalhados;
    • Próximo à parte superior da página, no card de comparação de apps semelhantes, selecione Editar grupo de apps semelhantes para editar um grupo personalizado de apps semelhantes. Depois de criar esse grupo, você pode comparar o desempenho do seu app com o de outros apps do Google Play selecionados.
  • métricas por código da versão do APK, dispositivo, versão do sistema operacional, 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, talvez 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 o card com o ícone para ver quais APKs do seu app têm o mau comportamento.

Detalhes sobre métricas

Wake locks travados e wake locks travados (segundo plano)

As páginas Wake locks travados e Wake locks travados (segundo plano) mostram os wake locks parciais adquiridos pelo seu 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 do wake lock parcial 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 travados em segundo plano só são coletados quando o app está 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 aciona 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: 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º percentual: 10% / 1% de 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.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque 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, acesse o site de desenvolvedores Android para ver 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á dados de ativação para as classes ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.

Detalhes da coleta de dados

  • Para fins de privacidade, as tags de identificação do wakeup são mantidas anônimas.
  • Os wakeups são coletados quando o dispositivo não está carregando.
  • Para fornecer uma métrica normalizada, o número de wakeups é comparado ao tempo em que o dispositivo está usando a bateria. O Google calcula o número de wakeups por usuário por hora para mostrar quantos usuários são afetados por uma alta taxa de wakeups.
  • 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: porcentagem de sessões da bateria em que houve mais de 10 ativações por hora. Uma sessão da bateria é o período entre duas cargas completas de um dispositivo. 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º percentual: 10% / 1% de sessões diárias em que os usuários foram afetados por ativações por hora com valor maior do que o exibido.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque 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 de durações da bateria em que houve mais de quatro verificações de Wi-Fi por hora.
  • Número de sessões: número aproximado de sessões gravadas.
  • 90º / 99º percentual: 10% / 1% de sessões diárias em que houve verificações de Wi-Fi em segundo plano de mais de uma hora do que o número exibido.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 

Corrigir um problema

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

Uso excessivo da rede (segundo plano)

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. 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: porcentagem de duração da bateria em que houve uso de mais de 50 MB de rede em segundo plano por dia.
  • Número de sessões: número aproximado de sessões gravadas.
  • 90º / 99º percentual: 10% / 1% de sessões diárias em que houve uso diário de rede em segundo plano com duração maior do que o número exibido.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 

Corrigir um problema

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

Taxa de ANR e taxa de 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 seu 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 afetadas: porcentagem de sessões diárias em que houve pelo menos um ANR. Uma sessão diária se refere a um dia em que o app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá quatro sessões diárias.
  • Sessões sem ANR: 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 seu app foi usado.
  • Número de sessões: número aproximado de sessões gravadas.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 
  • ANRs relacionados: para visualizar detalhes de ANR em tempo real, selecione o link ANRs. Você será direcionado para a página "ANRs e falhas" no Play Console.

Detalhes da taxa de multi-ANR

  • Sessões afetadas: porcentagem de sessões diárias em houve pelo menos dois ANRs. Uma sessão diária refere-se a um dia em que seu app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá 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 seu app foi usado.
  • Número de sessões: número aproximado de sessões gravadas.
  • ANRs relacionados: para visualizar detalhes de ANR em tempo real, selecione o link ANRs. Você será direcionado para a página "ANRs e falhas" no Play Console.

Corrigir um problema

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

Taxa de falhas e taxa de multifalhas

Entender os dados do app

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

Detalhes da taxa de falhas

  • Sessões afetadas: 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 seu app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá quatro sessões diárias.
  • Sessões sem falhas: 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 seu app foi usado.
  • Número de sessões: número aproximado de sessões gravadas.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 
  • Falhas relacionadas: para visualizar detalhes de falhas em tempo real, selecione o link Falhas. Você será direcionado para a página "ANRs e falhas" no Play Console.

Detalhes da taxa de multifalhas

  • Sessões afetadas: 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 seu app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá 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 seu app foi usado.
  • Número de sessões: número aproximado de sessões gravadas.
  • Falhas relacionadas: para visualizar detalhes de falhas em tempo real, selecione o link Falhas. Você será direcionado para a página "ANRs e falhas" no Play Console.

Corrigir um problema

Se o app tiver um grande número de falhas, acesse o site de desenvolvedores Android para ver as soluções recomendadas.

Renderização lenta

Entender os dados do app

Na página Renderização lenta, 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 do que 16 ms. As interações do usuário com seu app devem ser executadas em 60 quadros 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: porcentagem de sessões diárias em que os usuários tiveram mais de 50% de frames com um tempo de renderização maior do que 16 ms. Uma sessão diária refere-se a um dia em que seu app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá quatro sessões diárias.
  • Número de sessões: número aproximado de sessões gravadas.
  • 90º / 99º percentual: 90% / 99% do total de frames teve um tempo menor de renderização do que o número mostrado. Esses números são baseados em todos os frames coletados.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 

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 estão abaixo de 16 ms.

Os dados abaixo do gráfico transmitem o desempenho de renderização do app e podem ajudar você a encontrar a causa principal 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.

  • Vsync perdido: para todos os frames renderizados em mais de 16 ms, o número de eventos de Vsync perdidos dividido pelo número 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 pelo número de frames.
  • Thread de IU lento: para todos os frames renderizados em mais de 16 ms, o número de vezes que o thread da IU levou mais de 8 ms para ser concluído dividido pelo número 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 pelo número 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 pelo número de frames.

Corrigir um problema

Se o app tiver um número alto de frames com um tempo de renderização maior do que 16 ms, acesse o site de desenvolvedores Android para ver as soluções recomendadas.

Frames congelados

Na página Frames congelados, você verá detalhes sobre a porcentagem de sessões diárias em que os usuários tiveram mais de 0,1% dos frames com um tempo de renderização maior do que 700 ms. As interações do usuário com seu app devem ser executadas em 60 quadros 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: 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 do que 700 ms. Uma sessão diária refere-se a um dia em que seu app foi usado. Por exemplo, se dois usuários usarem o app por dois dias, ele produzirá quatro sessões diárias.
  • Número de sessões: número aproximado de sessões gravadas.
  • 90º / 99º percentual: 90% / 99% do total de frames teve um tempo menor de renderização do que o número mostrado. Esses números são baseados em todos os frames coletados.
  • Quartil inferior: caso seu app exiba uma taxa de ocorrência igual ou superior ao limite mostrado, é porque ele está entre os últimos 25% dos 1.000 apps principais no Google Play (por número de instalações). 

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 estejam 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.

  • Vsync perdido: para todos os frames renderizados em mais de 16 ms, o número de eventos de Vsync perdidos dividido pelo número 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 pelo número de frames.
  • Thread de IU lento: para todos os frames renderizados em mais de 16 ms, o número de vezes que o thread da IU levou mais de 8 ms para ser concluído dividido pelo número 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 pelo número 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 pelo número de frames.

Corrigir um problema

Se o app tiver um número alto de frames com um tempo de renderização maior do que 700 ms, acesse o site de desenvolvedores Android para ver as soluções recomendadas.

Tempo de inicialização do app

Na página Tempo de inicialização do app, você verá detalhes sobre a inicialização lenta a partir dos estados fechado (a frio), aberto em segundo plano e aberto do sistema.

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: porcentagem de sessões em que houve um tempo de inicialização lento para cada respectivo estado do sistema:
    • Inicialização lenta com o app fechado: cinco segundos ou mais
    • Inicialização lenta com o app aberto em segundo plano: dois segundos ou mais
    • Inicialização lenta com o app aberto em segundo plano: um segundo ou mais
  • Número de sessões: número aproximado de sessões gravadas.
  • 90º / 99º percentual: 10% / 1% de sessões diárias em que houve tempo de inicialização lento para seu app.
  • Quartil inferior: se o app exibir uma taxa de ocorrência igual ou superior ao limite mostrado, é porque 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 grande número de tempos de inicialização lentos, acesse o site Desenvolvedores Android para ver as soluções recomendadas.

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 seu 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: porcentagem de sessões diárias de permissão em que os usuários negaram permissões selecionando Não perguntar novamente.
  • Total de solicitações: número aproximado de sessões de gravação.
  • Quartil inferior: se o app exibir uma taxa de ocorrência igual ou superior ao limite mostrado, é porque 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 grande número de permissões negadas, acesse o site de desenvolvedores Android para ver as soluções recomendadas.

Analisar seus dados com dimensões

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

  • Versão do app: a versão do seu app
  • Versão do Android: a versão do SO Android informada a partir do dispositivo do usuário
  • Dispositivo: nome de marketing e do dispositivo do usuário, como Google Nexus 7 (Flo), por exemplo
  • Tag de wake lock: as tags que foram definidas programaticamente usando a PowerManager API no seu app
  • Tag de wakeup: as tags que foram definidas programaticamente usando a AlarmManager API no seu app
  • Nome da atividade de ANR: nome totalmente qualificado da classe de atividade em que o ANR ocorreu (se disponível)
  • Tipo de ANR: quando 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?