Compara las métricas de Compose y View

Jetpack Compose acelera el desarrollo de la IU y mejora el desarrollo de Android. Sin embargo, ten en cuenta que agregar Compose a una app existente puede afectar métricas como el tamaño del APK, la compilación y el rendimiento del tiempo de ejecución de la app.

Tamaño del APK y tiempos de compilación

En esta sección, se analiza el impacto en el tamaño del APK y el tiempo de compilación a partir de la app de ejemplo Sunflower, una app que demuestra las prácticas recomendadas para migrar una app basada en objetos View a Compose.

Tamaño del APK

La adición de bibliotecas a tu proyecto aumenta su tamaño de APK. Los siguientes resultados son de la versión reducida del APK de cada proyecto con la opción de reducción de recursos y código habilitada. Además, se usó el modo completo de R8 y se realizaron las mediciones con el Analizador de APK.

Cuando se agregó Compose a Sunflower por primera vez, el tamaño del APK aumentó de 2,252 KB a 3,034 KB, un aumento de 782 KB. El APK generado consistía en la compilación de la IU con una combinación de Views y Compose. Se espera este aumento, ya que se agregaron dependencias adicionales a Sunflower.

Por el contrario, cuando Sunflower se migró a una app solo de Compose, el tamaño del APK disminuyó de 3,034 KB a 2,966 KB, una disminución de 68 KB. Esta disminución se debió a la eliminación de dependencias de View que no se usaban, como AppCompat y ConstraintLayout.

Tiempo de compilación

Si agregas Compose, se aumenta el tiempo de compilación de tu app, ya que el compilador de Compose procesa los elementos componibles en tu app. Los siguientes resultados se obtuvieron con la herramienta independiente gradle-profiler, que ejecuta una compilación varias veces para que se pueda obtener un tiempo de compilación promedio para la duración de la compilación de depuración de Sunflower:

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

Cuando agregaste Compose a Sunflower por primera vez, el tiempo de compilación promedio aumentó de 299 ms a 399 ms, un aumento de 100 ms. Esta duración se debe a que el compilador de Compose realiza tareas adicionales para transformar el código de Compose definido en el proyecto.

Por el contrario, el tiempo de compilación promedio disminuyó a 342 ms, una disminución de 57 ms, cuando se completó la migración de Sunflower a Compose. Esta reducción se puede atribuir a varios factores que, en conjunto, reducen el tiempo de compilación, como quitar la vinculación de datos, migrar dependencias que usan kapt a KSP y actualizar varias dependencias a sus versiones más recientes.

Resumen

Si adoptas Compose, aumentarás de manera efectiva el tamaño del APK de tu app y también el rendimiento del tiempo de compilación debido al proceso de compilación del código de Compose. Sin embargo, estas compensaciones deben compararse con los beneficios de Compose, en especial en relación con los aumentos de productividad de los desarrolladores cuando adoptan Compose. Por ejemplo, el equipo de Play Store descubrió que escribir la IU requiere mucho menos código, a veces hasta un 50%, lo que aumenta la productividad y la capacidad de mantenimiento del código.

Puedes leer más casos de éxito en Adopta Compose para equipos.

Rendimiento del tiempo de ejecución

En esta sección, se cubren temas relacionados con el rendimiento del tiempo de ejecución en Jetpack Compose para ayudarte a comprender la diferencia en el rendimiento entre Jetpack Compose y el sistema de View, y cómo puedes medirlo.

Recomposiciones inteligentes

Cuando algunas partes de la IU no son válidas, Compose intenta reescribir las partes que deben actualizarse. Obtén más información sobre esto en la documentación del ciclo de vida de los elementos componibles y de las fases de Jetpack Compose.

Perfiles de Baseline

Los perfiles de Baseline son una manera excelente de acelerar los recorridos comunes de los usuarios. Incluir un perfil de Baseline en tu app puede mejorar la velocidad de ejecución del código en aproximadamente un 30% desde el primer lanzamiento, ya que evita la interpretación y los pasos de compilación justo a tiempo (JIT) para las instrucciones de código incluidas.

La biblioteca de Jetpack Compose incluye su propio perfil de Baseline y obtienes estas optimizaciones automáticamente cuando usas Compose en tu app. Sin embargo, estas optimizaciones solo afectan las instrucciones de código dentro de la biblioteca de Compose, por lo que te recomendamos que agregues un perfil de Baseline a tu app para cubrir las instrucciones de código fuera de Compose.

Comparación con el sistema de View

Jetpack Compose tiene muchas mejoras en comparación con el sistema de View. Estas mejoras se describen en las siguientes secciones.

Todo supera a View

Cada View que se muestra en la pantalla, como TextView, Button o ImageView, requiere asignaciones de memoria, seguimiento de estado explícito y varias devoluciones de llamada para admitir todos los casos de uso. Además, el propietario de la View personalizada debe implementar una lógica explícita para evitar el rediseño innecesario, como en el procesamiento repetitivo de datos.

Jetpack Compose lo soluciona de varias maneras. Compose no tiene objetos que se puedan actualizar de forma explícita para dibujar vistas. Los elementos de la IU son funciones simples que admiten composición cuya información se escribe en la composición de manera reproducible. Esto limita el seguimiento de estado explícito, las asignaciones de memoria y las devoluciones de llamada únicamente a elementos componibles que requieren esas funciones, en lugar de usarlos para todas las extensiones de un tipo de View determinado.

Además, Compose ofrece recomposiciones inteligentes, que reproducen el resultado obtenido anteriormente si no necesitas hacer cambios.

Múltiples pases de diseño

Los ViewGroups tradicionales tienen mucha expresividad en sus APIs de medición y diseño, lo cual los hace propensos a varios pases de diseño. Realizar varios pases de diseño puede agregar más trabajo si se realizan en ciertos puntos anidados de la jerarquía de vistas.

Jetpack Compose aplica un pase de diseño único para todos los elementos componibles de diseño a través del contrato de la API. Esto permite que Compose procese de manera eficiente los árboles detallados de la IU. En caso de que se necesiten varias mediciones, Compose tiene medidas intrínsecas.

El rendimiento del inicio de View

El sistema de View debe aumentar los diseños XML cuando muestra un diseño en particular por primera vez. Con Jetpack Compose, te ahorras este paso, dado que los diseños están escritos en Kotlin y se compilan como el resto de tu app.

Cómo realizar comparativas de Compose

En Jetpack Compose 1.0, existen diferencias notables entre el rendimiento de una app en los modos debug y release. Para los tiempos representativos, siempre usa la compilación de release en lugar de debug cuando generes perfiles de tu app.

Para verificar el rendimiento de tu código de Jetpack Compose, puedes usar la biblioteca de Jetpack Macrobenchmark. Para aprender a usarlo con Jetpack Compose, consulta el proyecto de MacrobenchmarkSample.

El equipo de Jetpack Compose también usa Macrobenchmark para detectar regresiones que puedan producirse. Por ejemplo, consulta la comparativa de columnas diferidas y su panel para realizar un seguimiento de las regresiones.

Instalación de perfiles de Compose

Debido a que Jetpack Compose es una biblioteca sin empaquetar, no se beneficia de Zygote, que precarga las clases y los elementos de diseño que pertenecen al kit de herramientas de la IU del sistema de View. Jetpack Compose 1.0 usa la instalación de perfiles para compilaciones de lanzamiento. Los instaladores de perfiles permiten que las apps especifiquen código fundamental que se compilará con anticipación (AOT) durante la instalación. Compose envía las reglas de instalación del perfil que reducen los tiempos de inicio y los bloqueos en las apps de Compose.