Android performance optimization: rendering

Google recently released an online course on Android performance optimization on Udacity, which introduces how to optimize performance from the aspects of rendering, computing, memory, and power. These courses are a refinement and supplement of the Android performance optimization classic course previously released by Google on Youtube.

The following are study notes for the rendering chapter. Some of the content overlaps with the previous performance optimization examples. Welcome everyone to learn and communicate together!

1)Why Rendering Performance Matters

In order to achieve gorgeous visual effects, many apps now need to stack many view components on the interface, but this can easily cause performance problems. How to balance Design and Performance requires wisdom.

2)Defining 'Jank'

The screen refresh rate of most mobile phones is 60hz. If the task of a frame cannot be completed within 1000/60=16.67ms, frame loss will occur. The more frames are lost, the more severe the lag will be felt by the user.

3)Rendering Pipeline: Common Problems

Rendering operations usually rely on two core components: the CPU and the GPU. The CPU is responsible for calculation operations including Measure, Layout, Record, and Execute, while the GPU is responsible for Rasterization operations. The common cause of CPU problems is the presence of non-essential view components, which not only cause repeated calculation operations, but also occupy additional GPU resources.

4) Android UI and the GPU

Understanding how Android uses the GPU to render images helps us better understand performance issues. A very direct question is: how is the activity image drawn to the screen? How can those complex XML layout files be recognized and drawn?

Resterization is the most basic operation for drawing components such as Button, Shape, Path, String, Bitmap, etc. It splits those components into different pixels for display. This is a very time-consuming operation, and the introduction of GPU is to speed up the rasterization operation.

The CPU is responsible for calculating the UI components into Polygons and Textures, and then handing them over to the GPU for raster rendering.

However, it is very troublesome to transfer from CPU to GPU every time. Fortunately, OpenGL ES can hold the textures that need to be rendered in GPU Memory and directly operate them the next time they need to be rendered. So if you update the texture content held by the GPU, the previously saved state will be lost.

In Android, the resources provided by the theme, such as Bitmaps and Drawables, are packaged together into a unified Texture, and then passed to the GPU. This means that every time you need to use these resources, they are directly obtained and rendered from the texture. Of course, as UI components become more and more abundant, there are more evolved forms. For example, when displaying a picture, it needs to be loaded into the memory after calculation by the CPU, and then passed to the GPU for rendering. The display of text is more complicated. It needs to be converted into a texture by the CPU first, and then handed over to the GPU for rendering. When it returns to the CPU to draw a single character, it re-references the content rendered by the GPU. Animation has a more complicated operation process.

In order to make the App run smoothly, we need to complete all CPU and GPU calculation, drawing, rendering and other operations within 16ms per frame.

5) GPU Problem: Overdraw

Overdraw means that a certain pixel on the screen is drawn multiple times within the same frame. In a multi-layer overlapping UI structure, if the invisible UI is also drawing, some pixel areas will be drawn multiple times, which will waste a lot of CPU and GPU resources.

When designing for more gorgeous visual effects, we tend to fall into the vicious circle of using complex multi-level overlapping views to achieve such visual effects. This can easily lead to a lot of performance problems. In order to obtain the best performance, we must minimize the occurrence of Overdraw.

Fortunately, we can go to the developer options in the phone settings, turn on the Show GPU Overdraw option, and observe the Overdraw situation on the UI.

Blue, light green, light red, and dark red represent four different degrees of overdraw. Our goal is to minimize red overdraw and see more blue areas.

6)Visualize and Fix Overdraw - Quiz & Solution

Here is an example. Through the XML file, you can see that there are several unnecessary backgrounds. By removing the unnecessary backgrounds in the XML, the over-drawing of the layout can be significantly reduced. One of the more interesting points is: for the setting of the Avatar ImageView in the ListView, in the getView code, it is determined whether the corresponding Bitmap is obtained. After obtaining the Avatar image, the Background of the ImageView is set to Transparent. Only when the image is not obtained, the corresponding Background placeholder image is set. This can avoid over-rendering caused by setting a background image for the Avatar.

To summarize, the optimization steps are as follows:

Remove the default Background of Window

Remove unnecessary Background from XML layout file

Display a placeholder background image on demand

7) ClipRect & QuickReject

As mentioned before, drawing and updating invisible UI components will cause overdraw. For example, after the Nav Drawer slides out from the visible Activity, if you continue to draw those UI components that are not visible in the Nav Drawer, this will cause overdraw. To solve this problem, the Android system will try to reduce overdraw by avoiding drawing those components that are completely invisible. Those invisible Views in the Nav Drawer will not be executed and waste resources.

Unfortunately, for those overly complex custom Views (usually overriding the onDraw method), the Android system cannot detect what specific operations will be performed in onDraw, the system cannot monitor and automatically optimize, and Overdraw cannot be avoided. However, we can use canvas.clipRect() to help the system identify those visible areas. This method can specify a rectangular area, and only within this area will it be drawn, and other areas will be ignored. This API can be a good help for custom Views with multiple sets of overlapping components to control the display area. At the same time, the clipRect method can also help save CPU and GPU resources. Drawing instructions outside the clipRect area will not be executed, and those components whose parts are within the rectangular area will still be drawn.

In addition to the clipRect method, we can also use canvas.quickreject() to determine whether it does not intersect with a certain rectangle, thereby skipping the drawing operations in those non-rectangular areas.

8)Apply clipRect and quickReject - Quiz & Solution

The example above shows a custom View, which mainly presents multiple overlapping cards. The onDraw method of this View is shown in the following figure:

Turn on the display over-rendering in the developer options, and you can see that some areas of our custom View are over-rendered. So what causes over-rendering?

9)Fixing Overdraw with Canvas API

The following code shows how to use clipRect to solve the over-drawing of custom View and improve the drawing performance of custom View:

The following is the effect after optimization:

10)Layouts, Invalidations and Perf

Android needs to convert the XML layout file into objects that the GPU can recognize and draw. 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.

When a View needs to be rendered for the first time, a Display List will be created. When the View is to be displayed on the screen, we will execute the GPU's drawing instructions to render it.

If the Property of the View has changed (for example, moved), we only need to Execute Display List.

However, if you modify the content of some visible components in the View, the previous DisplayList can no longer be used. We need to recreate a DisplayList and re-execute the rendering instructions to update it to the screen.

Please note: Whenever the drawing content in the View changes, a series of operations such as recreating the DisplayList, rendering the DisplayList, and updating it to the screen will need to be performed. 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. For example, suppose the size of a Button needs to be increased to twice its current size. Before increasing the size of the Button, the parent View needs to recalculate and place the positions of other child Views. Modifying the size of the View will trigger the recalculation of the size of the entire HierarcyView. If the position of the View is modified, the HierarchView will be triggered to recalculate the positions of other Views. If the layout is complex, this can easily lead to serious performance issues.

11)Hierarchy Viewer: Walkthrough

Hierarchy Viewer can directly present the hierarchical relationship of the layout and various properties of the view components. We can use three different colors, red, yellow, and green, to distinguish the relative performance of the layout's Measure, Layout, and Executive.

12)Nested Hierarchies and Performance

The key to improving layout performance is to keep the layout hierarchy as flat as possible and avoid repeated nested layouts. For example, in the following example, there are two rows of views showing the same content, which are implemented in two different ways and have different hierarchies.

The following figure shows the difference in performance testing presented on the Hierarchy Viewer using two different writing methods:

13) Optimizing Your Layout

The following figure demonstrates how to optimize the layout of ListItem by replacing the nested LinearLayout in the old solution with RelativeLayout.