HUNTING YOUR LEAKS: MEMORY MANAGEMENT IN ANDROID (PART 2 OF 2)
2015-03-09 12:01
543 查看
Woo-hoo! Now you know what is happening with your app’s memory usage when you see one of those OOM exception. But, you don’t know where to find the source. Let alone, how to fix it.
Tracking down memory issues can be a pain in the neck. Here are a few strategies that will help you as you pursue the noble craft of Android-igami.
Sample project
There are code snippets and screenshots of what I’m working on sprinkled throughout this post. These will come from a single sample project, and if you prefer to see things in their entirety before being divided into little pieces, I provided that sample project to download here.
Yes, it uses Eclipse. Sorry to all you cutting edge folks working with the still beta Android Studio.
Structure: One activity, with a fragment. You’ll see an image that turns on and off every 5 seconds.
We’re using a singleton manager to keep time for us, and notify the Fragment when it’s time to switch the image on or off.
For those keeping score at home, this project has one A-level memory leak: the type of leak that no developer should ever allow into their code. And I’m not going to tell you where it is. But, that’s the purpose of this experiment! So let’s take a look at where it goes wrong.
![](http://images.cnitblog.com/blog2015/240739/201503/091153076599968.png)
Open the DDMS1 Perspective in Eclipse (It should be found somewhere around the
Highlight the process you wish to profile (most real devices will only show “debug”-signed processes, so you’d only see it on a real device if you built and installed from
Tap the little green “disk” icon (circled in above image), named “Update Heap.”
Make sure you open the Heap panel on the right side of the screen.
Tap the “Cause GC” button2.
This will put some numbers in that chart. The one we should focus on is “Allocated,” which shows you how much memory the Dalvik VM currently has given your app. This can stretch and shrink a bit, but there’s an upper limit (the size of which depends on the device). If you exceed the upper limit, you pop out an OOM and the app crashes.
This is a great tool to keep an eye on while you develop, since it shows a live snapshot of the system after any garbage collection cycle. If you ever notice the allocated memory gradually increasing without ever letting anything go, that’s a good indication that you might have a memory leak.3
“MAT,” the Eclipse Memory Analyzer tool, can read a file that your virtual machine generates (Remember that one we talked about in the last post? It’s called Dalvik). That file, called a “heap dump,” represents the set of all objects currently stored on your process’s heap4. That means you can actually poke around the metadata of the objects you’re using during runtime.
What you’ll need:
Eclipse (the Google provided “ADT” version works well here).
MAT.
If you’re not using the DDMS plugin, you’ll need to manually convert the Dalvik profile into an
Java
That’s good. Now leave it for a bit, because it could take a couple of minutes to generate (and the emulator is frozen until it finishes).
Once the output is ready, it should prompt you about some different types of reports. (If you instead see a prompt to save a file, go ahead and save it somewhere, then use the SDK tool hprof-conv to convert it to the appropriate format, and manually open it with Eclipse’s MAT). Once you have the “reports” prompt, just cancel out of it — we’re not going to use any pre-set reports for this.
![](http://images.cnitblog.com/blog2015/240739/201503/091155472682931.png)
You’re looking at the name and package of the objects in the first column, the number of that kind of object in existence at the moment in the next column and then some representation of the total heap sizes in the third and fourth columns6.
It might be interesting to sort by size or count to see where the majority of memory is being used in your code7. If you right-click on one of these listings, you can get some cool options, like all instances of objects of that type with all the references that keep it from being garbage collected.
![](http://images.cnitblog.com/blog2015/240739/201503/091156316436321.png)
But wait, we’re supposed to be hunting for something, right? We need a target of some kind.
First, try applying filtering to this list. In the first row, you can enter text. Since you almost always want to take a closer look at your code, I suggest entering something like “com.example.memoryleek”. This should filter down to a handful of entries.
![](http://images.cnitblog.com/blog2015/240739/201503/091156576748339.png)
Gazing upon these, I’m hoping you notice something horrifying. If you don’t, I recommend taking another look at Part 1 of this series. Hopefully you will figure out what the worst thing in the world to leak would be.
Hint: it’s Activities.
And, good Lord, I have 24 instances of LeekActivity right now! That’s totally not OK.
Why might this be?
Well, kindly, MAT has a way to tell us. You can right-click that list item, and select “Merge Shortest Paths to GC Roots”, excluding WeakReferences (remember, WeakReferences will have no effect on what is retained). This means we want to see what memory root all these objects have in common. That should indicate if there’s something retaining all of them at once, ergo, a leak of some kind!
![](http://images.cnitblog.com/blog2015/240739/201503/091157522993994.png)
In this case, there are 3 roots. Two of them are external to this project, so aren’t likely culprits. But, that LeekManager instance looks suspicious….
A-Ha! If you open it up, you can see that there’s a LinkedList called “listeners” on LeekManager that has a reference to all of those Activities.
But, where did that come from?
Well, check this out:
Every time our
Now, the above code looks like:
And when we run the app, we don’t see any more indications of leaky memory! Hoorah!
Tracking down memory issues can be a pain in the neck. Here are a few strategies that will help you as you pursue the noble craft of Android-igami.
Sample project
There are code snippets and screenshots of what I’m working on sprinkled throughout this post. These will come from a single sample project, and if you prefer to see things in their entirety before being divided into little pieces, I provided that sample project to download here.
Yes, it uses Eclipse. Sorry to all you cutting edge folks working with the still beta Android Studio.
Structure: One activity, with a fragment. You’ll see an image that turns on and off every 5 seconds.
We’re using a singleton manager to keep time for us, and notify the Fragment when it’s time to switch the image on or off.
For those keeping score at home, this project has one A-level memory leak: the type of leak that no developer should ever allow into their code. And I’m not going to tell you where it is. But, that’s the purpose of this experiment! So let’s take a look at where it goes wrong.
EXAMINATION 1: “UPDATE HEAP” BUTTON
![](http://images.cnitblog.com/blog2015/240739/201503/091153076599968.png)
Open the DDMS1 Perspective in Eclipse (It should be found somewhere around the
Window->Open Perspective->Otherpopup dialog).
Highlight the process you wish to profile (most real devices will only show “debug”-signed processes, so you’d only see it on a real device if you built and installed from
adb).
Tap the little green “disk” icon (circled in above image), named “Update Heap.”
Make sure you open the Heap panel on the right side of the screen.
Tap the “Cause GC” button2.
This will put some numbers in that chart. The one we should focus on is “Allocated,” which shows you how much memory the Dalvik VM currently has given your app. This can stretch and shrink a bit, but there’s an upper limit (the size of which depends on the device). If you exceed the upper limit, you pop out an OOM and the app crashes.
This is a great tool to keep an eye on while you develop, since it shows a live snapshot of the system after any garbage collection cycle. If you ever notice the allocated memory gradually increasing without ever letting anything go, that’s a good indication that you might have a memory leak.3
EXAMINATION 2: MAT & HPROF — A.K.A., “THE HUNT”
There are some acronyms for you, huh?“MAT,” the Eclipse Memory Analyzer tool, can read a file that your virtual machine generates (Remember that one we talked about in the last post? It’s called Dalvik). That file, called a “heap dump,” represents the set of all objects currently stored on your process’s heap4. That means you can actually poke around the metadata of the objects you’re using during runtime.
What you’ll need:
Eclipse (the Google provided “ADT” version works well here).
MAT.
If you’re not using the DDMS plugin, you’ll need to manually convert the Dalvik profile into an
.hproffile.
Plot a course
Run the MemoryLeek project on an emulator5. You should see a white screen with a slowly blinking image. Rotate the emulator ten or so times (either7on the numpad or
Cntrl+
F12). Now, return to Eclipse, and open the DDMS perspective once again. This time, we’re aiming for the green disc icon with an arrow attached — indicating you want to generate a heap dump. Go ahead and click it, and you should see a statement in the Android log that looks like:
Java
1 | I/dalvikvm(1948): hprof: dumping heap strings to "[DDMS]". |
Once the output is ready, it should prompt you about some different types of reports. (If you instead see a prompt to save a file, go ahead and save it somewhere, then use the SDK tool hprof-conv to convert it to the appropriate format, and manually open it with Eclipse’s MAT). Once you have the “reports” prompt, just cancel out of it — we’re not going to use any pre-set reports for this.
Load your ammo
Hooray! If you’re reading this, you’re hopefully looking at some kind of graph of your app’s current memory state. In my case, a pie chart.![](http://images.cnitblog.com/blog2015/240739/201503/091155472682931.png)
Now what?
Let’s try poking around a bit. Click the little bar chart icon in the top left, that says “Create a histogram…” when you hover over it. This will show you a list of all the objects currently allocated, in no particular order.You’re looking at the name and package of the objects in the first column, the number of that kind of object in existence at the moment in the next column and then some representation of the total heap sizes in the third and fourth columns6.
It might be interesting to sort by size or count to see where the majority of memory is being used in your code7. If you right-click on one of these listings, you can get some cool options, like all instances of objects of that type with all the references that keep it from being garbage collected.
![](http://images.cnitblog.com/blog2015/240739/201503/091156316436321.png)
But wait, we’re supposed to be hunting for something, right? We need a target of some kind.
Tracking the game
There’s a lot of noise in an app’s memory space. Fortunately, we can narrow it down in a few ways.First, try applying filtering to this list. In the first row, you can enter text. Since you almost always want to take a closer look at your code, I suggest entering something like “com.example.memoryleek”. This should filter down to a handful of entries.
![](http://images.cnitblog.com/blog2015/240739/201503/091156576748339.png)
Gazing upon these, I’m hoping you notice something horrifying. If you don’t, I recommend taking another look at Part 1 of this series. Hopefully you will figure out what the worst thing in the world to leak would be.
Hint: it’s Activities.
And, good Lord, I have 24 instances of LeekActivity right now! That’s totally not OK.
Why might this be?
Well, kindly, MAT has a way to tell us. You can right-click that list item, and select “Merge Shortest Paths to GC Roots”, excluding WeakReferences (remember, WeakReferences will have no effect on what is retained). This means we want to see what memory root all these objects have in common. That should indicate if there’s something retaining all of them at once, ergo, a leak of some kind!
![](http://images.cnitblog.com/blog2015/240739/201503/091157522993994.png)
In this case, there are 3 roots. Two of them are external to this project, so aren’t likely culprits. But, that LeekManager instance looks suspicious….
A-Ha! If you open it up, you can see that there’s a LinkedList called “listeners” on LeekManager that has a reference to all of those Activities.
But, where did that come from?
Well, check this out:
// In LeekFragment.class: @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Add this fragment as a leek listener so // it can update its view accordingly LeekManager.get().addListener(this); }
Every time our
LeekFragmentis created, we add it as a
LeekListenerto the
LeekManagersingleton. But, when we did those rotations, the Fragment was never removed as a listener. The Fragment has a reference to the parent Activity, and the parent
LeekActivityhas references to all the other view elements.
Taking the shot
There’s our leak. Fixing it? Easy:LeekFragmentneeds to be removed from
LeekManagerupon its
onDestroy()lifecycle method.
Now, the above code looks like:
// In LeekFragment.class: @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Add this fragment as a leek listener so // it can update its view accordingly LeekManager.get().addListener(this); }
@Override
public void onDestroy() {
super.onDestroy();
LeekManager.get().removeListener(this);
}
And when we run the app, we don’t see any more indications of leaky memory! Hoorah!
相关文章推荐
- HUNTING YOUR LEAKS: MEMORY MANAGEMENT IN ANDROID
- Wrangling Dalvik: Memory Management in Android (Part 1 of 2)
- Out Of Memory Error in Android - part 1
- 内存泄露 Analyzing the memory usage of your Android application
- An overview of memory management in QEMU
- How to discover memory usage of my application in Android
- eclipse创建android项目,无法正常预览布局文件,出现This version of the rendering library is more recent than your version of ADT plug-in. Please update ADT plug-in...
- Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework垃圾回收:在微软NET框架自动内存管理 (二)
- javax.management.MalformedObjectNameException: Invalid character '' in value part of property ,Oracle 驱动包的错误
- C#Memory Management for Unity Developers(Part 1 of 3)
- Hunting Memory Leaks in Java
- On Memory Leaks in Java and in Android.
- How to discover memory usage of my application in Android
- javax.management.MalformedObjectNameException: Invalid character '\n' in value part of property
- C#Memory Management for Unity Developers (part 2 of 3)
- Analyzing the memory usage of your Android application
- How to discover memory usage of my application in Android
- Openmpi使用Infiniband中” only allow registering part of your physical memory“问题
- out of memory logs in android app
- 133 You want to enable automatic PGA memory management in your database. Which setting is required t