Debugging memory issues with Android Studio

http://blog.csdn.net/yutao52shi/article/details/50055669

Objective

Memory problems are always painful for Android developers. If an Android programmer says he has not met OutOfMemory, it can only be said that he is definitely not an android. Historically, in the ADT era, we used Eclipse's Mat (http://www.eclipse.org/mat/) plugin for memory analysis. With the development of Android studio, we found that as not only brought a lot of coding convenience, but also brought a lot of useful tools. One of the memory analysis tools is a classic.

Body

Open as, in the bottom of the Android Monitor can be found in the Memory tab, in the real-time to see the movement of memories, can be found in the self-test where the memory explosion, but also easy to see the GC point (memory suddenly dropped a large section, Must have done full GC).

See on the right there are 4 buttons, the first is a pause, temporarily do not do any explanation. The following is a detailed explanation of the functions of the other three buttons.

Initial GC

This command will let the app execute a full GC. This feature does not use a lot of scenarios, I usually do it before the dump heap, which reduces many useless objects. Once clicked, there are times when memory changes can be clearly seen

Dump Java Heap

This function is the most I use, but also think the best use of memory analysis function. Because it is basically able to see which objects occupy a huge amount of memory, and can find out what objects they are holding, resulting in the inability to release. After clicking on the dump Java Heap, the app will freeze live. Then wait, it's better not to do anything else at this time, or it might fail. After about a few 10 seconds, it will go into the interface to read the Hprof file.

From the way can be basically seen, there is a 10Mac size bitmap by the gpuimage inside the module control (due to be confused, so the class name is F). With this information, the vast majority of oom problems can be solved.

Start Allocation Tracking

This function can record the memory allocation of each method of each thread in a certain interval. I'm not using much, mainly for debugging a case where there is a frequent GC in a complex system with a short memory burst. How to use: Click once, then you will see the memory recorder start to rotate, and then start on the app to do the corresponding action. Point again at the right time and end the record.

Then the app will be freeze and will go into the open interface of the Alloc file in a moment. By analyzing the alloc data, we can know the heap size allocated by all the called methods within a thread, which allows us to optimize for the method-level heap program.

Off Topic

In addition to instant dump instant view, we can also use as direct open. Hprof and. alloc files, it is very convenient to open some other personnel (such as QA) dump out of heap dump.
In addition, these tools, although in the previous Ddms also brought, but personally feel in as inside some improvement, the interface is very concise, key data at a glance. Basically can meet the daily production needs. But if you want to do more in-depth analysis, still need to use external tools, as the hprof viewing tool is far from the mat data detail, but provides some key data.

Debugging memory issues with Android Studio