UI Caton Principle:
"60fps (Frames Per Second) ----> 16ms"
For the numbers marked in red above, the following is a detailed explanation: The main root is rendering. Android will send a signal every 16ms to trigger the rendering of the UI. If the rendering is successful every time, it will achieve the required smooth screen. 60fps, that is, 60 stitches per second. In order to achieve 60fps, most operations of the program must be completed within 16ms, that is, 1000ms/60=16ms. Why should the standard be set at 60fps? The human brain has certain restrictions on the continuity of the picture, and the android system sets this smooth frame rate at 60fps, which is the number of frames per second, which is 16ms per frame, which is 60 frames per second. frame, so in order to ensure that the number of frames is not lost, we must process this CPU and GPU computing and rendering operations within 16ms. In addition, we need to know that when the Dalvik virtual machine reaches the GC, all threads will be suspended, so the GC After finishing, the thread can continue to execute, that is to say, if a large number of GC operations happen to be encountered when the interface is rendered in 16ms, the rendering time will be insufficient, and the page will cause a stuck problem.
Overdraw (overdraw): The reason for this is that there are a lot of overlapping parts in the UI layout. For example, there is a background in the Activity, and the View also has its own background. Similar to this, it is easy to cause overdrawing. This can be obtained from the developer. Observation in the options, reduce the red part, try to only have the green part.
UI Caton Cause Analysis:
- Artificially doing slightly time-consuming operations in the UI thread, causing the UI thread to freeze.
- Layout is too complex to render in 16ms.
- The animation is executed too many times at the same time, causing the CPU or GPU to be overloaded.
- Views are overdrawn, causing certain pixels to be drawn multiple times in the same frame time, overloading the CPU or GPU.
- View frequently triggers measure and layout, which leads to excessive time-consuming of measure and layout and frequent re-rendering of the entire View.
- Memory frequently triggers too many GCs, causing temporary blocking of rendering operations.
- Redundant resources and logic lead to slow loading and execution, and good coding habits can also improve UI performance.
- ANR。
UI Caton Summary:
- Layout optimization: use merge, viewStub titles; try not to have redundant nesting and overly complex layouts; if the layout is general, you can use include to import; try to use GONE to replace INVIsible, because the invisible interface will still be drawn; try to replace it with weight Length and width; if the Item has very complex nesting, consider using a custom View to improve it to reduce the number of measures and layouts and improve performance.
- List and Adapter optimization: Using cache and sliding monitoring, the UI is not updated when sliding.
- Memory allocation optimizations such as backgrounds and images.
- Avoid ANRs.