Jetpack Compose — Before and after
How the build speed, APK size and source line count changed after migrating the Tivi sample app to Jetpack Compose
This post has been updated since it was first published, to new include updated stats for Jetpack Compose 1.0.0–rc01. If you would like to see the original version of this post, see here.
In 2020, I began the task of slowly migrating the UI in Tivi to be written in Jetpack Compose, and roughly 12 months later it is now complete. 🎉
In this blog post, we’ll take a look back and compare a number of key metrics to see how well Compose compares in: APK size, build speed and lines of code.
The app
Before I go any further into the Compose side of things, let me quickly describe the app.
Tivi is pretty heavily modularized, with each UI ‘screen’ in its own Gradle module (named ui-$NAME). Each of those screens was implemented in a Fragment, and then pieced together using AndroidX Navigation in the main app module. To give you an idea of the structure, here’s a graph of the modules in the app:
Most of the fragments had no knowledge of each other, since the navigation graph was implemented using deep link URIs, ensuring decoupling. Perhaps more importantly, it also allows independent module compilation which aids build parallelism.
Note: the module structure of Tivi is not perfect by any means. There are too many dependencies of UI modules (at the top) to base modules (at the bottom). Ideally each layer should be seperated. Something for me to work on.
Before I started the migration to Compose, Tivi used all the cool 🌈 UI 💫 things available to Android developers: Data Binding, Epoxy, Material Design Components, Insetter DBX, MotionLayout to name a few. But unfortunately most of these came with a build cost since they use annotation processing.
Process of migrating
Earlier I mentioned that we had just completed the ‘first stage’ of the migration, so what do I mean by that? Well the app looks practically the same as when I started in Feb 2020.
The modularized nature of the app meant that the migration itself could be completed in pieces, one fragment at at a time, and that’s exactly what happened over the course of the past 11 months, covering 46 pull requests.
I started with a simple screen: Episode details, then migrated the Show details, then ‘Discover’, then ‘Search’, then ‘Followed shows’, etc. With the recent addition of Paging3 support for Compose, I could migrate the final screens: the ‘list’ grids:
The first stage of migration resulted in the app using Fragments and Navigation, with the UI of each fragment implemented via Jetpack Compose.
The second (and final) stage was to migrate away from fragments, and use the Navigation Compose component directly. This was completed in this PR:
It feels like a no-brainer to me that Compose is the future of UI development on Android.
So, let’s look at some metrics… 📊
Metrics
For each of the metrics below, we’re going to compare three different versions of the app:
- Pre-Compose. This is the commit before I landed the first PR adding Compose support to Tivi, back in February 2020.
- Fragments + Compose. This is based on the commit which marked the end of the first stage of migration. I have since branched and update it to use Jetpack Compose 1.0.0-beta05, AGP 7.0.0-alpha14, Gradle 7.0 and Kotlin 1.4.32, for direct comparison.
- Entirely Compose. This is using the current top-of-tree main commit. Tivi is completely Compose based (using 1.0.0-rc01), with no fragments in the app.
APK Size 🗜
The metric which your users will care the most about: APK size.
The following results are for the minified release APK (using R8) with resource shrinking enabled, measured using APK Analyzer.
Some notes about the numbers:
- We use the reported ‘APK file size’ (not download size) from APK Analyzer.
APK Size Analysis
When comparing the adjusted values vs ‘Pre-Compose’ we see a 46% reduction in APK size, and 17% reduction in method count when using Compose. 🤯
We see a 41% reduction in APK size, and 17% reduction in method count when using Compose
This number shows how little minification tools can help when you need to keep all View classes around, just in case they’re used from layout files.
Lines of code 📜
Now, I know that counting source lines of code isn’t a particularly useful statistic when comparing software projects, but it does provide an insight to how things are changing.
For this test I used the cloc tool, using the following command to exclude any build, generated and config files:
cloc . --exclude-dir=build,.idea,schemas
The cloc tool has built-in support for ignoring comments (although I didn’t verify this), so the results above are for actual ‘code’. Unsurprisingly the amount of XML lines decreased by a very large margin: 76%. Bye bye layout files, styles, themes and lots of other XML files. 👋
Also interesting is that the total lines in Kotlin went down too. My working theory for is that we now have less boilerplate in the app, and we were able to remove a lot of view helper & utility code. See this PR which removed nearly 3,000 lines which I’d written over the years:
Build speed ⏳
Build speed is a metric which developers care a lot about. Before starting this process, I had a feeling that removing lots of the annotation processors would help with the build speed, but I wasn’t sure by how much.
Test setup
Before I go any further, it’s important to know how I measured the numbers below. I followed a similar setup to Chris Horner when he measured build times on different CPUs.
The machine I tested on is a Lenovo P920 with 192GB RAM, and a very fast Xeon Gold 6154 CPU. Needless to say, this machine is not your typical developer setup, so to make the test more realistic I pinned the CPU to its minimum clock frequency:
# Use performance governor to allow tweaking of max freq
sudo cpupower frequency-set -g performance
# Set max frequency to CPU minimum: 1.2GHz
sudo cpupower frequency-set -u 1.2GHzTo prime all of the the remote artifact caches I then ran ./gradlew assembleDebug.
To run the tests, I ran the following command 5 times in a loop:
./gradlew --profile \
--offline \
--rerun-tasks \
--max-workers=4 \
assembleDebugThe
--max-workersisn’t strictly necessary, but Gradle will use all 64 ‘cores’ available on this CPU by default. Limiting to 4 is more comparable to typical laptop CPUs.
Results
You can see the test results below, using the ‘Total Build Time’ value from each resulting profile report.
This result surprised me quite a bit because the ‘Entirely Compose’ time is 25 seconds quicker than ‘Each fragment in Compose’. 🤔
Thanks to Ivan Gavrilović for working out why, and it wasn’t anything to do with Compose. ‘Entirely Compose’ is using the most recent version of Dagger/Hilt, which uses the new ASM API in Android Gradle Plugin 7.0. The other versions of the app used an older version of Hilt, which uses a different mechanism and results in dexing times to be sloowwww.
Taking a step back, a 29% decrease in build time is amazing when you think about everything which the Kotlin Compiler & Compose compiler plugin is doing for us now, such as positional memoization, and fine-grained recomposition. See this article from Leland for more information:
Caveats
There are some caveats in all of the results above:
Feature work
While I didn’t perform any major new feature work on Tivi during the 11 months, I didn’t particularly limit myself either. There are a number of changes I made which were not focused on the migration, and could skew the results.
Dependency updates
During the 11 months of migration, there were lots of dependency updates. Most of the dependency updates were runtime library dependencies, so most likely affect the APK Size metrics.
I also updated Gradle (from 6.0.1 to 7.1.1), the Android Gradle Plugin (3.6.0 to 7.1.0-alpha02) and Kotlin (1.3.61 to 1.5.10), all of which can have a large effect on build speed.
Compose is in beta
The obvious one. Compose is currently in beta so all of the results are from a snapshot in time whilst it is being developed. Once it hits 1.0 later this year, it will be interesting to re-run these tests and see if there are any differences.
Summary
If we look at the results and caveats we should not make too many judgements since we’re not comparing apples 🍎 to apples 🍏; it’s more like comparing apples 🍎 to their slightly sweeter cousin, pears 🍐.
Fruit analogies aside, I think the biggest takeaway for me is that Compose will have a positive (or neutral) effect on most developer metrics. With that in mind, along with the vastly increased developer productivity with Compose, it feels like a no-brainer to me that Compose is the future of UI development on Android.
