Android Performance Patterns: Render Performance

Word count: 1.5kReading time: 9 min

 2015/04/19

Series Catalog:

Technical review (2026-10-13): This is a study note from the 2015 video series. The Nexus 5 example and tool screenshots remain historical material. The original introduction uses 16ms as an approximation for 60Hz; the discussion below now clarifies refresh behavior, jank, and tool limitations.

Original video introduction:

Rendering performance is all about how fast you can draw your activity, and get it updated on the screen. Success here means your users feeling like your application is smooth and responsive, which means that you’ve got to get all your logic completed, and all your rendering done in 16ms or less, each and every frame. But that might be a bit more difficult than you think.

In this video, Colt McAnlis takes a look at what “rendering performance” means to developers, alongside some of the most common pitfalls that are ran into; and let’s not forget the important stuff: the tools that help you track down, and fix these issues before they become large problems.

Android Rendering Knowledge

When you think you’ve developed a world-changing app, your users might not agree. They might think your app is slow and laggy, failing to achieve the smoothness they expect, let alone changing the world. Straight into the bin! Hang on, it runs smoothly on my Nexus 5. How can it be slow? If you know anything about Android fragmentation, you’d know that many low-end phones don’t have the powerful processor and GPU of a Nexus 5, or the same clean stock Android installation.

If a large number of users complain that your app is laggy, don’t just blame their hardware. Sometimes the problem lies within the app itself, including rendering work or a blocked main thread. Measure first to identify the cause and choose a fix. Thus, knowing how Android rendering works is essential for any Android developer.

At 60Hz, display intervals are about 16.67ms. At 90Hz, 120Hz, and 144Hz, they are approximately 11.11ms, 8.33ms, and 6.94ms. Scheduling and the rendering pipeline also affect the app’s actual deadline. One function taking more or less than 16ms does not, by itself, prove that a frame missed its deadline or appeared smoothly.

Design vs Performance

Rendering issues come up often when building an app. Designers want something dazzling, but those animations and Views won’t run smoothly on every Android phone. That is the tradeoff we have to work with.

Design vs Performance

Drawing Principles

Android does not unconditionally redraw the entire Activity every 16ms. In the View system, invalidation, layout requests, and animations can drive another frame. ViewRootImpl schedules its traversal through Choreographer. A static interface with no pending update does not need to rerun drawing for the entire View tree simply because another refresh arrives. This demand-driven behavior already exists in Android 4.4.4 ViewRootImpl and Choreographer.

Hardware acceleration still needs CPU work for measurement, layout, and recording drawing commands; unchanged display lists can be reused. Android 5.0’s ThreadedRenderer delegates rendering to RenderThread. The GPU executes commands asynchronously, followed by SurfaceFlinger composition and presentation. The main thread finishing does not mean the frame is already on screen. See the hardware-accelerated drawing model.

The original diagram uses a simplified 60Hz model: a continuous animation appears smooth when successive frames meet their expected presentation times. Its 16ms labels are approximations, not universal thresholds.

Draw Good

If an update takes 24ms and misses its intended presentation opportunity, it may cause what we commonly call a dropped frame or jank.

Draw Bad

When no new buffer is available, SurfaceFlinger can keep the previous buffer. The display has not necessarily stopped refreshing, and other layers may still update. See the SurfaceFlinger documentation.

In a simplified fixed-60Hz example that misses one presentation opportunity, old content remains for about 33.33ms instead of 16.67ms. Neither the diagram’s “34ms” nor the original text’s “32ms” is a precise measurement. Buffering, scheduling, GPU completion, and submission timing affect the actual outcome; “24ms” alone cannot tell you how many frames a particular device will miss.

Frame Drops

Frame drops are a core user experience issue. Users easily perceive the stuttering caused by dropped frames, especially during interactions like list scrolling or typing. Users will immediately complain, and the next step is often uninstalling your app. Understanding the causes of frame drops is critical.

Unfortunately, many things can cause frame drops, such as:

