Android performance optimization series-Profile GPU Rendering and androidrendering

Android performance optimization series-Profile GPU Rendering and androidrendering
Profile GPU Rendering

The Profile GPU Rendering function is provided in the Android developer options to display the time (in ms) that the GPU spends Rendering each frame of an image in real time on the screen ).

The rendering time is represented by a bar chart, and the green line above represents 16 ms, that is, to ensure that all the bar charts are under this line as much as possible. Each bar chart consists of three parts: blue, red, and yellow, representing three different stages of rendering, by analyzing the time of these three stages, we can find the performance bottleneck during rendering.

The blue part indicates the Painting time or the time when the display list is created and updated at the Java layer. Before a View is rendered, it needs to be converted to a format that the GPU can recognize. To put it simply, it may be a few drawing commands. To be more complex, we may embed a custom path obtained from the canvas. After this step is completed, the output result will be cached by the system as the display list.

The blue part records the time this frame takes to complete the two steps for all views to be updated. When it is very high, it means that many views are suddenly invalid (invalidate), or there are several custom views that are particularly complicated in the onDraw function.

The blue section of that bar represents draw time or rather how long it took to create and update your display lists in Java. remember that before a view can be actually be rendered, it has to first be transformed into a GPU-friendly format.
On the simple side of this, it cocould just be a few Draw commands. But on the complex end, we cocould be tessellating a custom path coming from your canvas object.
Once done, the results are then cached as a display list object by the system.
This blue bar is recording how much time it takes to complete these two steps for all the views that need to be updated on the screen this frame.
When you see this bar shoot high, it cocould mean that a bunch of views suddenly became invalidated, or it may be a few custom views who might have some extremely complex logic in their onDraw funtion.

The red part indicates the execution time, that is, the time when the Android 2D rendering engine (OpenGL) executes the display list. To draw changes on the screen, Android needs to use OpenGL es api to draw the display list information. OpenGL finally transmits the data to the GPU, and then the GPU renders the information to the screen. The more complex the View, the more complicated the commands required for OpenGL rendering. If the red section is relatively high, complicated views may be the culprit. It is worth noting that the peak value is relatively large, which indicates that some views have been submitted repeatedly, that is, they have been drawn multiple times, and they may not need to be re-painted.

The red section of the bar represents execute time. This is the time spent by Android's 2D renderer to execute display list.
See, in order to draw to the screen, Android needs to draw your display list information by interacting with the OpenGL es api which refreshing tively passes along data to the GPU, which then, ultimately, ends up putting pixels on the screen. remember that for more complex views like 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 are a likely culprit.
It's also worth noting that large spikes in this bar can come from re-submitting a load of views to be redrawn again. these views havent necessarily been invalidated. but if something happens, like a view rotates, then we need to go back and clean up areas of the screen that might be affected by that redrawing the views underneath it.

The orange part indicates the processing time. Further, the CPU tells the GPU that the rendering has been completed. This part is blocked, and the CPU will wait for the GPU to know that it has received the command. If the command is too high, it means there are too many tasks on the GPU, it is usually because of a lot of complicated view rendering that requires too many OpenGL rendering commands to process.

The oragen section of the bar represents the process time. or rather, this is where the CPU tells the GPU that it's done rendering a frame. this action is a blocking call, and as such the CPU will sit around and wait for the GPU to acknowledge that it's got the command. if this bar is getting large, then it means that you're doing a lot of work on the GPU resulting from your complex views that require a lot of OpenGL rendering commands to be processed.

CPU and GPU
The modern graphic API does not allow the CPU to communicate directly with the GPU, but connects the two parts through a graphical Driver layer in the middle.

The graphic driver maintains a queue. The CPU adds the display list to the queue, and the GPU extracts data from the queue for rendering.

Refefence

Android Performance Patterns: Tool-Profile GPU Rendering
Perf Primer: CPU, GPU and your Android game