Mobile performance testing checks how quickly and reliably an application helps users complete tasks with limited device resources. A product may return correct responses yet start slowly, stutter while scrolling, overheat the phone, or close after a few transitions.
Connect measurements to user scenarios. Megabytes and milliseconds become useful when the device, application activity, and acceptable result are known.
What to measure
Client performance includes startup, screen readiness, input response, smoothness, CPU, memory, network, storage, and energy consumption. Assess stability separately: crashes, hangs, and termination under resource pressure.
This complements server load testing. A fast API does not guarantee a fast screen if the client slowly parses data, decodes images, or blocks its main thread. Conversely, a slow backend may account for most waiting while the client behaves correctly.
Define criteria before execution
Replace “it should be fast” with a scenario, device, conditions, and measurement boundary. A team might set an internal target from launch to a usable cart on a chosen phone. That is a product criterion rather than a universal application standard.
Agree on repetitions, data preparation, and comparison with the previous build. Thresholds without measurement methods invite disputes because testers can time different events and both believe they are correct.
Startup: first frame and useful readiness
Distinguish cold starts, returning to an existing process, and state restoration. Android distinguishes TTID, time to initial display, from TTFD, time to full display. A polished splash screen does not establish readiness for interaction.
First launch after installation may perform special setup. Measure it separately to avoid mixing onboarding and migration with typical daily use.
Preparing a repeatable environment
Use a suitable physical device, fixed OS and build, identical data, and network conditions. Account for battery charge, temperature, power saving, free storage, and background processes. Comparing a hot phone with a cool one without documenting the difference is invalid.
Final comparisons need an agreed user-representative configuration. Debug builds and attached debuggers can affect performance. Detailed profiling helps explain causes but also adds overhead.
Practical example: a catalog regression
Suppose scrolling becomes noticeably worse after a catalog update. Separate client changes from an unrelated slow server response.
- 1.Prepare the same catalog and device. Record initial conditions and previous and new build numbers.
- 2.On the previous build, follow a fixed path: launch, open a category, load the list, and perform the same scrolling sequence.
- 3.Record readiness time, frame profile, and observed behavior. Repeat the agreed number of times.
- 4.Repeat on the new build with identical data, network, and cache preparation.
- 5.Compare result distributions, then profile the problematic section. One hypothesis is that image decoding during scrolling interferes with frame processing.
- 6.After the fix, repeat the same scenario. Expect the criterion to pass without worsening memory, image quality, or loading.
Account for run order if it affects heat or cache state. One fast and one slow run cannot support a robust conclusion.
Memory and prolonged scenarios
Measure beyond startup. Repeatedly open heavy screens, switch sections, load images, and navigate back. Observe whether memory settles after operations complete.
Growth alone does not establish a leak; useful caches may be filling. Inspect retained objects, repeatability, and behavior under constrained resources. Symptoms may eventually appear as restarts or state loss after backgrounding.
Responsiveness, frames, and hangs
Average FPS can hide noticeable individual delays. Inspect frame durations, problematic sections, and input response. Frame budgets depend on refresh rate and device behavior; one number cannot fit every display.
Distinguish expensive animation, brief dropped frames, and prolonged unresponsiveness. Users experience related symptoms, but causes and tools differ. Android Studio and Instruments can investigate specific sections beyond visual impressions.
Network, battery, and storage
Check transfer volume, repeat requests, cache use, and background behavior. Unnoticed continuous polling can consume battery and data despite a fast interface.
A quick glance at battery percentage says little. Use a repeatable extended scenario and available measurement tools. Observe file and cache growth too: ordinary use must not consume storage without bounds.
Reporting results
State user impact, device, conditions, builds, exact measurement boundaries, and repeated-run results. Retain a profile or trace; use video to illustrate visible symptoms.
A few arbitrary attempts cannot produce a reliable p95. Small samples support initial diagnosis, but distribution and rare-delay conclusions need enough data. Production metrics additionally reveal whether real users encounter the problem.
Key takeaways for QA
Test performance through repeatable scenarios, agreed criteria, and suitable devices. Establish a regression before explaining it through profiling. Evaluate speed alongside memory, stability, and energy use; accelerating one screen must not degrade the rest of the product.