Jetpack Compose before and after use

In order to include the updated content of Jetpack Compose 1.0.0-beta05, this article was updated after the first publication. If you want to see original version , please click here .

In 2020, I started the Tivi UI, the goal is to make it be written by Jetpack Compose . After about 12 months, the task is complete! 🎉

In this article, we will review and compare some key indicators to understand Compose's relative advantages, including: APK size, build speed, and number of lines of code.

application itself

Before we learn more about Compose, let me quickly describe the application itself.

Tivi has been highly modularized, each of its UI interface is in its own Gradle module (named ui-$NAME). Each interface is Fragment AndroidX Navigation is used in the main app module to combine them. In order to give you an intuitive impression of the architecture, the following is a block diagram of the application:

△ Tivi module diagram, using Jake Wharton provided, very convenient Gradle task generated

Since the navigation map is implemented using the deep link URI , most fragments know nothing about each other, thus ensuring decoupling. Perhaps more importantly, this form supports independent module compilation, which facilitates parallel construction.

Note : The module structure of Tivi is not perfect. Among them, there are still many dependencies between the UI module (located at the top level) and the basic module (located at the bottom level). Ideally, each level should be kept separate. My next job is to optimize this problem.

Before starting to migrate to Compose, Tivi has used all the cool UI components that Android developers can use, including but not limited to: Data Binding 、 Epoxy 、 Material Design Components 、 Layout DBe 1601e55806698 . Unfortunately, many of these components use annotation processing, which also brings additional construction costs.

Migration process

I mentioned earlier that we have completed the "first act" of the migration. What does this mean? The app now looks the same as when I started the migration in February 2020.

The modularity of the application means that it can be migrated in fragments, and only one fragment is migrated at a time—and this is what has been 46 pull requests in the past 11 months.

I started the migration from a simple interface: episode details show details , " found ", " search ", " followed performance " and so on. Recently, after Paging3 supported Compose , I migrated the final interface: "List" grid:

△ Before and after the migration, the effect of the video displayed in Tivi

The first stage of application migration used Fragments and Navigation , and the UI of each Fragment was implemented using Jetpack Compose.

The second (and final) stage is to move out from Fragment and use Navigation Compose component . This step is done in PR .

migration process is easy for me, and there is no doubt that Compose is the future of Android UI development.

Next, let’s take a look at the specific indicators... 📊

indicator

For each of the following indicators, we have compared three different versions of the application:

1. access Compose before : Back in February 2020, which I add Comepse support for Tivi first PR release before of submit .
2. Fragments + Compose submission on which this version is based is marked as the end of the first phase of the migration. I checked out the new branch and updated Jetpack Compose to 1.0.0-beta05, AGP to 7.0.0-alpha14, Gradle to 7.0, and Kotlin to 1.4.32 to reduce uncertainties in the comparison. You can see the relevant code branch
3. fully integrated into Compose : This version uses the latest main submission . At this time, Tivi is completely based on Compose (version 1.0.0-beta05), and there is no Fragment in the entire application.

APK size reduction 🗜

The metric that your users care most about is the APK size.

Below is opened resource reduction minimize release of APK (using R8) by APK Analyzer results measured:

△ A chart showing the size of Tivi APK

△ A chart showing the number of Tivi methods

of the above numbers:

• We used the APK Analyzer (not the size at the time of download).

APK size analysis

After comparing the migrated application with the application before connecting to Compose, we found that the APK size has been reduced by 41% and the number of methods has been reduced by 17% .

After using Compose, we found that the APK size has been reduced by 41% and the number of methods has been reduced by 17%

This figure shows that when you need to keep all the View classes in case you need to use them in the layout file, the compression tool is very limited.

Number of lines of code 📜

I know that when comparing software projects, calculating the number of source code lines is not a particularly useful statistical method; but this method can provide a perspective to help us understand how things change.

For testing, I used the cloc tool. Use the following commands to exclude various build files, auto-generated files, and configuration files.

cloc . --exclude-dir=build,.idea,schemas

