Maintaining a smooth, consistent frame rate is essential for delivering responsive user experiences on Android devices. Modern smartphones feature displays refreshing at 60Hz, 90Hz, or 120Hz. To hit 60 frames per second (fps), the operating system and application UI thread must measure, layout, draw, and upload each frame within a strict 16.6ms budget (or 8.3ms on 120Hz screens). When rendering pipelines exceed this threshold, frames are skipped, producing perceptible stutter known as UI jank.
Android Debug Bridge (ADB) provides the dumpsys gfxinfo command, allowing developers and performance engineers to capture comprehensive rendering diagnostics, frame completion percentiles, and dropped frame counts directly from the command line without modifying application source code.
Preparing the Target Device and Clearing Previous Profiling Data
Connect your Android smartphone or tablet to your computer with USB Debugging enabled, then verify the connection:
adb devices
Before profiling a specific user interaction, identify the application’s package name (for example, com.example.app). Reset the internal graphics buffer so your diagnostic metrics reflect only the upcoming test session:
adb shell dumpsys gfxinfo com.example.app reset
Capturing High-Level Frame Rate and Jank Metrics
Perform the target interaction on your device—such as flinging through a long RecyclerView list, triggering an expansion animation, or switching tabs. Once complete, dump the aggregated graphics report:
adb shell dumpsys gfxinfo com.example.app
The output begins with a high-level statistical summary of recent frames:
Stats since: 123456789ns
Total frames rendered: 480
Janky frames: 18 (3.75%)
50th percentile: 7ms
90th percentile: 13ms
95th percentile: 17ms
99th percentile: 24ms
Number Missed Vsync: 4
Number High input latency: 2
Number Slow UI thread: 12
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 2
Interpreting the Key Metrics:
- Total frames rendered: The total frame sample captured during the recording window.
- Janky frames: Frames that missed the target VSYNC deadline. Production applications should generally maintain a jank rate below 5%.
- Percentiles (50th, 90th, 95th, 99th): The time taken to complete frames across standard distributions. If the 90th percentile exceeds 16ms on a 60Hz device, users will notice frequent stutter.
- Slow UI thread: Indicates excessive CPU operations (such as JSON parsing, database queries, or heavy view inflation) blocking the main thread during frame generation.
- Slow bitmap uploads: Indicates uncompressed or oversized image assets being transferred across the CPU/GPU bus without hardware caching.
Extracting Granular Per-Frame Breakdown Using framestats
To identify the exact phase of the rendering pipeline responsible for latency spikes, append the framestats flag:
adb shell dumpsys gfxinfo com.example.app framestats
This command outputs detailed CSV data containing timestamps (in nanoseconds) for the last 120 rendered frames. Each line breaks down the 14 standard pipeline stages:
IntendedVsync: The ideal time the frame was scheduled to begin.Vsync: The actual time the main thread acknowledged the VSYNC signal. A wide gap between IntendedVsync and Vsync indicates main thread starvation.InputHandling: Time spent executing touch gesture callbacks and motion events.Animation: Time consumed by ValueAnimators and physics simulations.PerformTraversals: Duration of themeasure()andlayout()view hierarchy pass. Deeply nested layouts significantly inflate this value.Draw: Time spent converting UI views into GPU display list commands.Sync: Time spent synchronizing main thread assets with the backgroundRenderThread.IssueDrawCommands: Duration spent executing OpenGL/Vulkan rendering calls against the GPU.FrameCompleted: Total time from frame scheduling to presentation on the screen.
Automating Performance Audits in Continuous Integration
You can automate jank detection during end-to-end UI tests by piping the output through grep and awk:
adb shell dumpsys gfxinfo com.example.app | grep "Janky frames:" | awk '{print $3, $4}'
By integrating this query into continuous testing pipelines, engineering teams can automatically reject pull requests that introduce layout regressions or exceed acceptable frame drop thresholds.