We have an app with lots of bitmaps in memory. It keeps failing with
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
errors. It's possible that we are genuinely using too much memory; it's possible that we are leaking memory; it's also possible that we aren't doing anything wrong, and heap fragmentation is what's killing us. (Since Android's garbage collector doesn't relocate live blocks, we could have megabytes free and be unable to allocate 50K.)
Is there any way to rule out fragmentation? I've looked for something like maxAvail/memAvail, but haven't spotted anything apposite.
I would look into examining the heap via MAT. The Eclipse Memory Analyzer will help you determine which of your proposed issues you actually have.
There was a talk at Google I/O 2011 that covered some basics on the topic of memory management and debugging. You can watch it online here: http://www.youtube.com/watch?v=_CruQY55HOk&feature=relmfu
Related
I have been trying to reduce memory usage of the app.
It seems the memory allocation is not an issue as the heap shows allocation of 8mb out of 54mb being used.
Majority of the memory is consumed by code and native section, which doesnt seem right at all. I dont know how to go about it as allocation is not a problem as it seems.
Any help is most Welcome.
I am developing an application in that I am getting the Out of memory Exception this is happened due to the insufficient memory. Is possible re allocate the memory once reach the maximum allocate memory.
It is not possible to allocate more memory than is in budget which system gives you.
You can try to put android:largeHeap to your manifest, but it works only on some devices and it isnt generally best solution.
Instead you should find out where you are using all that memory and try to optimize to cut it down.
On modern devices there should be plenty of memory and should be enough for most operations with good design. System places gap on memory usage to prevent poorly designed apps, from depleting memory pool.
I'm studying about RAM memory, and I see that helloworld from the android samples uses about 13MB of android memory.
How does it happen, if the app have only an activity with a TextView?
And what to do to reduce memory usage? and which uses more memory?
I see that helloworld from the android samples uses about 13MB of android memory
You did not indicate how you are measuring this memory usage.
Please read:
Dianne Hackborn's blog post, "Process Stats: Understanding How Your App Uses RAM"
Dianne's epic StackOverflow answer on measuring memory usage, particularly the first paragraph:
Note that memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. In fact the chances of you actually correctly interpreting whatever numbers you get is extremely low
Anything that you use that lies beyond what is written in those posts may or may not be accurate. And even interpreting what Process Stats is telling you is a bit of a challenge.
How does it happen, if the app hase only an activity with a TextView?
It is unlikely that your app has 13MB of consumed heap space. What you are seeing probably includes memory shared with other processes, for the Dalvik VM, platform libraries, and framework classes.
Android developers should be worrying about their heap space, first and foremost. Most of the memory usage beyond that is driven by the platform, not you (notable exception: NDK libraries that you load and the memory that they consume, for code and data).
what to do to reduce memory usage?
Probably nothing, because probably nothing needs to be done.
For more complex apps, as thepoosh mentions in a comment, you can generate a heap dump from DDMS and examine that in MAT to see if your app is leaking memory, resulting in an over-use of heap space.
You are welcome to try using android.os.Debug to try to get a sense of how much the heap is being utilized at runtime.
And, you are welcome to read the documentation on memory usage.
What is the difference between the heap usage (Allocated) we can see in the Elipse Memory Analysis Tool (in the DDMS view) and the memory usage size for the same App shown here on the Android device?:
Settings->Apps->Running
Even though I aggressively tried to preserve memory by making objects null as soon as they weren't needed, the latter number (memory usage size on Running apps screen) only kept increasing and my app finally crashed due to OutOfMemoryError. However, the former showed me that I was well within a reasonable size. I was also calling System.gc() a lot. Is there a difference between the two? Why the discrepancy? Any ideas on how I can solve this problem?
The biggest difference between the two that I know of is the scope of garbage collection.
Normal garbage collection, including System.gc(), collects a bit of garbage, then stops. It is not a complete sweep of the heap to get rid of everything. That is to try to minimize the CPU impact of garbage collection.
The heap dump prepared for MAT, though, effectively a complete GC.
Your symptoms suggest that you are allocating memory faster than GC can reclaim it. The primary solution for this is to try to allocate less memory, or allocate it less frequently. For example, where possible, reuse objects, bitmap buffers, and the like, instead of trying to let GC clean the old stuff and allocating new stuff as you go.
It sounds like you have a memory leak somewhere in your application if the memory is never released. This means that somewhere you are maintaining a strong reference to a large object which is being recreated (like an Activity or Bitmap) which is why calling System.gc() is making no difference.
I suggest watching the following on memory management in android from google IO 2011. It lets you know how to use the eclipse memory analyser tool which is incredibly useful for debugging this sort of error
I noticed that on my Galaxy Nexus that android.content.res.Resources is allocating about 11MB. I discovered this as I was in the process of profiling things using DDMS and the "Dump HPROF file" option. So, I spent two hours trying to see if the allocation was due to something in my code or supporting libraries. I removed all my data, a ton of classes, all my libraries, and saw no change. After placing a breakpoint in my code at the beginning of the onCreate() method of the activity, it showed that the 11MB allocation is already present.
After being thoroughly confused, I decided to connect my rooted Nook Color running CM7 to see what it was reporting for initial memory usage for the exact same application. The worst case memory "Problem Suspect" reported by the MAT weighs in at a mere 896KB.
Is ICS that top-heavy? Am I missing something here? As far as I can tell, my application is functioning correctly, but having the heap usage indicate 97% full has me worried about potential failures.
If it helps, MAT was indicating that the primary objects consuming all the memory were Bitmaps, BitmapDrawables, and NinePatchDrawables. I don't understand where these allocations are coming from.
Pre-Honeycomb (<3.0), Bitmaps were allocated in native heap and did not appear in Dalvik heap dumps as shown by Eclipse MAT, etc. This native allocation still contributed towards maximum Dalvik heap limits for an application, and still caused garbage collection to run at approximately the correct time when approaching a low memory situation. This usage can be measured with Debug.getNativeHeapAllocatedSize().
Since Android 3.0 (including ICS), it now allocates the pixel data for Bitmaps in normal byte arrays in Dalvik heap. The practical effects of this are better/simplified garbage collection behaviour for Bitmaps (since they can be treated in a more orthodox way) and the ability to track Bitmap allocations in Dalvik heap dumps.
I do not think the actual memory usage for a particular application is significantly different between pre-Honeycomb and more recent releases, and that this is just a matter of an alternative accounting practice.
Memory Analysis for Android
BitMaps in Android