Profile GPU Rendering Walkthrough

This walkthrough shows how to use Profile GPU Rendering on your mobile device.

Profile GPU Rendering gives you a quick visual representation of how much time it takes to render the frames of a UI window relative to the 16-ms-per-frame benchmark.

What it's good for:

• Quickly seeing how a UI window performs against the 16-ms-per-frame target.
• Identifying whether any part of the rendering pipeline stands out in using processing time.
• Looking for spikes in frame rendering time associated with user or program actions.

Prerequisites

• A mobile device running at least Android 4.1 (API level 16) with Developer Options enabled.

Enable Profile GPU Rendering

You enable Profile GPU Rendering on a device using the Settings app, in the Developer Options section. This section of Settings is not visible by default. For information about enabling Developer Settings, see Run Apps on a Hardware Device.

To enable Profile GPU Rendering output:

• 

  Figure 1. Turning on Profile GPU Rendering.

  1. On your mobile device, go to Settings > Developer Options.
  2. In the Monitoring section, select Profile GPU Rendering.
  3. In the Profile GPU Rendering popup, choose On screen as bars to overlay the graphs on the screen of your mobile device.
  4. Go to the app that you want to profile.

• ---

  

  Figure 2. Screen when Profile GPU Rendering is on.

  Visual Output of GPU Profiler

  • For each visible application, the tool displays a graph.
  • The horizontal axis shows time elapsing, and the vertical axis time per frame in milliseconds.
  • As you interact with your application, vertical bars show up on your screen, appearing from left to right, graphing frame performance over time.
  • Each vertical bar represents one frame of rendering. The taller the bar, the longer it took to render.
  • The green line marks the 16 millisecond target. Every time a frame crosses the green line, your app is missing a frame, and your users may see this as stuttering images.

• ---

  Profile GPU Rendering Graph

  

  Figure 3. Enlarged Profile GPU Rendering graph.

  In this enlarged image of the Profile GPU Rendering graph you can see the colored sections as displayed on Android 6.0 (API level 23).

  • The green horizontal line represents 16 milliseconds. To achieve 60 frames per second, the vertical bar for each frame needs to stay below this 16 ms mark. Any time a bar pushes above this line, there may be pauses in the animations.
  • The tool highlights frames that exceed the 16 millisecond threshold by making the corresponding bar wider and less transparent.
  • Each bar has colored components that map to a stage in the rendering pipeline. The number of components vary depending on the API level of the device.

  The following table shows the component bars in Android 6.0 and higher.

  Component of Bar	Rendering Stage	Description
  	Swap Buffers	Represents the time the CPU is waiting for the GPU to finish its work. If this bar gets tall, it means the app is doing too much work on the GPU.
  	Command Issue	Represents the time spent by Android's 2D renderer issuing commands to OpenGL to draw and redraw display lists. The height of this bar is directly proportional to the sum of the time it takes each display list to execute—more display lists equals a taller red bar.
  	Sync & Upload	Represents the time it take to upload bitmap information to the GPU. A large segment indicates that the app is taking considerable time loading large amounts of graphics.
  	Draw	Represents the time used to create and update the view's display lists. If this part of the bar is tall, there may be a lot of custom view drawing, or a lot of work in onDraw methods.
  	Measure / Layout	Represents the amount of time spent on onLayout and onMeasure callbacks in the view hierarchy. A large segment indicates that the view hierarchy is taking a long time to process.
  	Animation	Represents the time it took to evaluate all the animators that were running that frame. If this segment is large, your app could be using a custom animator that is not performing well or some unintended work is happening as a result of properties being updated.
  	Input Handling	Represents the time that the app spent executing code inside of an input event callback. If this segment is large it indicates that the app is spending too much time processing the user input. Consider offloading such processing to a different thread.
  	Misc Time / VSync Delay	Represents the time that the app spends executing operations in between two consecutive frames. It might be an indicator of too much processing happening in the UI thread that could be offloaded to a different thread.

  Table 1. Component bars in Android 6.0 and higher.

  Android versions between 4.0 (API level 14) and 5.0 (API level 21) have a blue, purple, red and orange component. Android versions below 4.0 only have the blue, red, and orange components. The following table shows the component bars in Android 4.0 and 5.0.

  Component of Bar	Rendering Stage	Description
  	Process	Represents the time the CPU is waiting for the GPU to finish its work. If this bar gets tall, it means the app is doing too much work on the GPU.
  	Execute	Represents the time spent by Android's 2D renderer issuing commands to OpenGL to draw and redraw display lists. The height of this bar is directly proportional to the sum of the time it takes each display list to execute—more display lists equals a taller red bar.
  	XFer	Represents the time it take to upload bitmap information to the GPU. A large segment indicates that the app is taking considerable time loading large amounts of graphics.
  	Update	Represents the time used to create and update the view's display lists. If this part of the bar is tall, there may be a lot of custom view drawing, or a lot of work in onDraw methods.

  Table 2. Component bars in Android 4.0 and 5.0.

  Note: While this tool is named Profile GPU Rendering, all monitored processes actually occur in the CPU. Rendering happens by submitting commands to the GPU, and the GPU renders the screen asynchronously. In certain situations, the GPU can have too much work to do, and your CPU will have to wait before it can submit new commands. When this happens, you'll see spikes in the orange and red bars, and the command submission will block until more room is made on the GPU command queue.