Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Visão geral das ferramentas relacionadas à coleta e análise de desempenho

Existem muitas ferramentas para coletar, analisar e exibir dados de desempenho de aplicativos móveis, que podem ser divididos aproximadamente nas seguintes categorias. Por exemplo, ferramentas de desempenho móvel que podem coletar vários indicadores de desempenho, perfdog e Solopi, entre os quais Solopi é de código aberto e pefdog é uma ferramenta comercial. Ferramentas que podem realizar análises de falhas, como o Firebase Crashlytics comercial e a ferramenta Sentry de código aberto. Se precisar analisar dados relacionados à rede, você pode usar Charles ou Wireshark. Além disso, existem ferramentas abrangentes de gestão de desempenho, como o Dynatrace. De modo geral, as capacidades, a precisão e a experiência do usuário das ferramentas comerciais são definitivamente melhores do que as ferramentas de código aberto. Como estudo e pesquisa pessoal, só posso começar com ferramentas de código aberto. Portanto, ao escrever este blog, também usaremos ferramentas de código aberto como exemplos.

Ferramenta de teste de desempenho móvel：
PerfDog: Uma ferramenta para monitorar desempenho de aplicativos, CPU, memória, consumo de energia e outros dados, suportando testes de desempenho e monitoramento em tempo real de aplicativos móveis.
Solopi: concentra-se em testar e monitorar o desempenho de aplicativos móveis, incluindo monitoramento em tempo real de taxa de quadros, CPU, memória e outros indicadores.

Ferramenta de análise de falhas：
Firebase Crashlytics: uma poderosa ferramenta de relatório e análise de falhas fornecida pelo Google que pode monitorar falhas de aplicativos em tempo real.
Sentry: Uma ferramenta de rastreamento de erros de código aberto que suporta múltiplas plataformas, incluindo relatórios de erros e monitoramento de desempenho de aplicativos móveis.

Ferramentas de teste de desempenho de rede：
Charles Proxy: Uma ferramenta de proxy de depuração de rede que captura e analisa dados de solicitação e resposta de rede para aplicativos móveis.
Wireshark: Uma ferramenta de análise de rede de código aberto que oferece suporte à captura e análise de pacotes de rede de aplicativos móveis.

Ferramentas APM(Gerenciamento de desempenho de aplicativos):
Dynatrace: Uma solução de monitoramento de desempenho full-stack nativa da nuvem que oferece suporte ao monitoramento de desempenho de aplicativos móveis e análise da experiência do usuário.

Quais métricas de desempenho são coletadas e como

  Antes de realizar a análise de desempenho, você deve primeiro entender o significado de cada indicador de desempenho. Tomando como exemplo os indicadores de desempenho coletados pelo Solopi, vamos dar uma olhada nos indicadores comuns de desempenho de aplicativos móveis e como esses indicadores podem ser coletados.

Taxa de quadros

A fórmula para calcular a taxa de quadros é:Taxa de quadros = número de quadros desenhados/período de tempo,A taxa de quadros desejada para a maioria dos desenvolvedores de aplicativos e jogos é60 FPS( quadros/segundo), por que a taxa de quadros alvo é de 60FPS? Como a taxa de atualização da tela da maioria dos smartphones e tablets modernos é de 60 Hz, desde que a taxa de quadros atinja 60 FPS, ou seja, o número de quadros desenhados por segundo seja 60, os efeitos visuais do usuário serão mais suaves e não haverá atraso. O mínimo não pode ser inferior a 30FPS. Isso ocorre porque o monitor exibe repetidamente a imagem do quadro anterior enquanto espera por um novo quadro, fazendo com que a imagem fique irregular. Os altos podem chegar a 90FPS (por exemplo, para dispositivos com altas taxas de atualização).

Como coletar informações de taxa de quadros

  Existem duas maneiras de coletar a taxa de quadros. Uma é usar a classe Choreographer para coletar estatísticas de taxa de quadros. Isso requer a gravação de código no aplicativo e só pode coletar as informações de taxa de quadros do aplicativo.Outra forma é usar ferramenta gfxinfo. Tomando Solopi como exemplo, o tempo limite do quadro dentro de 1 segundo também é calculado por meio das informações da ferramenta gfxinfo e a taxa de quadros real é deduzida. Portanto, quando está próximo do estacionário, parte da taxa de quadros pode ser exibida incorretamente. Recomenda-se realizar testes de taxa de quadros em cenários dinâmicos, como deslizamento ou troca de página. O método gfxinfo pode coletar informações de taxa de quadros de todos os aplicativos e é muito adequado como ferramenta de coleta de dados de desempenho. Portanto, aqui também nos concentramos em como coletar informações de taxa de quadros por meio do gfxinfo.

