Google "Android Performance optimization" Learning notes

Render article

1) Why Rendering performance Matters

There are many apps that will need to cascade a lot of view components on the interface, but this can be very easy to cause performance problems. It takes wisdom to balance design with performance.

2) Defining ' Jank '

Most mobile phone screen refresh rate is 60hz, if there is no way within the 1000/60=16.67MS to complete the task of this frame, there will be a drop frame phenomenon. The more dropped frames, the more serious the user feels about the lag situation.

3) Rendering Pipeline:common problems

Rendering operations typically depend on two core components: CPU and GPU. The CPU is responsible for calculating operations including Measure,layout,record,execute, and the GPU is responsible for rasterization (rasterization) operations. The common problem with CPUs is that there are non-essential view components that not only result in duplicate computations, but also consume additional GPU resources.

4) Android UI and the GPU

Understanding how Android uses the GPU for screen rendering can help us better understand performance issues. A very straightforward question is: how does the activity picture be drawn to the screen? How can the complex XML layout files be identified and plotted?

Resterization Rasterization is the most basic operation for drawing those components such as button,shape,path,string,bitmap. It splits those components into different pixels for display. This is a time-consuming operation, and the introduction of the GPU is to speed up rasterization operations.

The CPU is responsible for computing the UI component as a polygons,texture texture and then handing it to the GPU for rasterized rendering.

However, it's a hassle to move from CPU to GPU every time, fortunately OpenGL ES can hold the textures that need to be rendered in the GPU memory and work directly on the next time it needs to be rendered. So if you update the texture content held by the GPU, the previously saved state is lost.

In Android, the resources provided by the theme, such as Bitmaps,drawables, are packaged together into a unified texture texture and then transferred to the GPU, which means that each time you need to use these resources, you get the rendering directly from the texture. Of course, with the increasing richness of the UI components, there are more evolving patterns. For example, when a picture is displayed, it needs to be loaded into memory by the CPU's calculation before it is passed to the GPU for rendering. The display of the text is more complex, requires the CPU to be converted into a texture, and then to the GPU to render, return to the CPU draw a single character, and then re-reference GPU-rendered content. Animations have a more complex flow of operations.

In order to make the app smooth, we need to process all CPU and GPU calculation, drawing, rendering and so on within 16ms per frame.

5) GPU Problem:overdraw

Overdraw (Over-drawn) describes that a pixel on the screen is drawn several times within the same frame. In a multi-layered UI structure, if the invisible UI is also doing the drawing, it causes some pixel areas to be drawn multiple times. This will waste a lot of CPU and GPU resources.

When designing for a more ornate visual effect, it is easy to fall into the loop of complex multi-layered overlapping views to achieve this visual effect. This can easily lead to a lot of performance problems, in order to get the best performance, we have to minimize the occurrence of overdraw situations.

Fortunately, we can open the show GPU overdraw option by using the developer options in the phone settings, observing the overdraw situation on the UI.

Blue, light green, red and crimson represent 4 different levels of overdraw, and our goal is to minimize the overdraw and see more blue areas.

6) Visualize and Fix Overdraw–quiz & Solution

Here is an example of an XML file where you can see several nonessential background. By removing the non-essential background of XML, you can significantly reduce the over-drawing of the layout. One of the more interesting things is: for the ListView Avatar ImageView Settings, in the GetView code, to determine whether to obtain the corresponding bitmap, after acquiring the avatar image, the ImageView Background is set to transparent, the corresponding background placeholder image is set only when the image is not acquired, which avoids excessive rendering caused by setting the background map to Avatar.

To summarize, the optimization steps are as follows:

• Remove window's default background
• Remove non-required background in XML layout file
• Display a placeholder background image on demand

7) ClipRect & Quickreject

As mentioned earlier, drawing updates to an invisible UI component can cause overdraw. For example, if the nav drawer is sliding out of the previously visible activity, it will lead to overdraw if you continue to draw UI components that are not visible in the nav drawer. To solve this problem, the Android system minimizes overdraw by avoiding drawing components that are completely invisible. View that is not visible in the nav drawer will not be wasted resources.

Unfortunately, for overly complex custom view (which usually overrides the OnDraw method), the Android system cannot detect what is being done in OnDraw, and the system cannot monitor and automatically optimize, and there is no way to avoid overdraw. But we can use Canvas.cliprect () to help the system identify those areas that are visible. This method allows you to specify a rectangular area that will be drawn only within this area, and other areas will be ignored. This API can be very helpful for those custom view that has multiple sets of overlapping components to control the displayed area. While the Cliprect method can also help conserve CPU and GPU resources, drawing instructions outside of the Cliprect area will not be executed, and components that are part of the content within the rectangular region will still be drawn.

In addition to the Cliprect method, we can also use Canvas.quickreject () to determine if a rectangle is not intersected, skipping the drawing operations in the non-rectangular areas.

8) Apply ClipRect and Quickreject–quiz & Solution

The example diagram above shows a custom view with the main effect being to render multiple overlapping cards. The OnDraw method for this view is as follows:

Open the show over rendering in developer options and you can see that there is over-drawing in our Custom View section area. So what causes excessive plotting?

9) Fixing overdraw with Canvas API

The following code shows how to improve the drawing performance of Custom view by Cliprect to resolve the excessive drawing of custom view:

The following is an optimized effect:

Layouts, Invalidations and Perf

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

The display list is created for the first time a view needs to be rendered, and when the view is displayed on the screen, we execute the GPU's drawing instructions to render.

If the property attribute of the view changes (for example, the move position), we just need to execute the Display list to be sufficient.

However, if you modify the contents of some of the visible components in the view, then the previous displaylist cannot continue to use, we need to recreate a displaylist and re-execute the render instruction to update to the screen.

Please note: Whenever the drawing content in the view changes, you will need to recreate the displaylist, render the displaylist, and update to the screen for 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. For example, suppose that the size of a button needs to be twice times larger than the current one, and the position of the other child view needs to be recalculated and placed by the parent view before the button size is increased. Modifying the size of the view will trigger the entire hierarcyview operation of the recalculated size. Modifying the location of the view triggers the Hierarchview to recalculate the location of the other view. If the layout is complex, this can easily lead to serious performance problems.

One) Hierarchy Viewer:walkthrough

The Hierarchy Viewer can be very straightforward in rendering the layout hierarchy, the various properties of the view component. We can distinguish the relative performance of the layout measure,layout,executive by the red, yellow, and green three different colors.

Nested Hierarchies and performance

The key to improving layout performance is to keep the layout hierarchy flat and avoid duplicate nesting layouts. For example, in the example below, there are 2 rows of views that show the same content, each of which is implemented in two different ways, with different hierarchies.

Shows the performance test differences that are presented on the hierarchy Viewer using 2 different formulations:

Optimizing Your Layout

An example demonstrates how to optimize the layout of a ListItem by relativelayout instead of nesting linearlayout in the old scheme.

This article turns from http://www.techug.com/android-2

Google "Android Performance optimization" Learning notes