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 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.
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 second (and final) stage was to migrate away from fragments, and use the Navigation Compose component directly. This was completed in this PR:
Migration to Navigation Compose by chrisbanes · Pull Request #761 · chrisbanes/tivi
This PR removes (nearly) all Fragments from Tivi*, and migrates everything to Compose Navigation. There are no…
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… 📊
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.
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
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.
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.2GHz
To prime all of the the remote artifact caches I then ran
To run the tests, I ran the following command 5 times in a loop:
./gradlew --profile \
--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.
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:
There are some caveats in all of the results above:
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.
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.
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.
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.