Triggering unnecessary measurement, layout, or drawing-command recording, adding CPU work.
Drawing pixels that will be covered by later content; the cost depends on clipping, transparency, and renderer optimizations.
Animations repeatedly triggering expensive layout or drawing. Animation count alone does not prove a CPU or GPU bottleneck.

Detection and Solution

Detecting and solving these issues depends heavily on your application architecture. Fortunately, we have many developer tools to help. Some tools can even trace down to specific lines of code or UI controls. These tools include but are not limited to:

Hierarchy Viewer

Hierarchy View

The old Hierarchy Viewer helps reveal unnecessary nesting in a View tree. Depth is a clue, not proof of jank or overdraw. The screenshot and Window → Open Perspective → Hierarchy View refer to historical tools. Their host, Android Device Monitor, was deprecated in Android Studio 3.1 and removed in 3.2; those launch instructions are obsolete.

Use Layout Inspector for debuggable View, Compose, or hybrid apps. It shows hierarchy, attributes, snapshots, and Compose recomposition/skip information. These explain structure; node counts and recomposition counts alone do not establish frame cost or missed deadlines.

On-Device Tools: Profile GPU Rendering, Show GPU Overdraw, GPU View Updates

On-Device Tools

These tools live in Developer options; their names and locations vary by Android version and vendor. From Android 4.2, enabling Developer options usually requires tapping Build number seven times in the device’s About screen. See the official instructions.

Profile GPU/HWUI Rendering displays rendering stages as bars, useful for spotting anomalies. Despite its name, it measures CPU-side stages and waits, not pure GPU execution time. It also does not cover every custom OpenGL/Vulkan rendering path. See the tool documentation.
Debug GPU Overdraw highlights repeated drawing of pixels in the rendering paths it covers. It does not directly measure frame latency or per-pixel execution cost; the next article covers it further.
Show GPU View Updates flashes updated regions in older versions. In Android 4.4.4 HardwareRenderer, debug.hwui.show_dirty_regions overlays a translucent red rectangle on dirty regions in some frames. No red flash does not mean software rendering on the CPU. The region might be unchanged, or the overlay might not be drawn in that frame. This is not a CPU/GPU classifier, and it is distinct from Show Surface Updates and Show Hardware Layer Updates.

TraceView

Traceview is a legacy method-trace viewer. The screenshot shows thread timelines and method statistics, not each frame’s presentation timeline. It can help find Java method hotspots, but does not describe the entire GPU workload, cross-process scheduling, or actual presentation, nor does it guarantee visibility into every native function.

Traceview is deprecated; Android Studio 3.2+ uses CPU Profiler for these .trace files. Method instrumentation adds overhead, while sampling can miss short-lived calls. Absolute timings from a recording are not automatically representative of an unprofiled run. See method tracing and profile types.

A practical workflow today is:

Capture a system trace of a reproducible scrolling or animation scenario. On Android 12 / API 31+, Perfetto FrameTimeline compares expected and actual timelines and helps connect app frames, SurfaceFlinger, and jank reasons. Older systems and unsupported rendering paths do not automatically provide the same tracks.
Examine the captured main-thread, RenderThread, scheduling, and GPU evidence for an affected frame. CPU work, lock waits, scheduling delays, and unfinished GPU work are different causes. A system trace does not automatically log every function.
Re-run the same scenario and device with Macrobenchmark after the fix. FrameTimingMetric was added in AndroidX Benchmark 1.1.0, and frameOverrunMs requires API 31+. Follow the target-app configuration for a non-debuggable, profileable app; a Layout Inspector debugging session is not a performance baseline.

Perf Matters

Keep calm, profile your code, and always remember, Perf Matters.

Summary

The first video covers the basics of rendering performance, what can go wrong, and the tools for investigating it. It gets us through finding and locating a problem; fixing it is mostly left for practice. That is how this series works: learn to use the tools and understand what they show, then work out a fix for the app in front of you. There is no single fix for every app.

About Me && Blog

Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”