Android Performance Optimization: Overdraw - Practical Application

Android Performance Overdraw

Word count: 1.3kReading time: 7 min

 2015/01/13

Introduction

The previous article covered the theory of overdraw and tools to detect it. While iOS users rely on Apple’s curation, Android users rely on developers’ discipline. Unfortunately, many market-leading Android apps still suffer from significant overdraw issues. As a developer, I want to see Android bridge and eventually surpass the experience gap with iOS.

This post follows one overdraw optimization case. It uses only a few of the available techniques; apps differ, and so will the changes they need. Treat it as an example. Getting this right still takes work.

If you missed the theory part, check it here: Android Performance Optimization: Overdraw (Part 1)

Technical review — 2026-10-13: This is a 2015 File Manager case study. The exact OS and app versions were not recorded. The Monitor, Hierarchy Viewer, and Tracer for OpenGL ES instructions are obsolete: Android Device Monitor was deprecated in Android Studio 3.1 and removed in 3.2. The screenshots remain useful, but fewer overdraw colors do not establish a frame-rate or power improvement; the original article contains no frame-time measurements.

For View-based pages today, use Android Studio Layout Inspector to inspect the runtime hierarchy and backgrounds, and Debug GPU Overdraw to locate repeated drawing. Compare the same interaction on the same device and OS, with debug coloring disabled during System Trace collection. Perfetto FrameTimeline is available on Android 12 / API 31 and later; it currently does not support SurfaceView, so it is not a measurement path for every type of content.

Identifying Overdraw Regions

1. Enable Overdraw Visualization

Find Debug GPU Overdraw → Show overdraw areas in Developer options. The original device placed this under Settings → Accessibility → Developer tools → Hardware-accelerated rendering; menu locations vary by system.

2. Open the Page Under Test

Enabling the overlay does not normally require killing the app. The original screenshots below were taken after reopening File Manager and Settings. For a before-and-after comparison, keep the launch state, list contents, and menu position consistent.

File Manager Settings

In the default scheme shown here, blue, green, light red, and red indicate one, two, three, and at least four extra draws respectively. File Manager has large green and red regions worth investigating. Settings helps illustrate the colors, but a different app is not a controlled performance baseline or an acceptance threshold.

3. Analyze Suspicious Regions

The blue ActionBar and bottom SmartBar suggest an extra draw. A theme background is one possibility, but the color alone cannot identify the responsible View or Drawable.
The green content area has two extra draws. A background fully covered by opaque content might be redundant; a color difference from Settings does not prove that it is safe to remove.
Start with these large regions, then inspect icons, list items, and the sliding menu.

Step-by-Step Optimization

The original workflow opened Monitor and switched to Hierarchy View. The screenshot below preserves that workflow; use Layout Inspector for a current project.

Original hierarchy inspection

The screenshot shows PhoneWindow$DecorView as the root, followed by ActionBarOverlayLayout. This is the hierarchy on the original device and theme, not a universal Android layout. The parent-child relationship alone does not establish that the window background belongs to ActionBarOverlayLayout.

1. Remove a Fully Covered Background

Distinguish the Window background from each View’s own background. In this case, I added the following line to File Manager’s main Activity in onCreate():

1	getWindow().setBackgroundDrawableResource(android.R.color.transparent);

This replaces the window background with a transparent color Drawable; it does not remove the Drawable object. If the page’s content always covers the window completely and opaquely, another option to evaluate is getWindow().setBackgroundDrawable(null), available since API 1. Setting a null background does not make the window transparent. Check loading, empty-list, menu-sliding, and transition states for exposed areas or flashes before adopting either change.

These are the original screenshots after applying the transparent background:

Optimization Step 1 Optimization Step 1 - Menu state

Compared with the earlier screenshots, the blue overlay on the ActionBar is gone, and the content has shifted from green to blue. Those regions have one fewer repeated draw in these frames.

2. Eliminate a Redundant Container Background

The original investigation identified DragRelativeLayout, derived from the project’s SlidingMenu. Its CustomViewAbove held the movable content, while CustomViewBehind held the menu behind it.

Hierarchy View Analysis

In the CustomViewBehind constructor, I found this line setting the background color:

1	setBackgroundColor(getResources().getColor(R.color.mz_slidingmenu_background_light));

The finding was that the menu content added by SlidingMenu.setMenu() completely covered this background. The change therefore removed the container’s background drawing, not the CustomViewBehind View. It also did not rely on CustomViewAbove always covering the menu. This was a finding about that project’s implementation, not a guarantee for other libraries or versions with the same class names. Exposed areas must still be checked with the menu open.

Optimization Step 2 Optimization Step 2 - Menu state

Repeated drawing is reduced in several regions. The intended appearance still needs checking with the menu both open and closed.

3. Inspect List-Item Drawing

Looking further under CustomViewAbove, I found a ListView with ID FilesList. I tried removing a setBounds() call from PartitionItemLayout.onDraw(). The overdraw colors decreased, but the list items also became lighter. These are the screenshots from that attempt:

List-item experiment List-item experiment - Menu state

The lighter list items matter: this step doesn’t yet count as a successful optimization. Drawable.setBounds() defines the rectangle used by a subsequent draw() call; it doesn’t draw anything itself. Removing it can leave stale bounds or stop a background that should still be visible from being drawn.

The next step is to find the call that draws the background, check whether that drawing is redundant, then remove or reduce it while preserving the intended appearance. Blue still means one extra draw; fewer colors don’t prove an optimal rendering path.

Improving Code Quality

Using Lint

Lint and IDE inspections can identify redundant layouts, unused resources, and potential errors. In the example below, a FrameLayout or its parent may be unnecessary. Remove it only after checking that it has no required background, padding, layout-parameter, or event-handling role.

Lint Warning

The original article also listed unused variables, possible null dereferences, empty branches, redundant return / continue, and simpler loop forms. Some are general IDE inspections rather than Android Lint performance rules. An enhanced for loop is not automatically faster. Removing a container primarily affects inflation, measurement, and layout; it reduces pixel overdraw only if it also eliminates actual repeated drawing.

Tracer for OpenGL ES — Historical Tool

These steps describe the old Device Monitor and do not apply to Android Studio 3.2 or later. Open the Tracer for OpenGL ES perspective, create a GLTrace, select the app and Activity, click Trace to start, and Stop to finish.

Original Tracer interface

I replayed the frames to check whether the default and CustomViewBehind backgrounds were still being drawn. The screenshot below remains, but the original GLTrace files aren’t available here for another analysis.

Original frame inspection

Avoiding fully covered backgrounds across multiple frames removes that drawing work. How much GPU time it saves, and whether it improves missed frames, requires a separate measurement. The historical screenshots do not provide those results.