Deep understanding of the Android rendering mechanism

Basic knowledge

CPU: central processing Unit, it integrates operation, buffering, control and other units, including drawing function. The CPU handles objects as multidimensional graphics, and textures (Bitmaps, drawables, etc. are packaged together into a uniform texture).

GPU: A CPU-like processor specifically designed to handle graphics, to help speed up grid operations, and, of course, to have the appropriate cache data (such as caching already rasterized bitmap) mechanism.

OpenGL ES: A 3DAPI, cross-platform, fully functional 2D and 3D graphics API for handheld embedded devices, with a fixed rendering pipeline process. OpenGL es detailed

displaylist transforms an XML layout file into an object 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 given to the GPU to draw to the screen.

Grid is the image of vector resources, such as the conversion of a pixel pixel pixels, displayed on the screen.

Vertical Sync VSync: Let the graphics card's operation and display refresh rate consistent to stabilize the output picture quality. It tells the GPU to wait for the screen drawing to finish before loading a new frame. The following three graphs are what happens with GPU and hardware synchronization, refresh rate: The number of times a screen is refreshed in a second, as determined by the hardware, such as 60Hz. and Frame Rate:gpu a second to draw the number of frames in the operation, the unit is 30fps, the normal process diagram is as follows:

Introduction to rendering mechanism analysis rendering process

The overall drawing process for Android is as follows:
UI object-->CPU is processed as a multidimensional graphic, texture---call the gpu--> GPU on the Opegl es interface to rasterize the graph (Frame rate)--Hardware clock (Refresh rate)--Vertical sync--Project to screen

The Android system emits a vsync signal (1000ms/60=16.66ms) every 16ms, triggering a rendering of the UI, which, if each render succeeds, is able to achieve the 60fps required for a smooth screen, in order to achieve 60fps, This means that most of the operations that compute the rendering must be done within 16MS.

Render Timelines

Under normal circumstances, the Android GPU will be in the 16ms to complete the drawing of the page, if a frame screen rendering time is more than 16ms, the vertical synchronization mechanism will let the display hardware wait for the GPU to complete the raster rendering operation, and then draw the interface again, it will appear to pause the screen.

When GPU rendering is too slow, it can result in the following situations where some frames display the same screen content as the previous frame.

Rendering FAQ GPU Over-drawing

Overdraw is a common optimization point in development, which refers to the situation where layers are drawn in an interface, such as:

We can use some third-party tools to see if transitions are drawn. such as Millet Meizu.

Any time the drawing content in the view changes, the creation of displaylist, rendering displaylist, and updating to the screen will be performed in a series of actions. The performance of this process depends on the complexity of your view, the state of the view, and the execution performance of the rendering pipeline.

When the size of the view changes, the displaylist is recreated and then rendered, and when the view shifts, the displaylist is not recreated, but the re-rendered operation is performed.
So when the interface is too complex, the Displaylist drawing interface will be delayed and result in Kaka.

We can use the render tool to detect that there may be differences in how different phones are presented in the tool. The GPU rending information about Statusbar,navbar, the active program activity area, respectively. The GPU rending information for the active program activity area.

We turn on the phone's GPU rending to present the information, we take Meizu for example:

Note: Each bar has three parts,
Blue represents the time to measure the display list,
Red represents the time required for OpenGL to render the display list.
Yellow represents the time the CPU waits for GPU processing.

Android Rendering optimization

Understanding the Android rendering mechanism is helpful for optimization, especially when writing layouts. Reduce the layout level and reduce GPU rendering this is helpful in providing the quality of the app.

To remove unnecessary interfaces:

Layout-Level optimization

You can see the level of the interface using the Hierarchy Viewer tool, see my previous blog: Android layout optimization

Picture Format Selection

The Android interface can be used PNG preferably PNG, because the 32-bit PNG color transition smooth and support transparency. JPG is a pixel compressed picture, the quality has dropped, and then take to do 9path buttons and the tension of the control will inevitably be miserable, to try to avoid. Conditional can choose WEBPP, this format of the picture occupies a small size, and can meet the needs of mobile phone display.

When the background can not be avoided, try to use color.transparent

Because the transparent color color.transparent is not rendered, he is transparent.
So we need to make a decision when setting up 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);}

Deep understanding of the Android rendering mechanism