Android FPS Measurement and Optimization: Methods, Tools, and Best Practices

Introduction – Inspired by a colleague's article on Android over‑rendering, the author shares experience testing app smoothness and outlines the need for quantitative, visualized, multi‑device, non‑root, API‑agnostic, automated, and reliable monitoring.

Test Requirements

Quantify program stutter via technical means and visualize data.

Support multiple device models without relying on root.

Avoid Android API version constraints to maintain compatibility.

Automate the monitoring workflow.

Ensure continuous and reliable data collection.

Understanding FPS – FPS (Frames per Second) is the number of frames displayed each second. Human perception requires at least 10‑12 fps for motion, 24 fps for smooth video, and 60 fps for optimal fluidity; 60 fps corresponds to a frame time of about 16.67 ms.

Calculation Formula

1000 ms / 60 frames ≈ 16.67 ms/frame

Feasible Ways to Obtain FPS

After reviewing various resources, three practical approaches were selected.

Method 1 – GPU Rendering Profile

Enable Settings → Developer options → GPU rendering profile and select "Show on screen as a bar graph". The screen displays a real‑time bar chart where a green line marks the 16 ms threshold; bars exceeding this indicate frame delays (jank). Screenshots illustrate the bar graph and typical GPU rendering examples.

Method 2 – adb shell dumpsys gfxinfo

adb shell dumpsys gfxinfo yourpackagename

The command returns graphics statistics such as total frames, janky frames, percentile frame times, and various latency counts. Example output (excerpt) is shown below:

** Graphics info for pid 3125 [com.qtest.demo] **
Stats since: 37470720668 ns
Total frames rendered: 95
Janky frames: 0 (0.00%)
90th percentile: 7 ms
95th percentile: 7 ms
99th percentile: 11 ms
Number Missed Vsync: 0
Number High input latency: 0
Number Slow UI thread: 0
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 0

This method works only on Android M and above and requires user interaction (screen dragging) to generate accurate data, making it less suitable for projects targeting a wide range of devices.

Method 3 – adb shell dumpsys SurfaceFlinger --latency

adb shell dumpsys SurfaceFlinger --latency com.qtest.demo/com.qtest.DemoActivity

The first line reports the refresh period (≈16.67 ms). Subsequent lines provide three columns for each of the last 128 frames: start draw time, VSync time before submission, and the timestamp after submission. The three columns allow calculation of per‑frame latency and detection of dropped frames.

Vertical Synchronization (VSync)

VSync synchronizes the GPU with the display’s refresh cycle; the GPU must wait for the previous frame to finish before presenting a new one, preventing screen tearing.

Jank (Dropped Frames)

Within a 16.67 ms refresh period, 127 timing entries are recorded. If the interval between consecutive frame timestamps deviates from the expected 16.67 ms, a frame delay (jank) occurs, counted as one drop per cycle.

Images illustrating the presence and absence of VSync and examples of GPU rendering jank are included in the original article.

The article concludes with reference links to further reading and notes that the discussion will continue in future updates.