A biblioteca Jetpack Microbenchmark permite comparar rapidamente seu código nativo do Android (Kotlin ou Java) no Android Studio. A biblioteca processa o aquecimento, mede o desempenho do código e as contagens de alocação e gera resultados de comparação no console do Android Studio e em um arquivo JSON com mais detalhes.
Recomendamos criar um perfil para seu código antes de programar uma comparação. Isso ajuda você a encontrar operações caras que fazem a otimização valer a pena. E pode também esclarecer por que as operações estão lentas, mostrando o que está acontecendo enquanto elas são executadas. Talvez elas estejam sendo executadas em uma linha de execução de baixa prioridade, em suspensão devido ao acesso ao disco ou sendo chamadas inesperadamente por uma função cara, como decodificação de bitmap.
As microcomparações são úteis principalmente para trabalhos da CPU executados várias vezes no app,
também conhecidos como "caminhos de código quente". Alguns exemplos: rolagem de RecyclerView com
um item exibido por vez, conversões/processamento de dados e outros trechos de código
que são usados repetidamente.
Outros tipos de código são mais difíceis de medir com a biblioteca Microbenchmark. Como as comparações são executadas em loop, qualquer código que não seja executado com frequência ou que apresente desempenhos diferentes quando chamado várias vezes pode não funcionar para a comparação.
Para aprender a usar a biblioteca em um ambiente de integração contínua (CI), consulte Executar comparações na integração contínua.
Evitar a medição do cache
Tente evitar medir apenas o cache. Por exemplo, uma comparação para o layout de uma visualização personalizada pode medir apenas o desempenho do cache de layout. Para evitar isso, você pode transmitir diferentes parâmetros de layout em cada loop. Isso pode ser difícil em outros casos, por exemplo, ao medir o desempenho do sistema de arquivos, já que o SO armazena o sistema de arquivos em cache durante o loop.
Código pouco executado
É pouco provável que a compilação JIT pelo Android Runtime (ART) ocorra para um código que é executado apenas uma vez durante a inicialização do aplicativo. Por esse motivo, fazer a comparação desse código com a biblioteca Microbenchmark, em que ele é executado em um loop restrito, não é uma forma realista de medir o desempenho.
Para comparar esse tipo de código, recomendamos a biblioteca Jetpack Macrobenchmark, que permite medir interações de usuário de nível mais alto, como a inicialização do app e o desempenho de rolagem.
Receber comparações consistentes
Os relógios em dispositivos móveis mudam dinamicamente do estado alto (para maior desempenho) para o estado baixo (para economizar energia ou quando o dispositivo esquenta). Esses relógios variados podem fazer com que os números de comparação variem muito. Por esse motivo, a biblioteca oferece maneiras de lidar com esse problema.
Bloquear os relógios (dispositivo com acesso root necessário)
Bloquear os relógios é a melhor maneira de alcançar um desempenho estável. Isso garante que os relógios nunca cheguem a um estado alto o suficiente para aquecer o dispositivo ou a um estado baixo, caso uma comparação não esteja utilizando a CPU totalmente. O bloqueio é aplicado automaticamente, durante a execução de microcomparações com o Gradle, ou manualmente na CI. Embora essa seja a melhor forma de garantir um desempenho estável, ela não recebe suporte da maior parte dos dispositivos porque exige um dispositivo Android com acesso root.
Modo de desempenho sustentado
Window.setSustainedPerformanceMode() é um recurso suportado por alguns dispositivos que permite que um app opte por uma frequência máxima de CPU mais baixa. Quando executada em dispositivos suportados, a biblioteca Microbenchmark usa uma combinação dessa API e inicia a própria atividade para impedir a limitação térmica e estabilizar os resultados.
Essa função é ativada por padrão pelo testInstrumentationRunner definido
pelo plug-in para Gradle. Caso queira usar um executor personalizado, crie uma subclasse no
AndroidBenchmarkRunner e use-a como seu testInstrumentationRunner.
O executor lança uma atividade opaca em tela cheia para garantir que a comparação seja executada em primeiro plano e sem qualquer outro app drenando a bateria.
Pausar a execução automática
Se nem o bloqueio de relógio nem o desempenho sustentado forem usados, a biblioteca executa a detecção de limitação térmica automaticamente. Quando ativada, a comparação interna é executada periodicamente para determinar quando a temperatura do dispositivo ficou alta o suficiente para diminuir o desempenho da CPU. Quando um baixo desempenho da CPU for detectado, a biblioteca pausará a execução para permitir que o dispositivo resfrie e repetirá a comparação atual.
Amostras
- Amostras de desempenho (link em inglês)
- PagingWithNetworkSample (link em inglês)
- WorkManagerSample (link em inglês)
Outros recursos
- Como combater regressões com comparações em CI (em inglês)
Enviar feedback
Para comunicar problemas ou enviar solicitações de recursos usando a comparação, consulte o rastreador de problemas público.