Android Performance Optimization-control optimization and android Performance Optimization

Android Performance Optimization-control optimization and android Performance Optimization

Android Performance Optimization-Control Optimization

 

I have discussed image optimization before. Next I will share the performance optimization of controls. Here I will mainly discuss the optimization for custom views.

　　1. First, let's talk about the three possible errors in the Custom View:

1) Useless cballs to onDraw (): We know to call View. invalidate () will trigger the redrawing of the View. There are two principles to be followed. The first is to trigger the invalidate method only when the View content changes, 2nd are to use ClipRect and other methods to improve the rendering performance.

2) Useless pixels: reduces unnecessary painting elements during painting. For invisible elements, we need to avoid re-painting as much as possible.

3) Wasted CPU cycles: For elements not on the screen, you can remove them using Canvas. quickReject to avoid wasting CPU resources. In addition, try to use GPU for UI rendering, which can greatly improve the overall performance of the process.

 

Next I will introduce the optimization.

1. Avoid Memory Allocation Operations in the onDraw () method, such as new Paint ().

First, the onDraw () method is executed on the UI thread. Try to avoid any operations that may affect the performance of the UI thread. Although the memory allocation operation does not require too much system resources, it does not mean that there is no cost for free. Because the device has a certain refresh frequency, the onDraw method of the View is frequently called. If the onDraw method is inefficient, the problem of low efficiency will be extended when the accumulation of frequent refresh occurs, then it will have a serious impact on the performance.

The invalidate () method is called only when the view content changes.

You can call the Canvas. quickReject () method to remove elements that are not on the screen to avoid resource waste.

For example, when you slide the interface, the system will frequently call the onDraw () method, which will occupy a large amount of memory in a short period of time. Memory jitter may occur, and GC will be triggered frequently, which will affect the CPU efficiency and cause a large amount of cell phone power consumption.

2. Reduce the impact of alpha on performance.

In many custom views, in order to make the interface more beautiful, the alpha value is set to make the View transparent, however, this is a burden on performance. Generally, an opaque View only needs to be rendered once. However, if an alpha value is set for this View, it must be rendered at least twice. The reason is that a view containing alpha needs to know in advance what the next layer of the mixed View is, and then use the View on the upper layer to perform Blend color mixing.

In some cases, a View containing alpha may trigger and modify the parent View on HierarchyView, Which is re-painted once. In the following example, the image and the second-level title in the ListView are displayed with transparency settings.

 

 

In most cases, the elements on the screen are rendered from the back to the front. In the preceding figure, the background image (blue, green, red) is rendered, and the portrait image is then rendered. If the post-rendered element has an alpha value set, this element will be blend processed with the rendered element on the screen. Most of the time, we will set alpha for the entire View to achieve the fading animation effect. If the ListView in our figure is gradually reduced by alpha, we can see that the TextView and other components on the ListView will gradually converge to the background color. However, in this process, we cannot observe that it has actually triggered an additional drawing task. Our goal is to make the entire View more transparent, however, ListView does not stop performing Blending operations during this period, which may cause many performance problems.

How can we achieve the desired effect through rendering? We can first draw the elements in the View from the back to the front, but not directly display them on the screen, but use GPU preprocessing, after GPU rendering to the screen, GPU can directly rotate the raw data on the interface and set the transparency. Using GPU for rendering, although the first operation is more time-consuming than directly drawing on the screen, once the raw texture data is generated, the subsequent operations will save time and effort.

 

How can we make the GPU render a View? We can use the setLayerType method to specify how the View should be rendered. From SDK 16, we can also use ViewPropertyAnimator. alpha (). withLayer () to specify. As shown in:

 

Another example is a View that contains a shadow area. This type of View does not have the problem we mentioned earlier, because they do not have a stacked relationship.

 

To let the Renderer know this situation and avoid occupying extra GPU memory space for this View, we can make the following settings.

 

After the above settings, the performance can be significantly improved, as shown in: