Android: Baseline profile generation

[t895]

Here's the documentation for Baseline Profiles

This creates a new benchmark module that is responsible for generating baseline profiles and testing them. As part of this commit, an automatically generated baseline-prof.txt file has been included to speed up launch times with the app in its current state. Later, profile generation can be automated by the buildbot and keep up with the app as it changes.

Currently we only have the ability to generate the profile for activities that are reachable without having games available. The only other way to do this is having a rooted physical device with several manual steps. That is not ideal. Right now profiles are generated using the gradle managed devices feature.

Running this command in the Android directory will download an android device image and run the generate() method in BaselineProfileGenerator.kt
./gradlew :benchmark:pixel2Api31BenchmarkAndroidTest -P android.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile

Once the build has completed, a profile will be copied into Android/benchmark/build/outputs/managed_device_android_test_additional_output/pixel2Api31/BaselineProfileGenerator_generate-baseline-prof.txt

This has to be renamed to "baseline-prof.txt" and placed into the "main" folder of the app module.

StartupBenchmark.kt was used to generate the following results (9.85% reduction in startup time!) -

Without baseline profile
min - 939ms
median - 964ms
max - 1006ms

With baseline profile
min - 830ms
median - 869ms
max - 937ms

Benchmarking setup -
I used the Shield TV, installed the benchmark build, and ran the startupBaselineProfileDisabled() test. Make sure to uninstall and reinstall the app before running the startupBaselineProfile() test.
Additionally, both tests have one warmup iteration to discard our first startup time where we copy a bunch of files.

Note -
Tests only can be run using the new "benchmark" build variant of the app. This is made to closely follow the release variant but not require keys for easy local testing.

This inadvertently adds Kotlin support to the app and we now have access to Macrobenchmarks!

[JosJuice]

Kind of ambivalent about adding 4000 lines to shave off 100 ms, but if others think that 100 ms improvement is important enough, I wouldn't be against merging this.

[t895]

Kind of ambivalent about adding 4000 lines to shave off 100 ms, but if others think that 100 ms improvement is important enough, I wouldn't be against merging this.

It seems a little silly but as the app uses more UI libraries in the future, (Jetpack Compose) the gains will increase

[JosJuice]

So... That means that Jetpack Compose adds a lot of additional startup time? If so, what are the advantages to Jetpack Compose that would make it worth using? (Not very familiar with it)

[t895]

So... That means that Jetpack Compose adds a lot of additional startup time? If so, what are the advantages to Jetpack Compose that would make it worth using? (Not very familiar with it)

Much less code, easier to use APIs (Ex. no more weird workarounds for things like closing the virtual keyboard), and generally is the standard for UI code going forward. There's also a number of APIs that are exclusive to using Kotlin and Compose together

[JosJuice]

I'll trust you on this one since your work so far has shown that you know more about Android frontend development than me.