Jetpack Compose accelerates UI development and improves Android development. However, take into consideration how adding Compose to an existing app can affect metrics such as an app's APK size, build, and runtime performance.
APK size and build times
This section goes over the impact to APK size and build time by looking at the Sunflower sample app—an app that demonstrates best practices with migrating a View-based app to Compose.
Adding libraries to your project increases its APK size. The following results are for the minified release APK of each project with resource and code shrinking enabled, using R8 full mode, and measured using APK Analyzer.
|Mixed Views and Compose
When first adding Compose to Sunflower, the APK size increased from 2,252 KB to 3,034 KB—a 782 KB increase. The generated APK consisted of the UI build with a mix of Views and Compose. This increase is to be expected as additional dependencies were added to Sunflower.
Conversely, when Sunflower was migrated to a Compose-only app, the APK size
decreased from 3,034 KB to 2,966 KB—a 68 KB decrease. This decrease was due
to removing unused View dependencies, such as
Adding Compose increases the build time of your app as the Compose compiler
processes composables in your app. The following results were obtained using the
gradle-profiler tool, which executes a build several times so
that a mean build time can be obtained for the debug build duration of
gradle-profiler --benchmark --project-dir . :app:assembleDebug
|Mixed Views and Compose
|Mean build time
When first adding Compose to Sunflower, the mean build time increased from 299 ms to 399 ms—a 100 ms increase. This duration is due to the Compose compiler performing additional tasks to transform Compose code defined in the project.
Conversely, the mean build time dropped to 342 ms, a 57 ms decrease, when Sunflower's migration to Compose was completed. This reduction can be attributed to several factors which collectively reduce build time such as removing data binding, migrating dependencies that use kapt to KSP, and updating several dependencies to their latest versions.
Adopting Compose will effectively increase the APK size of your app and also increase the build time performance of your app due to the compilation process of Compose code. These tradeoffs, however, need to be weighed against the benefits of Compose, especially around developer productivity increases when adopting Compose. For example, the Play Store team found that writing UI requires much less code, sometimes up to 50%, thereby increasing productivity and maintainability of code.
You can read more case studies in Adopt Compose for Teams.
This section covers topics related to runtime performance in Jetpack Compose to help understand how Jetpack Compose compares to the View system's performance, and how you can measure it.
When portions of the UI are invalid, Compose tries to recompose just the portions that need to be updated. Read more about this in the Lifecycle of composables and Jetpack Compose phases documentation.
Baseline Profiles are an excellent way of speeding up common user journeys. Including a Baseline Profile in your app can improve code execution speed by about 30% from the first launch by avoiding interpretation and just-in-time (JIT) compilation steps for included code paths.
The Jetpack Compose library includes its own Baseline Profile and you automatically get these optimizations when you use Compose in your app. However, these optimizations only affect code paths within the Compose library, so we recommend that you add a Baseline Profile to your app to cover code paths outside of Compose.
Comparison with the View system
Jetpack Compose has many improvements over the View system. These improvements are described in the following sections.
Everything extends View
View that draws on the screen, such as
ImageView, requires memory allocations, explicit state tracking, and various
callbacks to support all use cases. Furthermore, the custom
View owner needs
to implement explicit logic to prevent redrawing when it isn't
necessary—for example, for repetitive data processing.
Jetpack Compose addresses this in a few ways. Compose doesn't have explicit
updatable objects for drawing views. UI elements are simple composable functions
whose information is written to the composition in a replayable way. This helps
cut down explicit state tracking, memory allocations, and callbacks to only the
composables that require said features instead of requiring them by all
extensions of a given
Furthermore, Compose provides smart recompositions, replaying the previously drawn result if you don't need to make changes.
Multiple layout passes
Traditional ViewGroups have a lot of expressiveness in their measure and layout APIs that make them prone to multiple layout passes. These multiple layout passes can cause exponential work if done at specific nested points in the view hierarchy.
Jetpack Compose enforces a single layout pass for all layout composables via its API contract. This lets Compose efficiently handle deep UI trees. If multiple measurements are needed, Compose has intrinsic measurements.
View startup performance
The View system needs to inflate XML layouts when showing a particular layout for the first time. This cost is saved in Jetpack Compose since layouts are written in Kotlin and compiled like the rest of your app.
In Jetpack Compose 1.0, there are notable differences between the performance of
an app in
release modes. For representative timings, always
release build instead of
debug when profiling your app.
Compose profile installation
Since Jetpack Compose is an unbundled library, it doesn't benefit from Zygote that preloads the View system's UI Toolkit classes and drawables. Jetpack Compose 1.0 utilizes profile installation for release builds. Profile installers let apps specify critical code to be ahead-of-time (AOT) compiled at installation time. Compose ships profile installation rules which reduce startup time and jank in Compose apps.