Android Memory leak analysis Tips

Java Virtual machine run generally have a memory limit, beyond this limit, will be reported OutOfMemory. There is usually a memory leak at this time. Resolving a memory leak is a two-step process: Analyzing whether an application really has a memory leak and finding a memory leak. These two steps are not the general sense of debugging, directly hit log, breakpoint debugging is not too force. Think about it, memory problems should appear in many places, so common problems should be tools. Android is now more of an ecosystem, and of course there are many development aids. In the previous two steps have a very powerful weapon, skilled grasp these weapons, analysis of the problem will be more effective.

Analyze if there is a memory leak: adb shell dumpsys meminfo package_name (adb shell Dumpsys meminfo pid)

As shown, you can see the memory footprint of the current app directly. In most cases, we are concerned with the 122 columns of line 122. If we suspect that an interface has a memory leak, it can be judged by the following methods. Repeat this step several times, and then look at the memory usage before and after the execution. If there is a noticeable increase in memory and there is no recovery over time, it is essential to confirm that there is a memory leak in the code.
        Analyze for memory leaks two: DDMS real-time view, note to show all the system processes on DDMS, this requires the phone has root permissions.
Select the process to analyze, go to the heap interface, click the Cause GC button, and the interface will refresh periodically. In general, just focus on the data object line, this is the memory our object occupies. The memory leak in Java is that the object is not released in time and cannot be GC. Focusing on data object generally directly concerns total size, depending on the size of this value to determine whether there is currently a memory leak. Also repeat an action for a period of time, observing that the total size of the data object has a significant increase in wood.
        The two methods above are the analysis of the use of wood memory leaks, the main idea is to repeat an operation, to see that there is no significant growth in the existence, and did not recover. Normal application will be stable in a small range, the problem of the application is generally continuous growth, it is difficult to recover. Two tools, one is manual refresh, one is automatic refresh, compared to the author recommended the first method. Manual control, feel better.
        Discovering that there is a memory leak in your app is not enough, and our ultimate goal is 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, which can generate HPROF files directly.
        If the mat plugin is already installed on eclipse, this file is opened at the same time as the build. However, the individual likes to use the mat alone, feeling faster and more convenient. 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. If a class has too many objects, basically the memory leak generated by this class, find where to allocate objects, 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 changes in the place are a dose of medicine, can begin to pay attention to avoid subsequent analysis is the best.