Android app Optimizer's direct reason for slow app lag

The most important root cause of performance problems that most users perceive as lag is because of rendering performance. From the designer's point of view, they want the app to have more animation, pictures and other fashion elements to achieve a smooth user experience. But the Android system is likely to be unable to complete those complex interface rendering operations in time. 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 picture, which means that most operations of the program must be done within 16ms () More than 16ms, the more lost frames, you can probably estimate the Android 5 seconds did not respond to throw the ANR exception during the number of lost frames, the author forget 312 frames.

If one of your operations takes time of 24MS, the system will not be able to render normally when the vsync signal is received, so there is a drop frame phenomenon. Then the user will see the same frame in 32ms.

It is easy for users to perceive that the lag is not smooth when the UI is performing animations or sliding the ListView, because the operation is relatively complex and the phenomenon of dropping frames is prone to 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.

There are tools that can be used to locate the problem, such as using Hierarchyviewer to find out if the layout in the activity is too complex, or by using the developer options in the phone settings and opening the show GPU overdraw. You can also use TraceView to see how the CPU is performing and to find performance bottlenecks more quickly (so the layout has a principle of using simple layouts as much as possible).

2) Understanding Overdraw (Understanding over Drawing)

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.

When designing for a more ornate visual effect, it is easy to get caught up in the vicious circle of using more and more cascading components 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 to see the overdraw situation on the UI.

Blue, light green, light red, crimson represents 4 different degrees of overdraw, and our goal is to minimize the overdraw, to see more blue areas (the area on the blue surface is drawn once at the same frame time, light green indicates two times, and the next increment).

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.

3) Understanding VSYNC

To understand how the app is rendered, we have to understand how the mobile 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.

Unfortunately, the refresh rate and frame rate do not always keep the same rhythm. If there is an inconsistency between the frame rate and the refresh frequency, the phenomenon of tearing is prone to occur (the contents of the upper and lower part of the screen are broken, and the data from different two frames overlap).

In general, the frame rate exceeds the refresh rate is only an ideal condition, in the case of more than 60fps, the GPU generated frame data will be held to wait for VSync refresh information, so as to keep each refresh has actual new data can be displayed. But we are experiencing more cases where the frame rate is less than the refresh frequency.

In this case, some frames display the same screen content as the previous frame. The bad thing is, the frame rate from more than 60fps suddenly fell below 60fps, this will happen lag,jank,hitching, such as Kaka dropped frame of the situation. This is also the user feel bad reason (so the frame rate can be fast not slow, fast does not affect the rendering mechanism, but slow words will drop frames, of course, not dropped frames will affect the user experience (card, Dayton, slow), it does not appear to lag slow phenomenon before it may have dropped frames, but users have not found that Found to be due to a serious drop frame).

4) Tool:profile GPU Rendering

The performance problem is so troublesome, fortunately we can have tools to debug. Open the developer options in the phone, select the profile GPU Rendering, select on the screen as bars (some phones may not have this option, it may be because your mobile phone system is customized by the handset manufacturer, this option is deleted, this situation is recommended to use a third-party simulator, Or use another phone to debug) option.

After choosing this, we can see the rich GPU drawing information on the phone screen, respectively, about Statusbar,navbar, the GPU rending information of the active program activity area.

As the interface refreshes, the vertical histogram is scrolled to indicate the time required to render each frame, and the higher the histogram, the longer the rendering time is spent.

There is a green line in the middle, representing 16ms, and we need to make sure that the total time spent on each frame is lower than the horizontal line, so that the problem of stalling can be avoided.

Each bar has three parts, and blue represents the time to paint the display list (the layout file that parses the XML), and the red represents the time it takes for OpenGL to render the display list, and yellow represents the time the CPU waits for GPU processing.

5) Why 60fps? (why does the frame rate have to choose 60fps, not less?) ）

We usually refer to 60fps and 16ms, but do you know why it is a measure of app performance in terms of whether the program is up to 60fps? This is because collaboration between the human eye and the brain does not perceive more than 60fps of image updates (60fps is the best effect).

12fps is probably similar to manual fast-flipping the frame rate of a book, which is clearly perceived to be not smooth enough. 24fps makes the human eye aware of continuous linear motion, which is actually attributed to the effect of motion blur. 24fps is the frame rate commonly used in film aprons, as this frame rate is sufficient to support the content that most movie images need to express, while minimizing expense. But less than 30fps is not smooth performance of beautiful picture content, at this time need to use 60fps to achieve the desired effect, of course, more than 60fps is not necessary.

The performance goal of the development app is to keep 60fps (some less will not affect the user experience), which means that each frame you only have 16ms=1000/60 time to handle all the tasks (this time can be used to compare with TraceView time, not too much for example greater than 32ms, Otherwise, it should be optimized).

6) Android, UI and the GPU

Understanding how Android uses the GPU for screen rendering can help us better understand performance issues. So one of the most practical questions is: How does the activity picture go 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, requiring the CPU to be transformed into textures before being rendered to the GPU, returning to the CPU to draw a single character, then re-referencing the GPU-rendered content. Animation is a more complex process.

In order to make the app smooth, we need to process all CPU and GPU calculation, drawing, rendering and so on within each frame 16ms, the focus is to reduce the time of cup, because we write the program is directly executed in the cup, and the GPU is far from the relationship, generally not considered.

To summarize, here are the direct reasons that caused our app to slow down, but also the underlying reason, for other reasons such as memory leaks, time-consuming tasks in the main thread these problems are first affecting the android rendering mechanism. Then there will be lag slow phenomenon, it is accurate to affect the rendering mechanism cup related parts resulting in delayed operation. Once you know the reason, the specific measures for optimization are there.

Finally, out of respect for the purpose of the work of others, special note: about this series of blog is the author after reading another person's blog after writing, so more or less will have some shadow

That person's blog address:

http://hukai.me/android-performance-patterns/his blog, I feel very useful.

Android app Optimizer's direct reason for slow app lag