Avaliar performance

Usar Simpleperf (link em inglês) para avaliar o desempenho de um dispositivo. O Simpleperf é uma ferramenta nativa de criação de perfis para e processos nativos no Android. Usar CPU Profiler para inspecionar o uso de CPU do app e a atividade das linhas de execução em tempo real.

Há dois indicadores de desempenho visíveis ao usuário:

• Desempenho previsível e perceptível. se o usuário interface (IU) solta frames ou renderiza consistentemente a 60 QPS? O áudio toca? sem artefatos ou estouros? Quanto tempo leva entre o toque do usuário na tela e o efeito mostrado na tela?
• Tempo necessário para operações mais longas (como abrir aplicativos).

A primeira é mais perceptível que a segunda. Os usuários geralmente percebem instabilidade mas não vão conseguir prever 500 ms versus 600 ms de tempo de inicialização do app, a menos que ele está olhando para dois dispositivos lado a lado. A latência de toque é imediata perceptíveis e contribuem significativamente para a percepção de um dispositivo.

Como resultado, em um dispositivo rápido, o pipeline de IU é o mais importante no sistema além do necessário para manter o pipeline de IU funcional. Isso significa que o pipeline de interface deve antecipar qualquer outro trabalho que não seja necessário para interface fluida. Para manter uma interface fluida, sincronização em segundo plano, entrega de notificações e trabalhos semelhantes precisam ser atrasados se o trabalho da interface puder ser executado. É aceitáveis em troca do desempenho de operações mais longas (ambiente de execução HDR+, inicialização do app etc.) para manter uma interface fluida.

Capacidade versus instabilidade

Ao considerar o desempenho do dispositivo, a capacidade e a instabilidade são duas métricas significativas.

Capacity

Capacidade é a quantidade total de algum recurso que o dispositivo possui por por um determinado período. Podem ser recursos de CPU, de GPU, de E/S, recursos de rede, largura de banda de memória ou qualquer métrica semelhante. Ao examinar desempenho de todo o sistema, pode ser útil abstrair os componentes individuais e assumem uma única métrica que determina o desempenho (especialmente ao ajustar um um novo dispositivo, porque as cargas de trabalho executadas nele provavelmente serão corrigidas.

A capacidade de um sistema varia de acordo com os recursos de computação on-line. Mudar a frequência de CPU/GPU é o principal meio de alterar a capacidade, mas há outras como a alteração do número de núcleos de CPU on-line. Portanto, os a capacidade de um sistema corresponde ao consumo de energia. mudando e capacidade sempre resulta em uma mudança semelhante no consumo de energia.

A capacidade necessária em um dado momento é determinada principalmente pelo aplicativo em execução. Como resultado, a plataforma pode fazer pouco para ajustar o capacidade necessária para uma determinada carga de trabalho, e os meios para isso estão limitados a melhorias no tempo de execução (framework do Android, ART, Bionic, drivers/compiladores de GPU, kernel).

Instabilidade

Embora seja fácil identificar a capacidade necessária para uma carga de trabalho, a instabilidade é um conceito nebuloso. Uma boa introdução à instabilidade como um impedimento para em sistemas, consulte O CASO DO DESEMPENHO AUSENTE DO SUPERCOMPUTADOR: ALCANÇAR O DESEMPENHO OTIMIAL NO OS 8.192 PROCESSADORES DO ASCl Q. (É uma investigação do motivo pelo qual a ASCI O supercomputador Q não atingiu o desempenho esperado e é um excelente introdução à otimização de sistemas grandes.)

Esta página usa o termo instabilidade para descrever o que o artigo ASCI Q chama ruído. A instabilidade é o comportamento aleatório do sistema que impede da execução. Muitas vezes, é um trabalho que precisa ser executado, mas pode não ter requisitos de tempo que fazem com que ele seja executado em um determinado momento. Porque ela é aleatória, é extremamente difícil refutar a existência de instabilidade para determinada carga de trabalho. Também é extremamente difícil provar que uma fonte conhecida de a instabilidade foi a causa de um determinado problema de desempenho. As ferramentas mais comumente usada para diagnosticar causas de instabilidade (como rastreamento ou geração de registros) pode introduzir a própria instabilidade.

Fontes de instabilidade experimentadas em implementações do Android no mundo real incluem:

• Atraso do programador
• Interromper gerenciadores
• Código do driver em execução por muito tempo com preempção ou interrupções desativadas
• Softirqs de longa duração
• Contenção de bloqueio (app, framework, driver do kernel, bloqueio de binder, mmap) cadeado)
• Contenção do descritor de arquivo em que um thread de baixa prioridade mantém o bloqueio em um , impedindo que um thread de alta prioridade seja executado
• Execução de códigos críticos para a interface em filas de trabalho que podem sofrer atrasos
• Transições de inatividade da CPU
• Geração de registros
• Atrasos de E/S
• Criação desnecessária de processos (por exemplo, transmissões CONNECTIVITY_CHANGE).
• Troca frequente de cache no cache da página causada por memória livre insuficiente

