Compara las métricas de Compose y View

Jetpack Compose acelera el desarrollo de IU y mejora el desarrollo de Android. Sin embargo, ten en cuenta cómo 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 través de la app de ejemplo Sunflower, una app que demuestra las prácticas recomendadas para migrar una app basada en View a Compose.

Tamaño del APK

Agregar bibliotecas a tu proyecto aumenta el tamaño del 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, lo que representa un aumento de 782 KB. El APK generado consistía en la compilación de la IU con una combinación de objetos View y Compose. Este aumento es esperable, ya que se agregaron dependencias adicionales a Sunflower.

Por el contrario, cuando Sunflower se migró a una app exclusiva 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 sin usar, como AppCompat y ConstraintLayout.

Tiempo de compilación

Agregar Compose aumenta el tiempo de compilación de tu app, ya que el compilador de Compose procesa los elementos componibles de 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 se agregó 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 la eliminación de la vinculación de datos, la migración de dependencias que usan kapt a KSP y la actualización de varias dependencias a sus versiones más recientes.

Resumen

La adopción de Compose aumentará de manera efectiva el tamaño del APK de tu app y también mejorará el rendimiento del tiempo de compilación debido al proceso de compilación del código de Compose. Sin embargo, estas compensaciones deben sopesarse con los beneficios de Compose, especialmente en lo que respecta a los aumentos de productividad de los desarrolladores cuando se adopta 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 Adopt Compose for Teams.

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 cómo se compara Jetpack Compose con el rendimiento del sistema de View y cómo puedes medirlo.

Recomposiciones inteligentes

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

Perfiles de Baseline

Los perfiles de Baseline son una excelente manera de acelerar los recorridos comunes del usuario. 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 just-in-time (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 abarcar 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 a fin de 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 ayuda a limitar el seguimiento de estado explícito, las asignaciones de memoria y las devoluciones de llamada únicamente a los 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 realizar cambios.

Múltiples pases de diseño

Los ViewGroups tradicionales tienen mucha expresividad en sus APIs de medición y diseño, lo que 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 solo pase de diseño para todos los elementos componibles de diseño a través de su contrato de 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 mediciones 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.

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 obtener información sobre cómo usarla con Jetpack Compose, consulta el proyecto MacrobenchmarkSample.

El equipo de Jetpack Compose también usa Macrobenchmark para detectar cualquier regresión que pueda ocurrir. 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 del kit de herramientas de la IU del sistema de View. Jetpack Compose 1.0 utiliza la instalación de perfiles para compilaciones de versión. 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.