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?
Related
Its an old post, but still in most of the places i found out that an android app gets around 16-32 MB memory
But when i check android Profiler, it says that my app is currently using around 350 MB memory on Samsung Galaxy S7.
I get OutOfMemoryException on my app a couple of times, I was curious why its happening. When i dig down a little i found out about 16-32 MB limit, but in actual my app is using 350 MB
I want to know how much memory a normal android phone gives to each app, or is it a variable number, and if no app is running android will not give outOfMemoryException, and if so many apps are in stack then there is a higher chance of OutOfMemoryException
But again there will be some limits.
Android devices vary significantly now that the OS is getting older. You should definitely aim for under 32mb limit if you want your app to work on lower end devices to be safe. Unless you are loading some very large images it sounds like your code is leaking memory.
Start by removing any image (or other asset) loading from your app to see if you still have problems.
If you do, check out LeakCanary, and when you find the leaks learn about them and why they are happening because it will help you immeasurably to become a better Android programmer. One of the chief ways apps leak memory is by passing an Activity context to a long running task :)
Trying to recreate OOM happening on a Samsung S4 (5.0.1) on an AVD (5.0). Both report MemoryClass 128, but I cannot reproduce the OOM condition on my AVD.
I ended up with a really extreme test bitmap of 6000x4000 (96MB with no inSampling. Sure, not a good idea for production, but this is for testing only) I'm using plain BitmapFactory.
The S4 consistently crashes while loading, not a surprise :)
The weird thing: on the AVD this consistently loads without any problem. I'm always able to allocate huge memory nearly to the limits of available MemoryClass, as if there's not fragmentation at all.
Shouln't devices with identical VM heap size behave similar? There should be no major differences in heap fragementation on both devices, as the App has been freshly installed and started.
I'm quite confused, because it looks like an AVD is not a useful device for testing, at least in terms of memory management in ART.
I might have some basic misunderstanding on MemoryClass and VM Heap size. Any ideas?
I have Samsung Galaxy S4 (Android 5.0.1). I tested 2 applications with a WebView.
1) In one of them a geographical map is used with marks and lines (paths). After 10-20 shifts and zooms it crushed with OutOfMemory.
2) In the second a site of a company is used integrated in Cordova. After 20-60 page loadings it also crushes with OutOfMemory.
When I see a memory allocation, it acts like a saw: after an increase up to some limit it frees, then again increases. After 2-4 peaks it crushes.
On some other devices these crushes are not reproduced. The same is in replies at PlayMarket.
I read many articles including http://www.dwmkerr.com/fixing-memory-leaks-in-angularjs-applications/. An application uses Angular JS. When I tested it in Chrome and Firefox developer's console I saw that after peaks up to 12 Mb a garbage collector in a browser started.
I have these questions.
1) Does a WebView have it's own garbage collector (I think, Javascript GC)?
2) If a WebView is just a View, why it is not destoroyed, but a whole application crushes?
3) How Android GC can affect WebView (maybe Chromium GC) and how WebView can tell Android GC to free a memory?
As nobody answered, I reply.
I connected devices to Chrome, entered "chrome://inspect" and watched a spreading of memory (including JS Heap) on time. On Samsung devices a memory constantly increased after events in WebView. On HTC (Android 2.3.3) it increased, then again cleaned by GC (every second). On Samsung Galaxy S4 it raised from 20 Mb up to 30 and then crushed. On Galaxy Tab A it started from 7 Mb and so didn't crush.
A Chrome developer console also showed a work of GC in WebView. Sometimes it launched Major GC, sometimes Minor GC. I think, that was a Javascript GC inside WebView, as it had not led to cleaning memory in Java.
1) Every implementation of a browser on every platform has it's own GC (including Javascript GC).
2) WebView is a very complex View, so it may easily crush an application.
3) I think, Android may ask WebView to free some memory, it launches it's GC. But depending on the platform it can decrease a used memory by WebView (on HTC 2.3.3) or leave it intact. So even if a GC was run in WebView, it often won't free memory in the application.
I am working on app. When I check the used memory of app in device it shows the 50 MB (By Going in setting and app and running process . But at same time when I check the app allocated and free memory it is just MB.
How can I get the exact figure.
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.