O tempo necessário para um determinado período de instabilidade pode ou não e reduzir à medida que a capacidade aumenta. Por exemplo, se um motorista deixa intervalos desativada enquanto espera uma leitura de um barramento i2c, levará uma leitura independentemente de a CPU estar em 384 MHz ou 2 GHz. Aumentando capacidade não é uma solução viável para melhorar o desempenho quando a instabilidade é envolvidas. Como resultado, processadores mais rápidos não costumam melhorar desempenho em situações de instabilidade.

Por fim, ao contrário da capacidade, a instabilidade está quase que totalmente dentro do domínio fornecedor do sistema.

Consumo de memória

O consumo de memória é tradicionalmente responsável pelo baixo desempenho. consumo em si não é um problema de desempenho, ele pode causar instabilidade lowmemorykiller, reinicializações do serviço e sobrecarga do cache de página. Reduzindo consumo de memória pode evitar as causas diretas do baixo desempenho, mas há podem ser outras melhorias direcionadas que também evitam essas causas (por exemplo, Fixe o framework para evitar que ele seja paginado quando for paginado. logo em seguida).

Analisar o desempenho inicial do dispositivo

Começar com um sistema funcional, mas com baixo desempenho, e tentar corrigir o comportamento do sistema analisando casos individuais de problemas o desempenho não é uma estratégia sólida. Como o baixo desempenho geralmente não é facilmente reproduzível (ou seja, instabilidade) ou um problema do aplicativo muitas variáveis no sistema completo impedem que essa estratégia seja eficaz. Conforme como resultado, é muito fácil identificar as causas incorretamente e fazer pequenas melhorias perder oportunidades sistêmicas para corrigir o desempenho em todo o sistema.

Em vez disso, use a seguinte abordagem geral ao criar uma nova dispositivo:

1. Inicialização do sistema na interface com todos os drivers em execução e alguns drivers as configurações do controlador de frequência (se você alterar essas configurações, repita todas as etapas abaixo).
2. Verifique se o kernel oferece suporte ao tracepoint sched_blocked_reason bem como outros tracepoints no pipeline de exibição que indicam quando o frame é exibida na tela.
3. Criar rastreamentos longos de todo o pipeline de interface (desde o recebimento de entradas por um IRQ) para a verificação final) enquanto executam uma carga de trabalho leve e consistente (por exemplo, UiBench (link em inglês) ou o teste com bola em TouchLatency).
4. Corrija as quedas de frames detectadas na versão leve e consistente. carga de trabalho do Google Cloud.
5. Repita as etapas 3 a 4 até que seja possível executar sem frames perdidos por mais de 20 segundos por vez.
6. Passe para outras fontes de instabilidade visíveis ao usuário.

Outras ações simples que você pode fazer no início do dispositivo incluem:

• Certifique-se de que o kernel tenha a sched_blocked_reason patchpoint do tracepoint. Este tracepoint está ativado com a categoria de trace programado no Systrace e fornece a função responsável por suspender quando esse entra em suspensão ininterrupta. É essencial para a análise de desempenho porque a suspensão ininterrupta é um indicador muito comum de instabilidade.
• Verifique se você tem rastreamento suficiente para a GPU e os pipelines de exibição. Ativado SOCs recentes da Qualcomm, os pontos de rastreamento são ativados usando:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

Esses eventos permanecem ativados quando você executa o Systrace. Assim, é possível ver informações no trace sobre o pipeline de exibição (MDSS) no Seção mdss_fb0. Nos SOCs Qualcomm, não haverá informações sobre a GPU na visualização padrão do Systrace, mas os resultados presentes no próprio trace (para detalhes, consulte Compreensão Systrace).

O que você espera desse tipo de rastreamento de tela é um único evento que indica diretamente que um frame foi enviado à tela. A partir daí, você possa determinar se você atingiu o tempo para a renderização do frame; se o evento Xn ocorrer menos de 16,7 ms após o evento Xn-1 (supondo uma tela de 60 Hz), você saberá que não se atrapalhou. Se o seu SOC não fornecer tais sinais, trabalhe com seu fornecedor para consegui-los. Depurar a instabilidade é extremamente difícil sem uma sinal definitivo de conclusão de frame.

