I am having an OutOfMemory exception with a gallery over 600×800 pixels JPEG’s.
The environment
I’ve been using Gallery with JPG images around 600×800 pixels.
Since my content may be a bit more complex than just images, I have set each view to be a RelativeLayout that wraps ImageView with the JPG.
In order to “speed up” the user experience I have a simple cache of 4 slots that prefetches (in a looper) about 1 image left and 1 image right to the displayed image and keeps them in a 4 slot HashMap.
The platform
I am using AVD of 256 RAM and 128 Heap Size, with a 600×800 screen.
It also happens on an Entourage Edge target, except that with the device it’s harder to debug.
The problem
I have been getting an exception:
OutofMemoryError: bitmap size exceeds VM budget
And it happens when fetching the fifth image. I have tried to change the size of my image cache, and it is still the same.
The strange thing: There should not be a memory problem
In order to make sure the heap limit is very far away from what I need, I have defined a dummy 8MB array in the beginning, and left it unreferenced so it’s immediately dispatched. It is a member of the activity thread and is defined as following
static { @SuppressWarnings("unused")
byte dummy[] = new byte[ 8*1024*1024 ]; }
The result is that the heap size is nearly 11MB and it’s all free.
Note I have added that trick after it began to crash. It makes OutOfMemory less frequent.
Now, I am using DDMS. Just before the crash (does not change much after the crash), DDMS shows:
ID Heap Size Allocated Free %Used #Objects
1 11.195 MB 2.428 MB 8.767 MB 21.69% 47,156
And in the detail table it shows:
Type Count Total Size Smallest Largest Median Average
free 1,536 8.739MB 16B 7.750MB 24B 5.825KB
The largest block is 7.7MB. And yet the LogCat says:
ERROR/dalvikvm-heap(1923): 925200-byte external allocation too large for this process.
If you mind the relation of the median and the average, it is plausible to assume that most of the available blocks are very small. However, there is a block large enough for the bitmap, it’s 7.7M. How come it is still not enough?
Note: I recorded a heap trace. When looking at the amount of data allocated, it does not feel like more than 2M is allocated. It does match the free memory report by DDMS.
- Could it be that I experience some problem like heap-fragmentation?
- How do I solve/workaround the problem?
- Is the heap shared to all threads?
- Could it be that I interpret the DDMS readout in a wrong way, and there is really no 900K block to allocate? If so, can anybody please tell me where I can see that?
Thanks a lot
Meymann
I think there’s nothing special in your case. There’s just not enough memory. You can’t have several 600×800 bitmaps in memory, they consume too much memory. You should save them to SD and load to memory on demand. I think that’s exactly what you do.
One thing you should be aware of: DDMS displays java heap memory consumption. But there’s also native memory that is not displayed in DDMS. And bitmaps as far as I understand are created in native memory. So DDMS is just a bad tool to track these memory issues. You just need to be sure that you free your memory, that images are collected by Garbage Collector after you don’t need them any more.
Garbage Collector works on it’s own schedule. That’s why you should call Bitmap.recycle() method on bitmaps that you don’t need any more. This method frees exactly the native memory that you run out of. This way you don’t depend on GC and you can free largest piece of memory as soon as possible.
First of all you should ensure that you don’t leak bitmaps.
Here’s a nice post on memory allocations, it can help you to dig deeper