Android performance optimization memory

Google recently released an online course on Android performance optimization on Udacity, which introduces how to optimize performance from the aspects of rendering, computing, memory, and power. These courses are a refinement and supplement of the Android performance optimization classic course previously released by Google on Youtube.

The following are study notes for the memory chapter. Some of the content overlaps with the previous performance optimization examples. Everyone is welcome to study and communicate together!

1)Memory, GC, and Performance

As we all know, Java has a GC mechanism, which is different from C/C++, which requires manual coding to allocate and release memory. The Android system has a Generational Heap Memory model, and the system will perform different GC operations according to different memory data types in the memory. For example, recently allocated objects will be placed in the Young Generation area. Objects in this area are usually created quickly and destroyed and recycled quickly. At the same time, the GC operation speed of this area is also faster than that of the Old Generation area.

In addition to the speed difference, when performing GC operations, any operations of all threads will need to be paused and wait for the GC operation to complete before other operations can continue.

Generally speaking, a single GC does not take up too much time, but a large number of continuous GC operations will significantly occupy the frame interval time (16ms). If too many GC operations are performed in the frame interval time, then naturally other operations such as calculations and rendering will have less time available.

2) Memory Monitor Walkthrough

The Memory Monitor in Android Studio can help us view the memory usage of the program.

3)Memory Leaks

A memory leak is when objects that are no longer used cannot be reclaimed because they are incorrectly referenced.

Memory leaks will cause the remaining available Heap Size in the Memory Generation to become smaller and smaller, which will cause GC to be triggered frequently, further causing performance problems.

Take a memory leak as an example. The following init() method comes from a custom View:

 private   void init() {
 ListenerCollector collector = new ListenerCollector();
 collector.setListener( this , mListener);
 }

The above example is prone to memory leaks. If the activity is recreated because the device is flipped, the custom View will automatically rebind the newly created mListener to the ListenerCollector. However, when the activity is destroyed, mListener cannot be recycled.

4) Heap Viewer Walkthrough

The following figure demonstrates the function of Heap Viewer in Android Tools. We can see the Heap Size of the current process, what types of data there are, and what is the proportion.

5) Understanding Memory Churn

Memory Churn is caused by a large number of objects being created and released in a short period of time. The instantaneous generation of a large number of objects will seriously occupy the memory area of ​​the Young Generation. When the threshold is reached and there is not enough remaining space, GC will be triggered, causing the newly generated objects to be quickly recycled. Even if each allocated object occupies a small amount of memory, their accumulation will increase the pressure on the Heap, thereby triggering more other types of GC. This operation may affect the frame rate and make users perceive performance issues.

There is a simple and intuitive way to solve the above problem. If you see multiple increases and decreases in memory in a short period of time in Memory Monitor, it means that memory jitter is likely to have occurred.

At the same time, we can also use Allocation Tracker to see the same objects constantly entering and exiting the same stack in a short period of time. This is one of the typical signs of memory jitter.

Once you have roughly located the problem, the next step to fix the problem will be relatively straightforward. For example, you need to avoid allocating objects in the for loop to occupy memory, and try to move the creation of objects outside the loop body. You also need to pay attention to the onDraw method in the custom View. The onDraw method will be called every time the screen is drawn and the animation is executed. Avoid performing complex operations in the onDraw method and avoid creating objects. For those situations where it is unavoidable to create objects, we can consider the object pool model, which can solve the problem of frequent creation and destruction through the object pool. However, it should be noted that after use, the objects in the object pool need to be manually released.

6)Allocation Tracker

Regarding the use of the Allocation Tracker tool, I will not expand it. Please refer to the following link:

http://developer.android.com/tools/debugging/ddms.html#alloc

http://android-developers.blogspot.com/2009/02/track-memory-allocations.html

7)Improve Your Code To Reduce Churn

The following example shows how to avoid memory jitter by modifying the code. Memory detection diagram before optimization:

After locating the code, the String concatenation problem was fixed:

Memory monitoring chart after optimization:

8)Recap

The three tools for measuring memory are mentioned above. Here is a brief summary of their respective characteristics:

Memory Monitor: Track memory changes of the entire app.

Heap Viewer: View the current memory snapshot to facilitate comparative analysis of which objects may have leaked.

Allocation Tracker: Tracks the origin of memory objects.