Usar comparativos de mercado sintéticos

Comparativos de mercado sintéticos são úteis para garantir a funcionalidade básica de um dispositivo está presente. No entanto, tratar os comparativos de mercado como um proxy do dispositivo percebido o desempenho deles não é útil.

Com base em experiências com SOCs, diferenças no comparativo de mercado sintético desempenho entre SOCs não está correlacionado com uma diferença semelhante em desempenho perceptível da interface (número de frames descartados, frame no 99o percentil momento etc.). Os comparativos de mercado sintéticos são apenas de capacidade. impactos de instabilidade o desempenho medido desses comparativos de mercado apenas roubando tempo do conjunto de dados operação da comparação. Como resultado, as pontuações de comparativo de mercado sintéticas são irrelevantes como uma métrica de desempenho percebido pelo usuário.

Considere dois SOCs executando o Benchmark X que renderiza 1.000 frames de interface do usuário e informa o tempo total de renderização (pontuação mais baixa, melhor).

• O SOC 1 renderiza cada frame do Benchmark X em 10 ms e pontua 10.000.
• O SOC 2 renderiza 99% dos frames em 1 ms, mas 1% dos frames em 100 ms e pontuações 19.900, uma pontuação significativamente melhor.

Se o comparativo de mercado for indicativo do desempenho real da interface do usuário, o SOC 2 seria inutilizáveis. Supondo uma taxa de atualização de 60 Hz, o SOC 2 teria um frame instável a cada 1,5 segundo de operação. Enquanto isso, o SOC 1 (o SOC mais lento de acordo com o Benchmark X) seria perfeitamente fluida.

Usar relatórios de bugs

Os relatórios de bugs às vezes são úteis para a análise do desempenho, mas como são tão pesados que raramente são úteis para depurar problemas esporádicos de instabilidade. Eles podem dar algumas dicas sobre o que o sistema estava fazendo em um determinado momento, especialmente se a instabilidade ocorreu em torno de uma transição do app (que está conectada um relatório do bug). Os relatórios de bugs também podem indicar quando algo é mais amplo com um sistema que poderia reduzir sua capacidade efetiva (como temperatura limitação ou fragmentação de memória).

Usar a latência de toque

Vários exemplos de mau comportamento vêm do TouchLatency, que é a carga de trabalho periódica preferencial usada para o Pixel e o Pixel XL. Ele está disponível em frameworks/base/tests/TouchLatency e tem dois modos: latência de toque e bola saltitante (para alternar os modos, clique no botão no canto superior direito direito).

O teste da bola quicar é tão simples quanto parece: uma bola quicando pela tela para sempre, independentemente da entrada do usuário. Geralmente também é de longe o teste mais difícil de ser executado perfeitamente, mas quanto mais próximo ele começar a funcionar sem perder frames, melhor será o seu dispositivo. A o teste da bola saltitante é difícil, pois é um teste simples, mas perfeitamente consistente que é executada em um relógio muito baixo (supõe que o dispositivo tem uma frequência governador Se o dispositivo usar relógios fixos, faça o downclock do CPU/GPU quase mínima ao executar o teste da bola saltitante pela primeira vez). À medida que o sistema diminui e os relógios ficam mais inativos, a CPU/GPU necessária o tempo por frame aumenta. Você pode observar a bola e as coisas ficarem instáveis, você também poderá ver frames perdidos no Systrace.

Como a carga de trabalho é muito consistente, é possível identificar a maioria das fontes a instabilidade com muito mais facilidade do que na maioria das cargas de trabalho visíveis ao usuário, monitorando esteja em execução exatamente no sistema durante cada frame perdido, e não na IU pipeline. Os relógios mais baixos amplificam os efeitos da instabilidade, maior é a probabilidade de que qualquer instabilidade cause uma queda de frame. Como resultado, mais próxima de TouchLatency for 60 QPS, menor será a probabilidade de ter um sistema ruim comportamentos que causam instabilidade esporádica e de difícil reprodução apps.

Como a instabilidade costuma (mas nem sempre) ser invariante, use um teste que é executado em relógios muito baixos para diagnosticar a instabilidade pelos seguintes motivos:

• Nem toda instabilidade é invariante em relação à velocidade do clock. muitas fontes só consomem CPU tempo de resposta.
• O governador deve conseguir o tempo médio para a renderização próximo do prazo ao para que o tempo gasto em trabalhos não relacionados à interface do usuário possa empurrá-lo para fora da borda descartando um frame.