Android app performance Optimization View optimization
Objective:
Whenever an app starts to expand quickly, as business functions become more complex, more and more functional modules are always causing such performance problems. Interaction is not smooth, ANR, mobile phone calorific value and so on performance issues in Android development has always been a pit dad's existence. Not everyone does not want to optimize, may be waiting for you to find the start to engage in performance, found that the project seems to be big, can run not to collapse on the good, so much code to see, to change. Sincerity is a dejected to think about. Also possible, the key point is not easy to find, perhaps a performance problem is something else you can not think of the place caused, in order to optimize such a point, it may take a lot of time. In short, such a complex, vast work, if you do not want to do, you can find 10,000 reasons. But a high-quality application, performance optimization will directly affect your app is what level of app, how many users will be chasing you, you can let your app increase how much value. All right, don't pull the duzi.
The basic concepts-whether big or small, suggest looking and deepening impressions.
This issue is about view optimization, there are a few basic concepts about rendering that you have to mention.
Rendering Performance
The most important root cause of performance problems that most users perceive as lag is because of rendering performance. The Android system is likely to be unable to complete the complex interface rendering operations in a timely fashion when the requirements are complex interactions or are the special effects of a cool hot dick bombing day. The Android system emits a vsync signal every 16ms, triggering a rendering of the UI, and if each render succeeds, it will be able to achieve the 60fps required for a smooth screen, which means that most of the program's operations must be done within 16ms in order to achieve 60fps.
But as said above, if a cock bombing day of the effect of processing more than 16MS, the system can not get the vsync signal when the normal rendering, so there is a drop frame phenomenon. Then the user will see the same frame in 32ms.
Generally speaking, the UI performs animations, or a view suddenly pops up at the same time many components that need to be rendered, or sliding the ListView is prone to lag, because the operation is relatively complex, prone to the phenomenon of dropped frames, and thus feel the lag. There are a number of reasons for dropping frames, perhaps because your layout is too complex to render within 16ms, possibly because there are too many drawing units stacked on your UI, and possibly because the animations have been executed too often. These can cause CPU or GPU overloading.
Excessive repainting
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 operation, this causes some pixel areas to be drawn multiple times. This wastes a lot of CPU and GPU resources.
In general, this problem should be a common problem in most apps, probably because the use of cascading components is unreasonable, resulting in excessive redrawing, or the layout repeating setting background causes excessive repainting. But this problem, we can easily use the tools provided by the mobile phone to quickly find out. The use of the tool is then given.
VSYNC
To understand how the app is rendered, we have to understand how the phone hardware works, so we have to understand what VSync is.
Before we explain the vsync, we need to know two related concepts:
- Refresh Rate: Represents the number of times a screen is refreshed in a second, depending on the hardware's fixed parameters, such as 60Hz.
- Frame rate: Represents the number of frames that the GPU draws operations within one second, such as 30fps,60fps.
The GPU gets the graphics data to render, and the hardware is responsible for rendering the rendered content onto the screen, and they collaborate on both sides.
The normal situation is good, but the problem is that your program, the operation, it is very likely to cause the frame rate is not synchronized, resulting in the front frame and after the frame overlap, there is an image fracture problem.
Just like the figure below
VSync If you want to dig deep or very interesting, interested in Google. Share a VSync related literature.
VSYNC Reference Documents
http://blog.csdn.net/michaelcao1980/article/details/43233765
Tool Article In fact, there are many tools that can be tuned. Here are some of the more commonly used tools with no threshold to use and skills. These are good enough to solve a lot of problems.
profile GPU Rendering (GPU rendering mode analysis)This tool is in the developer options for your phone. You can choose a different rendering method
as the interface refreshes, a line graph is displayed on the interface to indicate the time required to render each frame.
, the higher the figure represents the cost of The longer the rendering time.
In the middle there is a green horizontal line, representing 16ms, we need to make sure that the total time spent on each frame is lower than this one
horizontal line, so that the problem of stalling can be avoided. The entire analysis is divided into three parts, the blue represents the time to paint the display list, red represents the time that OpenGL renders the display list, and yellow represents the time the CPU waits for GPU processing.
Examples of applications
The User Center has a small animation of the active tag that is the jitter of a hot tag. When you go to the page, you find that the curve beats very hard, and each beat exceeds the 16ms baseline. It is doubtful whether this animation effect is implemented unreasonably.
After reviewing the code to find such a simple animation, the use of the way is actually frame-wise animation implementation.
<span style= "Font-family:comic Sans ms;font-size:14px;" ><?xml version= "1.0" encoding= "Utf-8"? ><animation-listxmlns:android= "http://schemas.android.com/apk/ Res/android "android:oneshot=" false "><itemandroid:drawable=" @drawable/hot_1 "android:duration="/> <itemandroid:drawable= "@drawable/hot_2" android:duration= "/><itemandroid:drawable=" @drawable/hot_3 "Android:duration="/></animation-list></span>
The step-by-frame animation is implemented by displaying the specified frame picture at a specified time. One-frame animation can be a lot of complex animations, but it also brings performance problems, because each variable frame needs to load a new picture resource. At the same time, because the frame is self-tuning, if each frame set picture changes too big, the whole animation will be very inconsistent and smooth.
For this simple animation of jitter, it can be done with tweened animation, not only reduce the consumption of resources, but also make the whole animation more smooth to open.
<pre name= "code" class= "java" ><span style= "font-family:comic Sans ms;font-size:14px;" > private void Sethotimganimation (View animationview) { Objectanimator shakeanimator = new Objectanimator () ; Shakeanimator.setinterpolator (New Linearinterpolator ()); Shakeanimator.setproperty (view.rotation); Shakeanimator.setfloatvalues (0,45,0); Shakeanimator.setduration (+); Shakeanimator.setrepeatcount (valueanimator.infinite); Shakeanimator.settarget (Animationview); Shakeanimator.start (); } </span>
Run the code to see the modified effect:
You can clearly see the GPU rendering of the analysis diagram, the whole process becomes relatively smooth, the animation process has been reduced to less than 16ms.
Show GPU Overdraw (display GPU over-drawn)
This tool can also be found in the developer options, and once opened, each component will be marked with a colorful display whenever you enter an application. What do these colors mean, respectively? Blue, light green, light red, crimson represents 4 different levels of overdraw, and our goal is to minimize the overdraw and see more blue areas.
Overdraw sometimes because there are a lot of overlapping parts in your UI layout, or because you don't have to overlap the background. For example, an activity has a background, and then the layout has its own background, and the sub-view has its own background. Simply by removing the necessary background image, this can reduce the number of red overdraw areas and increase the percentage of the blue area. This measure can significantly improve program performance.
let's take a few examples to illustrate its use:
Note: To better present the performance impact of the overdraw, here's a little trick--a constant refresh of the interface, so that enough GPU performance analysis diagram.
as can be seen, left unmodified interface, overdraw serious, full screen red, from the GPU rendering graph, GPU draw rendering time exceeded 16ms benchmark. The main reason for so much over-drawing is the repeating background, the upper layout of the red area set the background, and the sub-layout repeats the background setting, resulting in over-drawing. After setting the unnecessary background, you can see that the red marking area basically disappears, and from the GPU rendering graph, the average GPU rendering time is lowered below the 16ms baseline.
Android monitors-dump View HierarchyThis tool is in Android monitors. This feature will cut down the graph displayed in the current interface, and display the details of the display list on the right side of the current interface. With this information, you can not only analyze the status, value, size, etc. of the various components of the view, but also view the layout of the current interface and whether the hierarchy is reasonable. this way I will not repeat it.
This period of sharing is here, and the follow-up will be more practical tools and techniques for tuning. It is also hoped that the readers will actively share the better tuning methods found during the development process, so that the application becomes more and more sparkling.
Android app performance Optimization View optimization