A startup optimization feels faster on your phone. How would you prove it?

Answer

Define what became faster. The first frame, a usable lesson list, and restored user progress can arrive at different times. An early empty shell may improve one metric without improving the actual journey.

Measurement plan

Use Macrobenchmark with a suitable non-debuggable, profileable target build. Choose cold, warm, or hot startup based on the hypothesis and keep compilation conditions consistent. Repeat measurements on physical hardware under controlled conditions; record device, build, data fixture, and network assumptions.

Compare distributions and inspect traces for slow runs. A single best run hides noise and outliers. If network content determines readiness, use a controlled response for the benchmark and separately evaluate real network behavior.

Example hypothesis

“Deferring an unused analytics dependency should remove its initialization from the critical path.” A trace should show that work moved, while the first useful screen and later interaction remain correct. Check that deferred work does not simply cause a large pause on the user's first tap.

Follow-up to practise

Is time to initial display sufficient? Not when the first frame is just a loading placeholder. Define fully drawn readiness carefully, report it consistently, and include the state users need to act. Avoid moving the reporting call earlier merely to improve a number.

Reference

Android Developers: Write a Macrobenchmark