docs/speed/startup/android_startup.md
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.TimeToFirstVisibleContent4Startup.Android.Cold.TimeToFirstNavigationCommit3.TabbedBrowser.PaintPreview.TabbedPlayer.TimeToFirstBitmapStartup.Android.Cold.TimeToFirstContentfulPaint3.TabbedThis one can be useful for measuring dex optimization changes:
Startup.LoadTime.ProcessCreateToApplicationStartFor 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_timeChromiumPerf/android-pixel4-perf/startup.mobile / navigation_commit_timeChromiumPerf/android-pixel4-perf/startup.mobile / first_contentful_paint_timeWhen 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=speedSome 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.