Analyze if there is a memory leak: adb shell dumpsys meminfo package_name (adb shell Dumpsys meminfo pid)
As you can see, the memory footprint of the current application is directly visible. In most cases, we are concerned with the 122 columns of line 122. Suppose we suspect that an interface has a memory leak and can be inferred by the following method. Run this step repeatedly several times, and then look at the memory usage before and after the run. Assuming there is a noticeable increase in memory, and there is no recovery over time, it is essential to be able to confirm where there is a memory leak in the code.
Analyze if there is a memory leak two: DDMS real-time view, note to show the system all processes on DDMS, this need to have root access to the phone.
Select the process to analyze, go to the heap interface, click Cause Gcbutton, and the interface will refresh periodically. In general, just focus on the data object line, which is the memory that our objects occupy. The memory leak in Java is that the object is not released in time and cannot be GC. Focusing on data object generally focuses directly on total size, based on the increase in the size of this value to infer whether there is currently a memory leak. The same is repeated over a period of time to operate an action, observing the total size of data object has a significant increase in wood.
The above two methods are the analysis of the use of wood has a memory leak problem, the main idea is to repeat a certain operation, to see that there is no significant growth in the existence, and no recovery. Normal application will be stable in a small range, the problem of the application is generally continuous growth, very difficult to recover. Two tools, one is a manual refresh, one is the active refresh, compared to the author recommended the first method. Manual control, feel better.
Discovering that there is a memory leak in the app is not enough, and we are finally aiming to solve the problem. This is where you need to find a memory leak. Eclipse has provided us with a powerful memory analysis tool Mat, which is: http://www.eclipse.org/mat/. Before using this tool, build a hprof file that records the process memory division and use mat to analyze memory usage. There is a dump HPROF file button on the DDMS that will generate the HPROF file directly.
Assuming that the mat plugin is already installed on eclipse, this file is opened at the same time as the build. It's just someone who likes to use the mat alone, and it feels quicker and easier. After the mat has opened the Hprof file, it will be able to display the current memory consumption graph.
The circular image in this diagram shows where the memory is currently occupying the most. General memory leaks are in these few places. There is a link to the leak suspects, click to see the details, you can see which objects occupy the memory. Suppose that a class has too many objects, basically the memory leak generated by this class, find the place to allocate objects, very quickly find out where the logic is not robust, after the use of the memory is not released in a timely manner.
Analysis of memory leaks, to find a place to change is a good medicine, you can start from the attention to avoid the analysis is the best.
Android Memory leak analysis Tips