I have a strange memory behavior in an Android application I'm developing. The application is running fine, but if I look to a "task manager" in Android, like the Samsung SII task manager or the "Memory Usage" application on a Nexus 7 it shows that while using the app the amount of memory used is rapidly growing to an insane amount, like hundreds of megas (600~700MB on the Nexus 7). Then it can fall down back to about 200MB, grow again etc.
At first I thought that I had a bad memory leak and started to search for the problem in the Eclipse Memory Analyzer (MAT) like it is explained in this excellent video. But the problem is that from here everything looks ok. I didn't find any duplicate instance of an activity or anything else that could cause the leak, and the reported amount of memory used is a lot smaller. The problem also doesn't appear in the GC messages. So I can have a 600MB use reported in the Task manager, and something like this in Logcat:
01-29 12:05:44.511: D/dalvikvm(6044): GC_FOR_ALLOC freed 3930K, 24% free 28959K/38096K, paused 17ms, total 17ms
with a heap amount never going above 50~60MB (which could be normal because there are lots of pictures in the app). Numbers in MAT match.
I would like to bu sure that there is a memory leak or not in my application. Even if GC messages and MAT don't report problems, I find it really strange that the task managers report such a high memory usage. Maybe someone here already faced such a strange behavior and could give me a clue about what is happening?
The GC messages only show what's on the Dalvik heap. The native heap can grow without bound -- until the system decides to kill you, which it is reluctant to do so long as you're in the foreground. Does your app have a native component that could be causing the allocations?
If this is a developer / rooted device, the "procrank" tool can give you a quick summary of memory usage. The "showmap " tool can give you a more detailed breakdown.
DDMS has some (officially unsupported) tools for examining native memory usage. Google for "ddms native heap" to find some instructions.
Ok, after hours of testing I've finally found the problem. As guessed by fadden, the leak was out of the Dalvik's scope. It was in fact due to the following bug in Typeface.createFromAsset:
http://code.google.com/p/android/issues/detail?id=9904
This method is leaking asset stream. My app is using a custom TextView to display text with custom fonts, and as it is used in most of the layout files it was rapidly leaking a lot of RAM, but not in Dalvik's heap, so it was really difficult to spot using the usual tools.
Related
I encountered an issue with a leak on the in android's native heap in my app. The leak seems to come from LinkedBlockingQueue that is just keep growing without being cleaned up.
If you look at the look below, the native heap has a total of 478M and it keeps growing (it started from 20M and it keeps growing by around 250k every few seconds). The JVM heap is working correctly and stays at a the same levels around 100M. My app uses its own network code but even with it turned off and the app just "sits" there it still have this leak.
I have identified that the LinkedBlockingQueues are point to an com.android.okhttp.ConnectionPool instance (the same one). I don't use okhttp anywhere in my code. I do use firebase with config, database and storage support. But with the exception of the config that has attached listener the other services are not while I'm testing.
The snapshot below shows my java heap dump. The LinkedBlockingQueue has 6029 instances and almost 300M of retained memory. This number grows with the native heap increase so I'm assuming they are related.
The snapshot below shows one of the LinkedBlockingQueue$Node instances where the item is the connection pool. They all look the same and pointing to the same item.
I never encountered a memory leak like that and not sure what is the reason for it. I would appreciate if any of you have any thoughts of what it could be or if you had an issue like that before.
I figured it out. This had nothing to do with my app or firebase. It seems that Android Studio with ADB Integration may have been the cause.
When I disable the integration and used Android Device Monitor for memory and getting the logs. The native heap doesn't grow and stays at around the same levels.
Why does DDMS and Android's Running App (Settings->Apps->Running) show another allocated memory value?
DDMS shows that my application allocated memory size is equal ~40MB, on the other hand the Running App shows 80MB.
Which one value is correct? If DDMS value is correct how can I enforce the Running App to show correct value.
There is similar question, but answers are not enough for me.
I answer on my own question.
DDMS shows memory utilized only by Dalvik. The Running App show all memory which is utilized by application it is the sum of:
Native Heap
Dalvik Heap
Dalvik Other
Stack
Other dev
Graphics
and much more, in order to get detailed information about utilized memory please read Viewing Overall Memory Allocations.
I'm making a basic android application, but it is suffering from a LOT of garbage collection (the GC kicks in 4-5 times every second). I tried looking for the root cause and realized that my app has almost no memory as soon as the onCreate function is called.
As soon as the app starts, the DDMS shows almost 91% of the heap being used, mostly by 1-byte arrays. I also ran the memory analysis tool to see if I was leaking memory or something, and even after executing the app, it shows that most of the memory is used up by android.content.res.resources.
Why is my application losing so much memory to resources? The ONLY resource that my app has is a small JPEG image of 22KB. I read elsewhere that sometimes the free heap is misreported because of shared resources etc, but then the GC shouldn't kick in as often as it does when the app is running. Can someone help?
FWIW, the very same app run on a Galaxy S3 shows about 20% heap usage at the start, even though it shows the same amount of total memory (~10 MB). The problematic phone is a Galaxy S2.
Upgraded the phone to Cyanogenmod 10.1, and now the heap usage is ~30% at the start and the GC doesn't kick in anymore. Maybe a bug in the Samsung firmware?
I'm developing a large project with android technology
sometimes I have some exceptions like (Out Of Memory Error) on small devices
what I do when an exception occurred is to re-open the application
what happen that it leaves the previous process open and open a new process with new instance of application
I have tried to make
finish()
kill process
System.exit
to close the application and re-open it again but nothing works for me
any help please ???
First Thing you have to take care of, is Heap size.. You can track How much memory is getting consumed when your are running application. Under DDMS perspective there is a heap tab which will give you info about how much memory is consumed when you are running your application.
on what version of the android you are testing ? Android Os will allocate some memory for each application to run.In android 2.2 16mb will be allocated for one application. Version 2.3 allocates 24Mb for an application ,Android 3.0 allocates 42Mb. try testing on different versions of android, you will get to know..
Out of memory happens when RAM in a device is utilized fully, the system will throw this error and kill/restart the process. You need to find the appropriate place where you use the most of memory and handle the memory properly. Out of Memory generally happens because of poor bitmap/image handling. Check your code where you handle Bitmaps/ImageViews/PNG's etc.
Android default heap size is almost good for every heavy load jobs. Trace your code and find memory consuming parts of your code and try to optimize them. To do so, use HEAP tab in DDMS view in Eclipse.
yes that is the problem .i have faced similar problem recently then i resized my images then my problem is solved.Try to find out a way how to reduce the size of the images which you are loading from sever side back-end.
I am developing a game application under Android built for SDKs >= 8. I always tested it under an Android 2.2 phone and never had a problem. When I moved to a Nexus phone with ICS mounted on I started having problems with the heap memory allocation. I tried to remove everything in the app to see where I was having memory leak problems or strange allocations (using both DDMS and MAT under Eclipse) until I decided to just start an empty activity and to do nothing more.
Under Android 2.2 the heap size at startup is about 2.0MB, while under Android 4.1 is about 11MB. Why is there such a great difference?
More, when I play my app the heap size on ICS, the garbage collector quickly starts freeing memory and the whole application becomes slow and with a very low FPS. Under Android 2.2 everything is really smooth and clean, without any single problem.
Does anyone can suggest me where's the difference between these two systems? I don't want to talk about my app implementation (I already spent 2 weeks optimizing code, memory allocation and retention and everything else. Can't do much more), but I want to understand where all that memory goes just at app startup. Also, ICS seems to require much more memory to load and retain bitmaps and drawables.
Okay, I may be late to the party, but I figured out the root of your (and my) problem.
Before Android 3.0 (not sure if this was in the entire 1.x/2.x series) all bitmap related memory was not stored on the heap. So with 3.0 they started locating everything on the heap. I am not sure why an empty application takes up 11MB, I can only guess it is related to the default Android bitmaps used in applications.
Now there is another problem: in earlier versions of Android, there was only a 'drawable' folder, not a 'drawable-hdpi', 'drawable-mdpi' etc... folder. For some reason, when loading in a image from the 'drawable' folder, it takes up HUGE amounts of space. The solution is to add different resolution variants of your images to all the drawable-Xdpi (where X is l,m,h or xh) folders. It reduced my starting heap size from around 26MB to a good 16MB. Even if you don't resize them, and just copy-paste them into the folders, it will still result in quite a significant change in Bitmap sizes.
I hope I help some people by posting this.
-Z