Source: Android Performance Patterns - Season 1 http://hukai.me/android-performance-patterns/
notes:
The Android system sends a VSYNC signal every 16ms to trigger the rendering of the UI. If each rendering is successful, the 60fps required for a smooth screen can be achieved. In order to achieve 60fps, this means that most operations of the program must be performed in Completed within 16ms. However, the layout is too complicated, there are too many drawing units stacked on the UI, and the animation is executed too many times, which will cause the CPU or GPU to be overloaded and cannot be completed within 16ms. There is a "Debug GPU Overdraw" function in the developer options for developers to debug.
Just by removing unnecessary background images, this can reduce a lot of red overdraw areas and increase the proportion of blue areas. This measure can significantly improve program performance.
Android needs to convert XML layout files into objects that the GPU can recognize and draw. This operation is done with the help of DisplayList. When a View needs to be rendered for the first time, the DisplayList will be created accordingly. When the View is to be displayed on the screen, we will execute the GPU drawing instructions for rendering. If you need to render the View again after performing operations such as moving the position of the View, we only need to perform an additional rendering instruction. However, any time the drawing content in the View changes, a series of operations such as creating the DisplayList, rendering the DisplayList, and updating it to the screen will be re-executed. The performance of this process depends on the complexity of your View, the state changes of the View, and the execution performance of the rendering pipeline.
For those custom Views with multiple sets of overlapping components that cannot be simplified, we can use canvas.clipRect() to help the system identify those visible areas, specify a rectangular area, only in this area will be drawn, other areas will be Ignore, the drawing commands outside the clipRect area will not be executed, and those components whose part of the content is within the rectangular area will still be drawn. So as to achieve the purpose of helping to save CPU and GPU resources.
Memory thrashing. Too many objects are created in the same frame. 1, Memory Churn memory jitter, memory jitter is because a large number of objects are created and immediately released in a short period of time. 2. A large number of objects generated in an instant will seriously occupy the memory area of Young Generation. When the threshold is reached and the remaining space is not enough, GC will also be triggered. Even if the objects allocated each time take up very little memory, their stacking will increase the pressure on the Heap, which will trigger more other types of GCs. This action has the potential to affect frame rate and make users perceive performance issues. For example, you need to avoid allocating objects in the for loop to occupy memory, you need to try to move the creation of objects outside the loop body, and the onDraw method in the custom View also needs attention. Every time the screen is drawn and the animation is executed, The onDraw method will be called to avoid performing complex operations and creating objects in the onDraw method. For those situations where it is unavoidable to create objects, we can consider the object pool model to solve the problem of frequent creation and destruction through the object pool, but here we need to pay attention to the need to manually release the objects in the object pool after the end of use.
Memory leak. First you need to use the Heap Tool to get a memory snapshot of the current state when the activity is in the foreground, then you need to create a blank activity that takes up almost no memory to jump to the previous activity, and then jump to this Actively call the System.gc() method when the activity is blank to ensure that a GC operation is triggered. Finally, if all the memory of the previous activity is properly freed, there should be no objects in the previous activity in the memory snapshot after the blank activity is started. If you find that there are some suspicious objects that are not freed in the memory snapshot of the blank activity, then you should use the Alocation Track Tool to carefully find the specific suspicious objects. We can start listening from a blank activity, start to observe the activity, and then go back to the blank activity to end listening. After doing this, we can look closely at those objects to find the real culprit of the memory leak.
To find memory performance issues, Android Studio provides tools to help developers.
Memory Monitor: View the memory occupied by the entire app and the time when GC occurs. A large number of GC operations in a short period of time is a dangerous signal.
Allocation Tracker: Use this tool to track memory allocations, as mentioned earlier.
Heap Tool: View the current memory snapshot, which is easy to compare and analyze which objects may be leaked. Please refer to the previous Case.
Battery optimization: ways to reduce battery consumption:
- We should try to reduce the number and duration of waking up the screen, use WakeLock to deal with the wake-up problem, and be able to correctly perform the wake-up operation and shut down the operation in time according to the settings to enter the sleep state.
- Some operations that do not have to be performed immediately, such as uploading songs, processing pictures, etc., can wait until the device is in a charging state or when the battery is fully charged.
- The operation that triggers the network request will keep the wireless signal for a period of time each time. We can package the scattered network requests for one operation to avoid the power consumption caused by too many wireless signals.
To summarize the above content: 1. The UI is as simple as possible; 2. It is possible to reduce the overdraw of the UI; 3. Use the API to limit the area; 4. Avoid memory jitter and leakage; 5. Power optimization