Android-Learn how to solve memory leaks with real-life cases, and eventually discover Android native bugs

As a novice Android small white, just to the new company, the recent job is to learn to solve various kinds of bugs. At the beginning of the transformation, faced with a variety of new knowledge, there will be pressure, but the process of learning is happy.

One of the first bugs that happened last week was the memory leak of the application. Finally through the guidance of the predecessor, took two days (including today), to solve the problem, and finally found the Android native code bug (Happy ...) ）。 So the process of learning is summed up, can be like me as a new reference learning.

I. Background to the problem discovery

The QA test found that when an activity in the Setup feature was opened multiple times in the Android system, the resources it occupied failed to release, and after two hundred or three hundred repeated operations, the crash of the app was set.

The cause of the crash is the Oom problem, which is that the resource used is not being recycled by GC, causing insufficient memory, throwing out an oom (out of memory) exception, and applying crash.

So the next step is rd to solve the problem!

Two. Tools that need to be prepared/mastered

With no tools, it's hard to deal with and solve problems easily. After the guidance of our predecessors, we began to learn to use a series of tools to solve such problems.

1. Adb shell command

Android Novice must first start from ADB, ADB full name is Android Debug Bridge, provides a lot of operation of the phone commands, with it, can be convenient debug problems. Here we use the following commands,

A. adb Shell

Enter the ADB shell and execute the following command

B. Am start-a "xxx"-D "xxx"

Open activity with Activity manager to facilitate multiple tests and investigate process memory usage

C. Dumpsys meminfo xxx

To view the memory consumption of a process, XXX is the package name

　　 2. DDMS + Mat Tool

DDMS full name is Dalvik Debug Monitor Service, generally I use it to view the instant log, the role here is to use DDMS to generate hprof files , hprof is the heap snapshot of the Android process, with it, You can study which objects exist in the heap, as well as the reference to object, to investigate why the GC does not reclaim the object.

The Mat tool, which is provided by Eclipse, is a convenient tool to analyze hprof files. The mat is the Memory Analyzer tool, which is installed in Eclipse, select Install new software, and then provide the URL of the plugin and choose the installation.

　　 So here's our idea that test and reproduce the problem with the ADB shell command, then use DDMS to crawl the heap snapshot, use the mat to analyze the heap snapshot, and never solve the problem against the code.

Three. Procedures for resolving this memory leak problem

1. Reproduce the problem, open the activity directly via the AM Start command, and repeat the process multiple times by pressing the phone's return key.

2. During step one, use the dumpsys meminfo com.android.settings command each time to observe the number of activity in the heap.

Under normal circumstances, the activity value should be 0 or 1, should not continue to grow, because after the return, if there is no memory leak, the useless activity object will be GC (garbage collection) to be recycled.

But here, as there are problems, I observe that thenumber of activity has been increasing . As shown, the number of activity in the heap changes:

Step one operation 1 times,

Operation 2 times,

Operation 5 times,

Can obviously see the occurrence of the problem, that is, during each of our operations, the activity has passed the return key, not display, but the resource is not collected by GC, each operation will generate a new not and will not be released the activity object, a memory leak occurred!

So the next step is to solve the problem.

3. Use Ddms+mat to find clues and solve problems

Now that the scene has been reproduced, we need to use DDMS to generate the Hprof file, It is mentioned that if you are using the DDMS and Mat tools installed in Eclipse, clicking on the Generate Hprof file in Ddms will automatically associate the mat. Use the mat to open this file.

Ddms generate Hprof file, click on the 2 green buttons, as below,

Mat Open the Hprof file, open the proposal to select the first item, as below,

After opening, you can analyze the heap file. Here we choose, click Dominator Tree, which lists the largest objects in the heap,

Then, on the page that opens, select the activity (you can use keywords to filter the results) that you found in your test, where the problem is, Appdrawoverlaysettingsactivity (Android native code), The corresponding fragment is drawoverlaydetails. Since we have operated 5 times, we can see that 5 objects in the heap are present and are not released.

　　　

To analyze the reason why it was not released, use the function of the mat to parse the object's reference because the strongly referenced object is not recycled by the GC. Since this activity object has always existed, it must have been referenced, causing it to not be recycled by GC.

My approach is to right-click on object and click on Merge shortest Paths to GC Roots - exclude all phantom/week/soft etc. Preferences( Because you want to exclude weak references, as well as soft references, the objects contained in these references will be recycled by GC and have no reference value to us.

Then we can find out why,

By looking at its reference, it is found that there is a suspicious msession variable that belongs to the activity's parent class, uses the current object in the class, but has failed to release it, so this is the cause of the problem, causing the GC to fail to reclaim the resource.

Knowing the cause, the solution is simple, which is to release the Msession object in the Onstory or Ondetach method that is triggered by the return key. The problem will eventually be solved.

1    @Override 2      Public void OnDestroy () {3         Super . OnDestroy (); 4         msession.release (); 5     }

Finally commit the changes, in the new APK test, through the ADB shell command test found that the number of activity has been maintained normal, the memory leak problem has been resolved.

Finally, to solve the problem of memory leaks, it is important to use commands and tools skillfully. With their help, they can quickly find clues, and then go to the code to find the problem. Of course, the complexity of the problem, far from the process of this article to solve the simple, but for the novice, learning this method step will be a great help!

-Kevin Song

May 9, 2016

Android-Learn how to solve memory leaks with real-life cases, and eventually discover Android native bugs