Every Android component (activities, broadcast receivers, etc) can be a start-up entry point for Chrome. The main start-up scenarios we optimize for are:
For a home screen launch, we consider start-up to be complete once the Activity is rendered. For the latter two, we care both about:
Here are some UMA metrics that measure start-up (UMA's UI has descriptions):
Startup.Android.Cold.TimeToFirstVisibleContent4
Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed
Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap
Startup.Android.Cold.TimeToFirstContentfulPaint3.Tabbed
This one can be useful for measuring dex optimization changes:
Startup.LoadTime.ProcessCreateToApplicationStart
For Googlers, there's more background in this doc.
Here are some chromeperf metrics that measure start-up in a lab environment:
ChromiumPerf/android-pixel4-perf/startup.mobile / messageloop_start_time
ChromiumPerf/android-pixel4-perf/startup.mobile / navigation_commit_time
ChromiumPerf/android-pixel4-perf/startup.mobile / first_contentful_paint_time
When using Pinpoint to test start-up changes, make sure to:
--browser=android-trichrome-chrome-google-bundle
--browser=android-trichrome-chrome-google-64-32-bundle
--compile-apk=speed
Some start-up changes can improve start-up for high-end devices but degrade it for low-end ones (or vice versa). It is important to test both.
For small regressions (e.g. ~1%), it can help to add --pageset-repeat 10
or --pageset-repeat 20
in order to increase the number of samples collected. A single repeat produces 8 samples, then Pinpoint normally runs it 10 times (total 80). With --pageset-repeat=20
the total number of samples is 1600.
android-go-*
devices to test low-end.android-pixel6-*
to test high-end. They set is_high_end_android=true
.