Existem duas etapas principais para coletar informações de taxa de quadros.passo um: Obtenha informações do gfxinfo por meio do comando adb,Passo 2 : analisa as informações e calcula as informações da taxa de quadros. O conteúdo das informações do gfxinfo é aproximadamente o seguinte:

Estatísticas desde: hora de início das estatísticas, a unidade é nanossegundos.
Total de quadros renderizados: Número total de quadros renderizados.
Quadros instáveis: O número de quadros instáveis, ou seja, o número de quadros que excede 16 ms (intervalo de atualização de 60 quadros por segundo).
Porcentagem de quadros instáveis: a proporção de quadros instáveis ​​em relação ao número total de quadros.
Percentil 90: percentil 90, indicando que 90% dos frames possuem tempos de renderização abaixo deste valor (em milissegundos).
Percentil 95: percentil 95, indicando que 95% dos frames possuem tempos de renderização abaixo deste valor (em milissegundos).
Percentil 99: percentil 99, indicando que 99% dos frames possuem tempos de renderização abaixo deste valor (em milissegundos).
Number Missed Vsync: O número de sincronizações verticais não sincronizadas, ou seja, o número de quedas de quadros causadas por falha na renderização no tempo.
Número Alta latência de entrada: O número de atrasos de entrada altos indica o número de atrasos causados ​​por um tempo de processamento de evento de entrada muito longo.
Número de thread de UI lento: o número de vezes que o thread de UI respondeu lentamente, ou seja, o número de vezes que o thread de UI demorou muito para ser processado.

Tomando Solopi como exemplo, a taxa de quadros é deduzida através do tempo limite do quadro nas informações do gfxinfo. Para o código do projeto específico, você pode visualizar o código-fonte do solopi.

taxa de atraso/número de atrasos

Número de congelamentos : Durante o período de teste, o número de períodos durante os quais a taxa de quadros é detectada como inferior ao limite. Sempre que a taxa de quadros cai abaixo do limite por um período de tempo, isso é contado como uma falha. O limite aqui pode ser personalizado. Por exemplo, se for 60FPS inferior à taxa de quadros desejada, pode ser gravado como um congelamento. Ou seja, se o tempo de renderização do quadro for superior a 16ms, ele é calculado como travado.

taxa de atraso : A porcentagem do tempo de congelamento em relação ao tempo total de teste. Suponha que em um teste o aplicativo foi executado por 120 segundos, durante os quais a taxa de quadros foi inferior a 16 FPS 4 vezes no total e o tempo de atraso total foi de 8 segundos, então: o número de atrasos: 4 vezes. Taxa de gagueira: 8/120*100%=6,7%. No gfxinfo acima, também há informações de dados sobre a taxa de atraso.

CPU/memória

  Tomando Solopi como exemplo, CPU inclui a porcentagem de uso da CPU do processo onde a atividade de nível superior do aplicativo está localizada e a porcentagem global de uso da CPU. Para aplicativos de processo único, esses dados representam o uso da CPU do aplicativo; aplicativos de processo de vários processos, esses dados representam o uso da CPU de nível superior; quando ocorre uma troca de processo, o Soloπ pode alternar automaticamente para novos dados de processo.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Tempo de resposta

  Tomemos Solopi como exemplo, Contém dados de tempo de resposta e tempo de atualização para cliques no aplicativo. Pertence aos dados de dimensão do aplicativo. O tempo desde o clique do usuário até a primeira vez que o sistema emite uma atualização da interface é o tempo de resposta, e o tempo até o sistema parar de atualizar a interface é o tempo de atualização. A lógica de contar o tempo de resposta é dividir a gravação da tela em frames. De acordo com o site oficial do Solopi, ele reconhece automaticamente o frame inicial e o frame final para contar o tempo de resposta. o tempo de resposta não está correto. Por exemplo, quando o usuário clica em Iniciar, ao clicar na página do aplicativo, o tempo de operação da velocidade manual de alguém no meio é incluído e esta parte é contada no tempo de resposta. Portanto, se você deseja calcular o tempo de resposta da página preparada, é mais preciso apenas gravar a tela e identificar manualmente os frames inicial e final da página. As etapas específicas para gravar quadros de tela são as seguintes:

O texto acima é uma compreensão do significado dos indicadores de desempenho comuns em aplicativos móveis, bem como instruções detalhadas sobre como coletá-los. Em relação a travamentos, etc., iremos apresentá-los em detalhes em um blog subsequente.