Choose an externally observable journey
Use the Macrobenchmark guide to configure the benchmark module, target package and supported build. Select a journey with a clear start, action and completion condition.
Avoid benchmarking a debug build and presenting the result as production performance. The profiling guide explains release/profileable versus debuggable trade-offs.
Control state explicitly
| Variable | Record or control |
|---|---|
| Startup mode | Cold, warm or hot as appropriate |
| Compilation mode | Same intended mode across comparisons |
| Data and account | Stable seeded test state |
| Network | Controlled or documented conditions |
| Device | Same model, software and thermal state |
A benchmark that waits on an unpredictable production endpoint can measure server variation rather than your code change.
Make the test wait for real readiness
Use stable UI selectors and meaningful completion conditions. A fixed sleep can either waste time or finish before a slow device is ready, producing inconsistent results.
Keep test-only data and accounts isolated from real users and production transactions.
Inspect traces as well as summaries
A regression summary tells you that performance changed; a trace helps explain where. Retain representative slow iterations instead of discarding them as inconvenient outliers without investigation.
Compare distributions and normal noise before declaring a small difference meaningful.
Use benchmarks as release evidence
Add the journey to a repeatable review or CI process where hardware conditions can be managed. APKLint's Performance Checker can help define the scenario and acceptance questions, but it does not run Macrobenchmark. A defensible result includes the test code, target artifact, environment and measured output, with any uncontrolled variables clearly stated.
Define the scroll journey before measuring it
Suppose the benchmark evaluates a feed with image thumbnails. Seed a fixed feed, launch the intended screen, wait for the list's ready marker and perform a repeatable scroll distance. Decide whether image cache population belongs in setup or measurement. A warm-cache run and a cold-cache run answer different questions, so label them separately instead of averaging them together.
Use the Macrobenchmark setup guide to prepare a supported non-debuggable, profileable target close to the release configuration. Preserve optimization and dependencies representative of production. Benchmark warnings about the environment need investigation; suppressing them merely to obtain a number does not remove the measurement limitation.
Treat an incomplete journey as a test failure
If the feed never becomes ready, fail with a useful diagnostic instead of timing an empty screen. If a selector matches an unexpected login button or a recycled item, correct the test's state and selector before interpreting its frame metric. Keep the completion condition tied to the user-visible behavior being evaluated.
Run old and new candidates under comparable device and thermal conditions. Record any uncontrolled service dependency and use a controlled fixture where the question concerns local rendering. Retain per-iteration outputs and representative traces, especially when one candidate's average looks better but its slowest interactions worsen. If the device becomes hot during repeated runs, allow conditions to stabilize and document the interruption. Otherwise, test order can be mistaken for an implementation difference.
When a regression appears, identify the affected trace region before rewriting layouts. It might be image decode, a main-thread sort, a lock wait or an expensive state update. Change the supported cause and rerun the same journey; changing both the workload and implementation prevents a clean comparison. Keep the benchmark module and seeded data version with the result so another machine can reproduce the procedure on suitable hardware. A local benchmark supports a claim about that workload and environment, while production monitoring checks whether the change benefits the broader user population. Static APK inspection can help identify configuration, but it cannot replace the measured run or establish its timing.
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
