In-depth understanding of Android's rendering mechanism

Basics

CPU: Central Processing Unit, which integrates computing, buffering, control and other units, including drawing functions. The CPU processes objects into multi-dimensional graphics and textures (Bitmaps, Drawables, etc. are all packaged together into a unified texture).

GPU: A processor similar to the CPU that is specifically used to process Graphics. It is used to help speed up rasterization operations. Of course, there is also a corresponding mechanism for caching data (such as caching already rasterized bitmaps, etc.).

OpenGL ES: It is a 3D API for handheld embedded devices. It is a cross-platform, fully functional 2D and 3D graphics application programming interface API with a fixed rendering pipeline process. OpenGL ES detailed explanation

DisplayList converts the XML layout file into objects that the GPU can recognize and draw on Android. This operation is done with the help of DisplayList. DisplayList holds all the data information that will be handed over to the GPU to draw on the screen.

Rasterization is the process of converting vector resources such as images into a pixel map with grids of pixels and displaying it on the screen.

Vertical synchronization VSYNC: Make the graphics card's calculation and display refresh rate consistent to stabilize the output image quality. It tells the GPU to wait for the screen to draw the previous frame before loading a new frame. The following three pictures are what happens when the GPU and hardware are synchronized. Refresh Rate: The number of times the screen refreshes in one second, which is determined by the hardware, such as 60Hz. And Frame Rate: The number of frames drawn by the GPU in one second, the unit is 30fps. The normal process diagram is as follows:

Rendering mechanism analysis

Introduction to the rendering process

The overall drawing process of Android is as follows:

UI object -> CPU processes it into multi-dimensional graphics, texture -> calls GPU through OpeGL ES interface -> GPU rasterizes the image (Frame Rate) -> Hardware clock (Refresh Rate) -> Vertical synchronization -> Projected to the screen

The Android system sends a VSYNC signal every 16ms (1000ms/60=16.66ms) to trigger the rendering of the UI. If each rendering is successful, the 60fps required for a smooth picture can be achieved. In order to achieve 60fps, this means that most calculation and rendering operations must be completed within 16ms.

Rendering Timeline

Under normal circumstances, Android's GPU will complete the drawing of the page in 16ms. If the rendering time of a frame exceeds 16ms, the vertical synchronization mechanism will make the display hardware wait for the GPU to complete the rasterization rendering operation and then draw the interface again, which will make the picture appear to be paused.

When the GPU rendering speed is too slow, it will lead to the following situation: the screen content displayed in some frames will be the same as the previous frame.

Rendering FAQ

GPU Overdraw

OverDraw is a common optimization point in development, which refers to the situation where an interface is drawn layer by layer, such as:

We can use some third-party tools to check whether it is overdrawing. Such as Xiaomi Meizu.

Whenever the drawing content in the View changes, a series of operations such as creating the DisplayList, rendering the DisplayList, and updating it to the screen will be re-executed. The performance of this process depends on the complexity of your View, the state changes of the View, and the execution performance of the rendering pipeline.

When the size of the View changes, the DisplayList will be recreated and then rendered. When the View is displaced, the DisplayList will not be recreated, but re-rendered.

Therefore, when the interface is too complex, there will be delays in DisplayList drawing the interface, causing lag.

We can use the rendering tool to detect, in the tool, different mobile phones may have different presentation methods. GPU Rending information about StatusBar, NavBar, and the activated program Activity area. GPU Rending information about the activated program Activity area.

We open the information displayed by the GPU Rending of the mobile phone, taking Meizu as an example:

Note: Each bar line consists of three parts.

Blue represents the time to measure the drawing of the Display List.

Red represents the time required for OpenGL to render the Display List.

Yellow represents the time the CPU is waiting for GPU processing.

Android rendering optimization

Understanding Android's rendering mechanism is very helpful for optimization, especially when writing layouts. Reducing the layout level and reducing GPU rendering are very helpful for improving the quality of our app.

Remove unnecessary interfaces:

Layout level optimization

Use the Hierarchy Viewer tool to view the hierarchy of the interface. For an introduction to this, please refer to my previous blog: Android Layout Optimization

Of course, Android has also added tools to detect overdraw in some system versions. For example, Android added the Debug GPU Overdraw option in version 4.2. If you are using a Jelly Bean 4.3 or KitKat device, there will be a count in the lower left corner of the screen to show the degree of screen overdraw.

Another way to view overdraw is to select the "Show Overdraw areas" option in the Debug GPU overdraw menu. After selecting this option, different colors will be overlaid on different areas of the app to indicate the number of overdraws. Comparing these different colors on the screen can quickly and easily locate overdraw problems.

Image format selection

It is best to use png for Android interface, because 32-bit png has smooth color transition and supports transparency. Jpg is a pixel-compressed image, and its quality has been reduced. If it is used to make 9path buttons and tiled stretch controls, it will be terrible. Try to avoid it. If conditions permit, you can choose webpp, which takes up a smaller size and can meet the needs of mobile phone display.

When background cannot be avoided, try to use Color.TRANSPARENT

Because the transparent color Color.TRANSPARENT will not be rendered, it is transparent.

So we need to make a judgment when setting the interface:

Bean bean=list.get(i);
 if (bean.img == 0) {
            Picasso. with (getContext()). load (android.R.color.transparent). into (holder.imageView);
            holder.imageView.setBackgroundColor(bean.backPic);
 } else {
            Picasso. with (getContext()). load (bean.img). into (holder.imageView);
            holder.imageView.setBackgroundColor(Color.TRANSPARENT);
 }