Android Performance Testing: ANR, Frame Skipping, and Smoothness Measurement

Android performance testing traditionally suffers from limited test dimensions and difficulty collecting and quantifying data due to device fragmentation, diverse hardware, and complex app features.

The main performance testing dimensions include ANR (Application Not Responding) testing, smoothness testing, power consumption testing, and traffic testing. Inefficient code can cause UI jank, waste battery, and consume costly data, leading to user churn.

ANR Testing – ANR occurs when the system detects unresponsive key or touch events (KeyDispatchTimeout after 5 seconds), broadcast receivers (BroadcastTimeout after 10 seconds), or services (ServiceTimeout after 20 seconds). The first type accounts for over 90 % of ANRs. Long‑running operations on the main thread, such as network or database work, trigger ANRs; the solution is to off‑load work to background threads and communicate results via Handler or Message .

ANR logs are written to /data/anr/traces.txt . Analyzing this file can reveal the offending code, but the logs are often abstract and hard to interpret.

Avoiding ANR – Keep main‑thread work minimal, especially in onCreate() and onResume() . Avoid heavy processing in BroadcastReceiver ; instead start a Service for long tasks. Do not launch activities from IntentReceiver ; use NotificationManager to inform the user.

TraceView – Android SDK’s built‑in tool that records method execution times. By saving the traceview file and inspecting it, most performance bottlenecks can be located.

Another lightweight detection method inserts a periodic check in the main thread; if a variable does not change within a set interval, the app is considered janky. This approach is used by the open‑source project ANR‑WatchDog , which converts ANR warnings into crashes and persists diagnostic information.

Smoothness Testing – UI rendering on Android aims for 60 Hz (≈16 ms per frame). When rendering exceeds this interval, frames are dropped (Skipped Frame, SF). Android 4.1 introduced VSync, Triple Buffer, and Choreographer (Project Butter) to improve smoothness.

VSync synchronizes the display refresh with the GPU, ensuring each loop runs within 16.6 ms. If CPU/GPU work exceeds this, frames are skipped, reducing the effective FPS.

Measuring smoothness can be done by counting how many VSync loops execute per second (SM). A lower SM indicates more jank. Using Choreographer ’s FrameCallback , developers can record loop counts and calculate SM, while logging TraceView data for skipped frames to pinpoint the cause.

Conclusion – After Android 4.1, VSync loops provide a clear metric for an app’s maximum drawing capability. Fixed 16.6 ms intervals cap the theoretical FPS at 60. By monitoring loop execution time and counting skipped frames, developers can quantify ANR and smoothness issues and optimize app performance.