Solução de problemas e perguntas frequentes sobre o Monitoramento de desempenho
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, fornecemos dicas de solução de problemas para começar a usar o Performance Monitoring ou os recursos e as ferramentas do Performance Monitoring.
Primeiras verificações para a solução de problemas
As duas verificações a seguir são práticas recomendadas gerais para qualquer pessoa
antes da solução de problemas.
1. Verificar se há eventos de desempenho nas mensagens de registro
Verifique suas mensagens de registro para confirmar que o SDK do Performance Monitoring está capturando eventos de desempenho.
Como ver se há eventos de desempenho nas mensagens de registro
Ative a geração de registros de depuração da seguinte maneira:
Verifique o Painel de status do Firebase caso haja uma interrupção conhecida no Firebase ou no Performance Monitoring.
Como começar a usar o Performance Monitoring
Se você está começando a usar o Performance Monitoring (iOS+ | Android | Web), as dicas a seguir podem ajudar a resolver problemas que envolvem a detecção do SDK pelo Firebase ou a exibição dos primeiros dados de desempenho no console do Firebase.
O SDK foi adicionado ao app, mas o console
ainda pede para adicioná-lo
O Firebase pode detectar se você adicionou o SDK do Performance Monitoring ao seu app quando ele recebe informações de eventos (como interações) do aplicativo. O painel Desempenho do console do Firebase costuma exibir a mensagem "SDK detectado" em até 10 minutos após iniciar o app. Em seguida, o painel exibirá os dados iniciais processados em 30 minutos.
Se já passaram mais de 10 minutos desde que você adicionou a versão mais recente do SDK ao app e nenhuma alteração apareceu, verifique suas mensagens de registro para conferir se o Performance Monitoring está registrando eventos. Realize as etapas apropriadas, conforme descrito abaixo, para
solucionar problemas de uma mensagem atrasada de detecção de SDK.
O app está registrando eventos: etapas
de solução de problemas
Se você ainda estiver desenvolvendo localmente, tente gerar mais eventos para a coleta
de dados:
Continue desenvolvendo o app usando um simulador ou dispositivo de teste.
Gere eventos alternando o plano de fundo e o primeiro
plano do app várias vezes. Interaja com o app navegando pelas telas
e/ou acionando solicitações de rede.
Verifique se o arquivo de configuração do
Firebase (Google-Service-Info.plist) foi
adicionado corretamente ao app e se você não o modificou.
Especificamente, verifique o seguinte:
O nome do arquivo de configuração não tem caracteres adicionais, como
(2).
O arquivo de configuração está na raiz do seu projeto do XCode e foi adicionado aos
destinos corretos.
O ID do app da Apple (GOOGLE_APP_ID) no Firebase listado no arquivo de configuração está correto no seu app. Encontre o ID do app no card Seus apps
nas Configurações do projeto (settings).
Se algo parecer errado com o arquivo de configuração no seu app, tente o seguinte:
Exclua o arquivo de configuração atual do app.
Siga estas instruções para fazer o download de um novo arquivo de configuração e adicioná-lo ao seu app Apple.
Se o SDK estiver registrando eventos e tudo estiver configurado corretamente, mas você ainda não estiver vendo a mensagem de detecção do SDK ou os dados processados (após duas horas), entre em contato com o suporte do Firebase.
O app não está registrando eventos:
etapas de solução de problemas
Se você tiver adicionado o SDK e estiver usando o Performance Monitoring no app, as dicas a seguir poderão ajudar a resolver problemas gerais que envolvem recursos e ferramentas do Performance Monitoring.
O aplicativo não está registrando
eventos de desempenho
Faltam dados de traces de tela no
Painel de desempenho
Se você não tiver dados para traces de renderização de tela, tente as
etapas de solução de problemas a seguir:
Faltam dados de traces personalizados
no Painel de desempenho
Você está vendo os dados de desempenho dos traces coletados automaticamente, mas não dos
traces de código personalizados? Realize estas etapas de solução de problemas:
Verifique a configuração de traces de código personalizados instrumentados com a
API Trace,
principalmente o seguinte:
Os nomes dos traces de código e métricas personalizados precisam cumprir os seguintes
requisitos: nenhum espaço em branco no início ou no final, nenhum sublinhado
(_) no início e tamanho máximo de 32 caracteres.
Todos os traces precisam ser iniciados e interrompidos. Os traces que não forem iniciados, que não
forem interrompidos ou que forem interrompidos antes de ser iniciados não serão registrados.
Verifique as mensagens de registro para confirmar se o Performance Monitoring está registrando os traces de código personalizados esperados.
Dependendo do comportamento do código e das bibliotecas de rede usadas pelo código, o Performance Monitoring só pode gerar relatórios sobre solicitações de rede concluídas. Isso significa que as conexões HTTP/S que ficaram abertas talvez não
sejam registradas.
O Performance Monitoring não informa solicitações de rede com cabeçalhos Content-Type inválidos. No entanto, as solicitações de rede sem os cabeçalhos Content-Type ainda serão aceitas.
Os dados de solicitação de rede não são agregados conforme esperado
O que aconteceu com os principais problemas no card de desempenho da página inicial do projeto?
Substituímos Principais problemas por Alertas recentes para expandir mais nosso
recurso de alertas, que envia uma notificação automaticamente quando um
limite definido é ultrapassado. A funcionalidade de problemas foi descontinuada
e substituída por alertas.
O seletor de apps na parte de cima do card de desempenho filtra os problemas
em Alertas recentes. Somente os três alertas mais recentes para os
apps selecionados são exibidos.
O que aconteceu com a capacidade de definir limites para problemas no console?
O Performance Monitoring é compatível com alertas para métricas que excedem os limites definidos. Para evitar confusão com esses limites configuráveis para métricas de desempenho, removemos a capacidade de configurar limites para problemas.
O que aconteceu com as informações de detalhes e métricas no console do Firebase?
Substituímos as páginas de detalhes e métricas por uma interface do usuário (interface)
reformulada e centralizada para melhorar o processo da solução de problemas. Essa nova
interface de solução de problemas oferece a mesma funcionalidade principal que a página de detalhes e
de métricas. Para saber mais sobre a solução de problemas, consulte
Ver mais dados de um trace específico.
Por que o número de amostras não é o que eu esperava?
O Performance Monitoring coleta dados de desempenho dos dispositivos dos usuários no seu app. Se o aplicativo tiver muitos usuários ou se gerar muita atividade de desempenho, o Performance Monitoring poderá limitar a coleta de dados a um subconjunto de dispositivos para reduzir o número de eventos processados. Esses limites são o suficiente para que,
mesmo com menos eventos, os valores das métricas ainda representem a
experiência do usuário no app.
Para gerenciar o volume de dados coletados, o Performance Monitoring usa estas opções de amostragem:
Limitação de taxa no dispositivo: para evitar que um dispositivo envie bursts de traces de repente, limitamos o número de traces de solicitação de código e rede enviados de um
dispositivo para 300 eventos a cada 10 minutos. Assim, o dispositivo é protegido contra
instrumentações de loop que podem enviar grandes quantidades de dados de desempenho e
evitamos a distorção das medidas de desempenho por um único dispositivo.
Amostragem dinâmica: o Performance Monitoring coleta um número limitado de traces de código e
de solicitação de rede por app diariamente de todos os usuários do aplicativo. Uma taxa de amostragem dinâmica é buscada nos dispositivos usando o Firebase Remote Config para determinar se um dispositivo aleatório precisa capturar e enviar traces. Um dispositivo
não selecionado para amostragem não envia eventos. A taxa
de amostragem dinâmica é específica do app e é ajustada para garantir que o volume geral dos
dados coletados continue abaixo do limite.
Os projetos que ativaram a integração do BigQuery recebem um limite maior para o número de rastros de solicitações de rede.
As sessões do usuário enviam outros dados detalhados de um dispositivo, e exige
mais recursos para identificar e enviar as informações. Para minimizar o impacto das sessões de usuários, o Performance Monitoring também pode restringir o número de sessões.
Limitação de taxa do lado do servidor: para garantir que os apps não ultrapassem o limite de amostragem, o Performance Monitoring pode usar a amostragem do lado do servidor para excluir alguns eventos recebidos dos dispositivos. Esse tipo de limitação não altera a
eficácia das nossas métricas, mas pode causar algumas mudanças de padrão, incluindo:
O número de traces e o de vezes em que um código foi executado
podem ser diferentes.
Os traces estreitamente vinculados ao código podem ter um número de amostras
diferente.
O que aconteceu com a guia Problemas no console?
Substituímos a guia "Issues" pela introdução de alertas, que
informa automaticamente quando os limites definidos são excedidos. Não é mais necessário verificar manualmente o console do Firebase para determinar o status de um limite. Para informações sobre Alertas, consulte Configurar alertas de problemas de desempenho.
O que aconteceu com as guias No dispositivo e Rede no console?
Como faço para ver os traces que estavam nessas páginas?
Reformulamos a seção Performance Monitoring do console do Firebase para que a guia Painel exibe as principais métricas e todos os traces em um só lugar. Como parte da reformulação, removemos as páginas No dispositivo e Rede.
A tabela de traces na parte de baixo da guia Painel tem as mesmas
informações que as guias No dispositivo e Rede, mas com alguns
recursos a mais, incluindo a capacidade de ordenar os traces pela mudança na porcentagem
de uma métrica específica. Para visualizar todas as métricas e dados de um trace
específico, clique no nome do trace na tabela.
Veja seus traces nestas subguias da tabela:
Traces de solicitação de rede (prontos para uso e personalizados): subguia Solicitações de rede
Traces de código personalizados: subguia Traces personalizados
Traces de inicialização do app, de app em primeiro plano e de app em segundo plano: subguia Traces personalizados
Traces de renderização da tela: subguia Renderização de tela
Traces de carregamento da página: subguia Carregamento de página
Para saber mais sobre a tabela de traces e como visualizar métricas e dados, acesse a página de informações
gerais do console
(iOS+ |
Android |
Web).
Por que o número de frames lentos e congelados não é o que eu esperava?
Os frames congelados e com renderização lenta são calculados com uma taxa
de atualização de 60 Hz. Se a taxa de atualização do dispositivo for menor que 60 Hz, cada frame
terá um tempo de renderização mais lento, porque menos frames serão renderizados por segundo.
Tempos de renderização mais lentos podem gerar frames mais lentos ou congelados,
porque mais frames são renderizados lentamente ou travam. No entanto, se a taxa de atualização
for maior que 60 Hz, cada frame terá um tempo de renderização mais rápido.
Isso faz com que haja menos frames lentos ou congelados. Essa é uma limitação atual no SDK do Performance Monitoring.
Os dados do Performance Monitoring estão levando mais tempo do que o esperado para serem exportados ao BigQuery. Isso não deveria acontecer em tempo real?
Se você tiver ativado a integração do BigQuery com o Firebase Performance Monitoring, os dados serão exportados para o BigQuery entre 12 e 24 horas após o fim do dia (Horário do Pacífico).
Por exemplo, os dados de 19 de abril estarão disponíveis no BigQuery em 20 de abril
entre as 12h e meia-noite (todas as datas e horas são do Horário do Pacífico).
Processamento e exibição de dados quase em tempo real
O que são os dados de desempenho "quase em tempo real"?
O Firebase Performance Monitoring processa os dados de desempenho coletados à medida que eles chegam, o que resulta em dados quase em tempo real no console do Firebase. Usamos
o termo "quase em tempo real" porque os dados processados são exibidos no console alguns
minutos após a coleta.
Como faço para ter dados de desempenho quase em tempo real sobre meu app?
Para aproveitar o processamento de dados quase em tempo real, basta verificar se o app usa uma versão do SDK do Performance Monitoring compatível com o processamento de dados em tempo real.
Estas são as versões do SDK compatíveis:
iOS: v7.3.0 ou mais recentes
tvOS: v8.9.0 ou mais recentes
Android: v19.0.10 ou mais recente (ou Firebase Android BoM v26.1.0 ou mais recente)
Web: v7.14.0 ou mais recentes
Sempre recomendamos o uso da versão mais recente do SDK, mas qualquer uma das opções acima permitirá que o Performance Monitoring processe os dados quase em tempo real.
Quais versões do SDK do Performance Monitoring são consideradas compatíveis com os dados em tempo real?
Estas são as versões do SDK compatíveis:
iOS: v7.3.0 ou mais recentes
tvOS: v8.9.0 ou mais recentes
Android: v19.0.10 ou mais recente (ou Firebase Android BoM v26.1.0 ou mais recente)
Web: v7.14.0 ou mais recentes
Sempre recomendamos o uso da versão mais recente do SDK, mas qualquer uma das opções acima permitirá que o Performance Monitoring processe os dados quase em tempo real.
E se eu não atualizar o app para usar uma versão do SDK compatível com o processamento em tempo real?
Se o app não usar uma versão do SDK compatível com esse processamento em tempo real, ainda será possível ver todos os dados de desempenho dele no console do Firebase. No entanto, a exibição
dos dados de desempenho será atrasada em cerca de 36 horas a partir do momento da
coleta.
Fiz a atualização para uma versão do SDK compatível com o processamento em tempo real, mas alguns usuários ainda utilizam versões antigas do app. Continuarei vendo os dados de desempenho desses usuários no console do Firebase?
Sim. Você verá os dados de desempenho de todos os usuários independentemente da versão do SDK
utilizada por uma instância do app.
No entanto, se você estiver analisando dados recentes (menos de 36 horas),
as informações mostradas vão ser de usuários em instâncias do app usando uma versão do SDK
compatível com tempo real. Já os dados não recentes vão incluir informações de desempenho
de todas as versões do app.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-26 UTC."],[],[]]
