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

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

Tempos de compilação e tamanho do APK

Esta seção aborda o impacto no tamanho do APK e no tempo de build analisando o app de exemplo Sunflower, um app que demonstra as práticas recomendadas para migrar um app baseado em visualização para o Compose.

Tamanho do APK

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

Somente visualizações Visualizações e Compose em conjunto Somente Compose
Tamanho do download 2.252 KB 3.034 KB 2.966 KB

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 no build da interface com uma combinação de visualizações e do Compose. Esse aumento é esperado à medida que outras dependências foram adicionadas ao Sunflower.

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

Tempo de compilação

A adição do Compose aumenta o tempo de build do app, já que o compilador do Compose processa os elementos combináveis no app. Os resultados abaixo foram recebidos usando a ferramenta autônoma gradle-profiler, que executa um build várias vezes para que um tempo médio de build possa ser recebido para a duração do build de depuração do Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Somente visualizações Visualizações e Compose em conjunto Somente Compose
Tempo médio de build 299,47 ms 399,09 ms 342,16 ms

Ao adicionar o Compose ao Sunflower pela primeira vez, o tempo médio de build aumentou de 299 ms para 399 ms, um aumento de 100ms. Essa duração se deve ao fato de o compilador do Compose executar outras tarefas 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 reduzem coletivamente o tempo de build, como a remoção da vinculação de dados, a migração de dependências que usam kapt para KSP e a atualização de várias dependências para as versões mais recentes.

Resumo

A adoção do Compose aumenta efetivamente o tamanho do APK do app e também o desempenho do tempo de build devido ao processo de compilação do código do Compose. No entanto, essas compensações precisam ser comparadas aos benefícios do Compose, principalmente em relação ao aumento da produtividade do desenvolvedor ao adotar o Compose. Por exemplo, a equipe da Play Store descobriu que programar a interface requer muito menos código, às vezes até 50%, aumentando a produtividade e a manutenção do código.

Leia mais estudos de caso em Adotar o Compose for Teams.

Desempenho em tempo de execução

Esta seção aborda tópicos relacionados ao desempenho do ambiente 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 é possível medi-lo.

Recomposições inteligentes

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

Perfis de referência

Os perfis de referência são uma excelente maneira de acelerar jornadas comuns do usuário. A inclusão de um perfil de referência no app pode melhorar a velocidade de execução do 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 um perfil de referência próprio, e você recebe essas otimizações automaticamente quando usa o Compose no app. No entanto, essas otimizações só afetam caminhos de código na biblioteca Compose. Portanto, recomendamos que você adicione um perfil de referência ao app para cobrir 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 da View personalizada precisa implementar uma lógica explícita para evitar um redesenho quando não for necessário, por exemplo, para processamento de dados repetitivo.

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 simples que podem ser compostas, cujas informações são gravadas na composição de forma reproduzível. Isso ajuda a reduzir o rastreamento explícito de estado, as alocações de memória e os callbacks para apenas os elementos combináveis que exigem esses recursos, em vez de exigir que eles sejam usados por todas as extensões de um determinado tipo de View

Além disso, o Compose oferece recomposições inteligentes, repetindo o resultado renderizado anteriormente, caso você não precise fazer mudanças.

Várias transmissões de layout

As ViewGroups tradicionais têm muita expressividade nas APIs de medida e layout, o que os torna propensos a várias transmissões 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 transmissão de layout a todos os elementos combináveis de layout usando o contrato da API. Isso permite que o Compose processe árvores de interface profundas com eficiência. Caso várias medições sejam 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 é salvo no Jetpack Compose, já que os layouts são escritos em Kotlin e compilados da mesma forma que o restante do app.

Comparar o Compose

No Jetpack Compose 1.0, 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 conferir o desempenho do código do Jetpack Compose, use a biblioteca Jetpack Macrobenchmark. Para aprender a usar com o Jetpack Compose, consulte o projeto MacrobenchmarkSample.

A equipe do Jetpack Compose também usa a Macrobenchmark para capturar regressões que possam acontecer. Por exemplo, consulte a comparação de colunas lentas e o painel para rastrear regressões.

Instalação de perfil do Compose

Como o Jetpack Compose é uma biblioteca desagrupada, ele não se beneficia do Zygote (link em inglês), que pré-carrega as classes e os drawables do kit de ferramentas de interface do sistema de visualização. O Jetpack Compose 1.0 utiliza a instalação de perfil para builds de lançamento. Os instaladores de perfil permitem que os apps especifiquem o código essencial que será compilado 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.