Comparar métricas do Compose e da visualização

O Jetpack Compose acelera o desenvolvimento de interfaces e melhora o desenvolvimento para Android. No entanto, considere como adicionar o Compose a um app atual pode afetar métricas como o tamanho do APK, o build e o desempenho de execução do app.

Tempos de compilação e tamanho do APK

Nesta seção, vamos analisar o impacto no tamanho do APK e no tempo de build usando o app de exemplo Sunflower, que demonstra as práticas recomendadas para migrar um app baseado em visualizações para o Compose.

Tamanho do APK

Adicionar bibliotecas ao projeto aumenta o tamanho do APK. Os resultados a seguir são para o APK de lançamento minificado de cada projeto com a redução de recursos e código ativada, usando o modo completo do R8 e medidos com o APK Analyzer.

Ao adicionar o Compose ao Sunflower pela primeira vez, o tamanho do APK aumentou de 2.252 KB para 3.034 KB, um aumento de 782 KB. O APK gerado consistia na build da interface com uma combinação de visualizações e do Compose. Esse aumento é esperado, já que mais dependências foram adicionadas ao Sunflower.

Por outro lado, quando o Sunflower foi migrado para um app somente do Compose, o tamanho do APK diminuiu de 3.034 KB para 2.966 KB, uma redução de 68 KB. Essa diminuição ocorreu devido à remoção de dependências de visualização não utilizadas, como AppCompat e ConstraintLayout.

Tempo de compilação

Adicionar o Compose aumenta o tempo de build do app, já que o compilador do Compose processa os elementos de composição no app. Os resultados a seguir foram obtidos usando a ferramenta independente gradle-profiler, que executa um build várias vezes para que um tempo médio de build possa ser obtido para a duração do build de depuração do Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

Ao adicionar o Compose ao Sunflower, o tempo médio de build aumentou de 299 ms para 399 ms, um aumento de 100 ms. Essa duração se deve ao fato de o compilador do Compose realizar tarefas adicionais para transformar o código do Compose definido no projeto.

Por outro lado, o tempo médio de build caiu para 342 ms, uma redução de 57 ms, quando a migração do Sunflower para o Compose foi concluída. Essa redução pode ser atribuída a vários fatores que, juntos, reduzem o tempo de build, como a remoção da vinculação de dados, a migração de dependências que usam o kapt para o KSP e a atualização de várias dependências para as versões mais recentes.

Resumo

A adoção do Compose vai aumentar o tamanho do APK do app e o tempo de build devido ao processo de compilação do código do Compose. No entanto, essas compensações precisam ser comparadas com os benefícios do Compose, especialmente em relação ao aumento da produtividade do desenvolvedor ao adotar o Compose. Por exemplo, a equipe da Google Play Store descobriu que escrever a interface exige muito menos código, às vezes até 50%, aumentando a produtividade e a facilidade de manutenção do código.

Leia mais estudos de caso em Adotar o Compose para equipes.

Desempenho em tempo de execução

Nesta seção, abordamos tópicos relacionados ao desempenho de execução no Jetpack Compose para ajudar a entender como o Jetpack Compose se compara ao desempenho do sistema de visualização e como você pode medir isso.

Recomposições inteligentes

Quando partes da IU são inválidas, o Compose tenta recompor apenas aquelas que precisam ser atualizadas. Leia mais sobre isso na documentação sobre o ciclo de vida de elementos combináveis e as fases do Jetpack Compose.

Perfis de referência

Os perfis de referência são uma excelente maneira de acelerar as jornadas comuns do usuário. Incluir um perfil de referência no app pode melhorar a velocidade de execução de código em cerca de 30% desde a primeira inicialização, evitando a interpretação e as etapas de compilação just-in-time (JIT) para caminhos de código incluídos.

A biblioteca Jetpack Compose inclui o próprio perfil de referência, e você recebe essas otimizações automaticamente ao usar o Compose no app. No entanto, essas otimizações afetam apenas os caminhos de código na biblioteca do Compose. Por isso, recomendamos que você adicione um perfil de referência ao app para cobrir os caminhos de código fora do Compose.

Comparação com o sistema de visualização

O Jetpack Compose tem muitas melhorias em relação ao sistema de visualização. Essas melhorias são descritas nas seções a seguir.

Tudo estende a visualização

Cada View que é mostrada na tela, como TextView, Button ou ImageView, exige alocações de memória, rastreamento explícito de estado e vários callbacks para oferecer suporte a todos os casos de uso. Além disso, o proprietário do View personalizado precisa implementar uma lógica explícita para evitar que o desenho seja refeito quando não for necessário, por exemplo, para o processamento repetitivo de dados.

O Jetpack Compose resolve isso de algumas maneiras. O Compose não tem objetos atualizáveis explícitos para mostrar visualizações. Os elementos da interface são funções combináveis simples com informações gravadas na composição de forma repetida. Isso ajuda a reduzir o rastreamento de estado explícito, as alocações de memória e os callbacks apenas para os elementos que precisam desses recursos, em vez de fazer a exigência deles para todas as extensões de determinado tipo de View.

Além disso, o Compose oferece recomposições inteligentes, que repetem o resultado desenhado anteriormente se você não precisar fazer mudanças.

Várias transmissões de layout

Os ViewGroups tradicionais têm muita expressividade nas APIs de medição e layout, o que os torna propensos a várias passagens de layout. Essas transmissões de layout podem gerar trabalho exponencial se realizadas em pontos aninhados específicos da hierarquia de visualização.

O Jetpack Compose aplica uma única passagem de layout para todos os elementos combináveis de layout usando o contrato da API. Isso permite que o Compose processe árvores de IU profundas com eficiência. Se várias medições forem necessárias, o Compose tem medições intrínsecas.

Desempenho da inicialização da visualização

O sistema de visualização precisa inflar layouts XML ao mostrar um layout específico pela primeira vez. Esse custo é economizado no Jetpack Compose, já que os layouts são escritos em Kotlin e compilados como o restante do app.

Comparar o Compose

No Jetpack Compose, há diferenças significativas entre o desempenho de um app nos modos debug e release. Para tempos representativos, sempre use o build release, em vez do debug, ao criar o perfil do app.

Para verificar a performance do código do Jetpack Compose, use a biblioteca Jetpack Macrobenchmark. Para aprender a usá-la com o Jetpack Compose, consulte o projeto MacrobenchmarkSample.

A equipe do Jetpack Compose também usa a Macrobenchmark para rastrear regressões e validar o desempenho em relação às visualizações em todas as versões. Para ver comparativos de mercado detalhados de inicialização e rolagem que comparam o Compose e as visualizações no app Pokedex de código aberto, consulte Comparativos de mercado Hero.

Instalação de perfil do Compose

Como o Jetpack Compose é uma biblioteca desagrupada, ele não se beneficia do Zygote, que pré-carrega as classes e os drawables do kit de ferramentas de interface do sistema de visualização. O Jetpack Compose usa a instalação de perfil para builds de lançamento. Os instaladores de perfil permitem que os apps especifiquem códigos essenciais para serem compilados com antecedência (AOT, na sigla em inglês) no momento da instalação. O Compose envia regras de instalação de perfil que reduzem o tempo de inicialização e a instabilidade nos apps dele.