Define the user task and metric
Choose a task such as cold launch, scrolling a long list, loading a large PDF or completing a game level. Specify the beginning, end and success condition before collecting measurements.
The profiling guide distinguishes low-overhead profileable release testing from deeper debug-only inspection.
Build a practical matrix
| Dimension | Include |
|---|---|
| Hardware | Representative low, middle and high capability devices |
| Android version | Supported versions and behavior-change boundaries |
| Data | Empty, typical and largest supported inputs |
| Network | Controlled fast, slow and unavailable conditions |
| State | Cold start, warm state and restored session |
Not every combination needs equal frequency. Prioritize the population and failure modes that matter to the product.
Automate stable journeys
Use Macrobenchmark for supported end-to-end performance journeys. Keep compilation mode, app state and iteration setup explicit so results are comparable.
Do not compare debug and optimized release timings as though only one code change differed.
Measure distributions, not a lucky run
Repeat the workload, inspect variability and retain traces for unusually slow runs. Temperature, background activity and cache state can affect results.
Set a regression threshold appropriate to normal measurement noise. A tiny improvement smaller than the run-to-run variation is not convincing evidence.
Close the loop with production
Android vitals helps reveal device-specific and field failures that a laboratory matrix missed. Use those cohorts to improve the next test cycle.
APKLint's performance and release checkers can organize acceptance criteria and package inspection. They do not execute benchmarks, so a release decision should include actual measurements, the tested matrix and known untested conditions rather than a static checklist score alone.
Define when a search result is actually usable
For a search screen, choose a reproducible synthetic query and dataset. Define the start as the accepted search action and the finish as the correct result list becoming usable. A spinner disappearing before rows are bound is a different boundary. Keep the expected result count and content in the scenario so an empty fast result cannot pass as an improvement.
The Macrobenchmark guide describes repeatable app-level measurement. Use a release-like target and record setup, compilation mode and startup state. Avoid comparing a warmed development session with a freshly installed optimized build and attributing the difference solely to the changed code.
Control setup and inspect variability
Reset or retain cache state deliberately between iterations according to the question. If measuring first-use search, prepopulated results undermine the scenario. If measuring repeat search, clearing everything before every run measures a different experience. Record the chosen state rather than describing both as search speed.
Run enough controlled repetitions to understand ordinary variation and retain the distribution. Investigate unusually slow runs using traces instead of discarding them automatically. Thermal state, competing activity and input preparation can explain a difference that an average conceals.
Add a second query with a different result shape and a no-result case. Performance repairs must preserve behavior when the list is large, empty or replaced by a later request. If cancellation is supported, confirm that a canceled earlier query cannot overwrite the newer result.
Repeat the meaningful scenario on a representative lower-capability device. A flagship device can hide allocation or rendering costs that affect the intended audience. Keep the scope practical by selecting known boundaries and affected cohorts rather than running every conceivable combination without a clear question.
Report before-and-after values with the build identities, dataset and measurement boundary. Treat small changes within ordinary noise cautiously. Once the evidence supports a repair, retain the scenario and a suitable regression threshold so future changes can be compared under the same conditions.
Keep fixture preparation outside the measured interval unless preparation itself belongs to the user task. Record that distinction so a faster test-data loader is not mistakenly reported as a faster search implementation.
Sources and further reading
- Android Developers: Profile your app performance
- Android Developers: Macrobenchmark
- Android Developers: Android vitals
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
