Define the two milestones
The startup guide distinguishes initial display and full display. Use the appropriate fully-drawn reporting mechanism when the meaningful content is ready; do not mark it merely when the activity begins.
Write down what “ready” means for your app: saved game restored, first list loaded or essential controls interactive.
Inspect startup work by necessity
| Work | Question |
|---|---|
| Dependency initialization | Is it needed before the first screen? |
| Database opening/migration | Can it block the main thread? |
| SDK startup | Can documented deferred initialization help? |
| Asset decode | Is the initial asset appropriately sized? |
| Network request | Can cached or recoverable UI appear first? |
Do not defer security or correctness checks that must precede a protected action just to improve a timing chart.
Measure the intended launch state
A cold launch, warm launch and return to an existing activity are different scenarios. Use Macrobenchmark with explicit startup mode and controlled setup rather than manually force-stopping inconsistently between runs.
Test a representative release/profileable build and keep compilation state documented.
Trace before restructuring
Look for long main-thread sections, synchronous disk reads and initialization chains. Removing one expensive startup dependency can be more effective than micro-optimizing a small view inflation step.
Verify the complete experience
Measure both the first frame and usable content, and test offline/error states. A faster blank screen is not a satisfactory result.
APKLint's Performance Checker can help organize startup review, but it does not measure launch time from an uploaded APK. Keep the benchmark output, trace and readiness definition with the release so future changes are compared against the same user experience.
Define readiness for a cached inbox
Consider an inbox app that can show saved messages before refreshing the network. Its initial display may be the first visible frame, while the meaningful ready state is a usable list or a deliberate empty/offline state. Define that second milestone explicitly and report it when the chosen condition is reached. Reporting fully drawn as soon as the activity is created would measure a different experience.
The startup-time guide distinguishes launch states and display milestones. Keep fresh installation, process-cold launch and return to an existing activity separate in test results. A first-run database migration or account setup can make one scenario materially different from everyday cold starts.
Remove work from the critical path without hiding it in the next tap
Suppose the startup trace shows a large report-export SDK initializing before the inbox appears. If export is unavailable until the user opens a later screen, evaluate the SDK's supported deferred initialization. Then measure that later screen too. Moving a long pause to the first export tap can be an acceptable explicit tradeoff or a new defect, depending on the product's response requirements.
Keep authentication and authorization checks before protected operations. Cached content should follow the product's account and privacy rules, including sign-out handling. A startup improvement must not display the previous account's messages merely because local data is faster than a fresh request. Test the account-switch path explicitly, including a cold launch after the previous account has signed out.
Use repeated runs on a representative release-like build with recorded compilation state, data and device conditions. Preserve traces for unusually slow iterations and inspect whether they share an initialization bottleneck. Test offline launch, an empty inbox, an expired session and a failed refresh so every readiness branch has a deliberate outcome. Compare both initial display and meaningful readiness after the change. If the first frame improves while usable content becomes slower, report both results. Keep the benchmark workload and readiness definition with the release so a future developer cannot appear to improve the metric merely by moving the fully-drawn signal earlier.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
