Android Performance Optimization series--profile GPU Rendering

Profile GPU Rendering

The Android Developer option provides the profile GPU rendering feature for real-time display on the screen of how long the GPU takes to render each frame image (in ms).

The rendering time is represented by a histogram, the Green line above represents 16ms, which means to try to ensure that all bars are below this line. Each histogram is made up of 3 parts, blue, red, and yellow, representing 3 different stages of rendering, and by analyzing the time of the three stages, you can find performance bottlenecks when rendering.

The blue section indicates the time to draw or to create and update the display list at the Java layer. Before a view is actually rendered, it needs to be converted to a format that the GPU can recognize. In a nutshell, it's probably just a few drawing commands, a bit more complicated, and we might be embedding a custom path that gets from the canvas. Once this is done, the output will be cached by the system as the display list.

The blue section records how long this frame takes to complete these two steps for all view that needs to be updated. When it is high, it means that there are a lot of view suddenly invalid (invalidate), or there are several custom view in the OnDraw function to do a particularly complex drawing logic.

The blue section of this bar represents draw time or rather how long it took to create and update your D Isplay lists in Java. Remember that before a view can actually is rendered, it has to first being transformed into a gpu-friendly format.
on the simple side of this, it could just is a few Draw commands. But on the complex end, we could is tessellating a custom path coming from your canvas object.
Once Done, the results is then cached as a display list object by the system.
This blue bar was recording how much time it takes to complete these, steps for all, the views, need to being updat Ed on the screens this frame.
When you see the This bar shoot high, it could mean that a bunch of views suddenly became invalidated, or it could be a few Custom views The WHO might has some extremely complex logic in their OnDraw funtion.

The

Red section represents the execution time, which is the time that the Android 2D rendering engine (OpenGL) executes the display list. To draw the changes on the screen, Android needs to use the OpenGL ES API to draw these display list information, OpenGL eventually passes the data to the GPU, and the GPU renders to the screen. The more complex the view, the more complex the commands required for OpenGL drawing. If the red section is relatively high, complex view can be the culprit. It's also worth noting that there are large spikes, which means that some of the view has been repeatedly submitted, that is, drawn several times, and they may not need to be redrawn.

The red section of the bar represents execute time. This was the time spent by Android's 2D renderer to execute display list.
See, on order to draw to the screens, Android needs to draw your display list information by interacting with the Open GL ES API which effectively passes along data to the GPU, which then, ultimately, ends up putting pixels on the screen. Remember-for-more complex-a custom view, the more complex the commands needed for OpenGL to draw it.
And when you see this red bar shoot high, these complex views is a likely culprit.
It ' s also worth noting that large spikes in the This bar can come from re-submitting a load of views to be redrawn again. These views haven ' t necessarily been invalidated. But if something-happens, like a-view rotates, then we need-to go-back and clean-up areas of the "the screen" might be Affe CTED by this redrawing the views underneath it.

The orange portion represents the processing time, and the CPU tells the GPU when the rendering has completed. This part is blocked, the CPU waits for the GPU to know that the command is received, and if this is higher, it means that the GPU does too much work, usually because many complex view drawings require too much OpenGL rendering commands to handle.

The Oragen section of the bar represents the process time. Or rather, this is where the CPU tells the GPU it's done rendering a frame. This action was a blocking call, and as such the CPU would sit around and wait for the GPU to acknowledge that it ' s received The command. If This bar was getting large, then it means so you ' re doing a lot of work in the GPU resulting from many complex views T Hat require a lot of OpenGL rendering commands to be processed.

CPU and GPU
The modern graphics API does not allow the CPU to communicate directly with the GPU, but instead connects the two parts through a graphics driver layer in the middle (the graphics Driver).

The graphics driver maintains a queue, the CPU adds the display list to the queue, and the GPU pulls the data out of the queue to draw.

Refefence

Android Performance Patterns:tool-profile GPU Rendering
Perf primer:cpu, GPU and your Android game

Android performance Optimization series--profile GPU Rendering