△ A chart showing the number of lines of Tivi source code

cloc built-in support for ignoring comments (although I did not verify it), so the above results are applicable to the actual "code". Not surprisingly, the number of XML rows has been significantly reduced by 76% . Goodbye, layout files, and other XML files like styles, themes, etc.👋.

Interestingly, the total number of lines of Kotlin code has also dropped. My understanding of this phenomenon is that the template code in the application has been reduced, and we have also been able to remove a large amount of view auxiliary and tool code. As you can see, I this PR removed nearly written over the years in 3,000 lines of code.

Build speed ⏳

Build speed is an indicator that developers are very concerned about. Before starting the process, I think removing a lot of annotation processors will help speed up the build, but I'm not sure how much it can improve.

Test setup

Before proceeding to the next step, it is important to know how I measured the numbers below. I followed a similar with 160e5580669efc Chris Horner measuring different CPU build time .

I tested it on a Lenovo P920, which has 192GB RAM and a very fast Xeon Gold 6154 CPU. Needless to say, I know that this machine is not the usual configuration of the developer, so in order to make the test as realistic as possible, I fixed the CPU at its minimum clock frequency:

# 使用调频器的 performance 调速器来更改最大运行频率
sudo cpupower frequency-set -g performance
# 将最大频率设定为 CPU 的最低值：1.2GHz
sudo cpupower frequency-set -u 1.2GHz

In order to prepare all the remote cache files, I then ran ./gradlew assembleDebug .

To perform the test, I ran the following commands five times in a loop:

./gradlew --profile \
          --offline \
          --rerun-tasks \
          --max-workers=4 \
          assembleDebug

does not necessarily need to configure --max-workers here, but if it is not set here, Gradle will use all the 64 cores available by default for the CPU. Limited to 4 CPUs closer to a typical notebook computer.

result

You can see the results below, each result uses the "Total Build Time" value in the results report.

△ A chart showing the median build time of Tivi

This result is a little surprising to me, because "Full access to Compose" is 25 seconds faster than "using Compose in each Fragment".

Thanks Ivan Gavrilović finding out why. This phenomenon has nothing to do with Compose. "Full access to Compose" uses the latest version of Dagger/Hilt, which uses the new ASM API in Android Gradle Plugin 7.0. Other versions use the older Hilt version, which uses a different mechanism, which will seriously slow down the time to generate the dex file.

To say the least, considering the Kotlin compiler and Compose compiler plugin to do the things we like the location of the memory, fine-grained restructuring work, build time can reduction% 29, can be very alarming. You can check our published article to learn more:

• depth detailed explanation of Jetpack Compose | Optimized UI to build
• depth detailed explanation of Jetpack Compose | Implementation Principle

Note

Regarding all the results above, there are a few things to note:

related to new features

In these 11 months, I have not carried out major new feature development on Tivi, but I have not deliberately restricted myself. I have made many changes that are not related to migration, which may bias the results.

dependency update

During the 11 months of migration, many dependencies have been updated. Most of them are runtime-dependent libraries, so they are most likely to affect the APK size indicator.

I have also updated Gradle (from 6.0.1 to 7.0.0), Android Gradle Plugin (3.6.0 to 7.0.0-alpha14) and Kotlin . All may significantly affect the construction speed.

Compose is still in beta stage

This is most obvious. Compose is still in the beta stage, so all results are from a timely snapshot of the development process. When you reach version 1.0 later this year, you can rerun these tests and compare the differences.

summary

If we look at the results and precautions, we should notice that we are not comparing 🍎 with 🍏, but more like comparing 🍎 with relatives who are sweeter than it, so we should not make too much Evaluation.

Putting the fruit analogy aside, I think the biggest gain for me is that Compose has a positive (or neutral) impact on most developer metrics. With this in mind, coupled with the fact that Compose has greatly improved the productivity of developers, to me, Compose is undoubtedly the future of Android UI development.

Thanks to Nick Butcher, Jose Alcérreca and Jolanda Verhoef.