Develop Reference

Usage of heap memory for android app

I used following APIs to check memory that my app can use and got the below results.
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.v("onCreate", "maxMemory:" + Long.toString(maxMemory));
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass();
Log.v("onCreate", "memoryClass:" + Integer.toString(memoryClass));
V/onCreate: maxMemory:402653184
V/onCreate: memoryClass:64
But when I launch my app, it shows 5MB allocated and 1 MB free.
I was in assumption that entire 64 MB will be for the app and suppose if 5MB is allocated out of 64MB then 59MB should be free.
And as I progress using the application, the heap size allocated is growing with lot of GC causes in between which is impacting the UI performance.
Could someone make me understand this process.
Will this work this way?
Thanks

How to know updated available heap size?

I am facing difficulties to get updated available heap size of application after removing some of the large objects.
My requirement is to free the memory once user reach the specific level of heap size. e.g I am using Samsung Tab3 which has 64 Mb heap size for an application.
Application should't go out of memory while viewing images, hence i have restricted 55 MB as max limit for heap size to grow. I am checking available heap size before view image. If the heap size is greater than 55 MB then I remove the some of the images which are recently viewed, so i can get enough memory to load image.
But the problem is that the, after removing images objects, I got the last increased heap size, which is always greater than 55 MB. I also called gc after remove each image, but doesn't affect.
I want the decreased heap size after removing image object.
if heap has reached 55 MB then on each removal heap should decrease, how to get decreased heap size?
I am using following codes to get available heap size.
/**
* This method is used to get currently allocated heap size to application.
*/
public static int getAllocatedHeapSize()
{
DecimalFormat df = new DecimalFormat();
int size = new Double(Runtime.getRuntime().totalMemory()/1048576).intValue();
Log.d("heap", "debug.memory: allocated: " + size + "MB of " + df.format(new Double(Runtime.getRuntime().maxMemory()/1048576))+ "MB (" + df.format(new Double(Runtime.getRuntime().freeMemory()/1048576)) +"MB free)");
return size;
}
/**
* Check whether free memory is available to store new attachment page
* #return true if available else false
*/
public static boolean isFreeMemoryAvailable()
{
int allocatedHeapSize = getAllocatedHeapSize();
if (allocatedHeapSize > ) {
return false;
}
return true;
}
isFreeMemoryAvailable() method goes in infinite because its not getting updated heap size.
Give me a solution as soon as possible.

Runtime.totalMemory() is not related to how much of the heap that is actually used when called. It returns the actual size of the heap. From the documentation:
Returns the number of bytes taken by the heap at its current size.
Removing objects does not necessarily change the heap size.
You could get the actual usage of the heap by doing:
Runtime.totalMemory() - Runtime.freeMemory();
That said, maybe you should look at storing your images in a android.util.LruCache or something instead of doing this management yourself.

There are several aspects to this question:
1) You might get more reliable and detailed statistics using java management beans, e.g., http://docs.oracle.com/javase/7/docs/api/java/lang/management/MemoryMXBean.html among other (MemoryMXBean, MemoryPoolMXBean, GarbageCollectorMXBean)
2) You cannot reduce your heap size from within the java application, you can only reduce your usage of the heap.
3) You might consider the usage of Soft References http://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html. This class enables you to keep references as long as the space is not needed otherwise, and collect it only when absolutely necessary. This way you can limit your heap size, and use soft references to keep data as long as possible but do not impede the GC collecting it if necessary.

Heap not expanding on Genymotion emulator

While resizing large bitmaps for faster image upload to a server I occasionally ran into OutOfMemoryErrors.
To prevent this I calculate the required amount of memory and check if it exceeds Runtime.getRuntime().maxMemory() before trying to scale an image.
However, I still run into OOM errors even though the image should fit on the heap easily.
The emulated device (Galaxy SII API 16) gives me a max memory of 67108864 bytes using the above method.
In the following snippet, the heap size is 43975K and only < 15K of that memory is in use. For my ~31K allocation the heap should grow automatically to about 45K which is still not even close to the maximum size of 64 MiB.
But as you can see, instead of expanding the heap, the dalvik vm runs out of memory.
10-13 20:35:57.223: D/dalvikvm(1201): GC_FOR_ALLOC freed 505K, 67% free 14692K/43975K, paused 31ms, total 31ms
10-13 20:35:57.223: I/dalvikvm-heap(1201): Forcing collection of SoftReferences for 31961100-byte allocation
10-13 20:35:57.251: D/dalvikvm(1201): GC_BEFORE_OOM freed 2K, 67% free 14689K/43975K, paused 29ms, total 29ms
10-13 20:35:57.251: E/dalvikvm-heap(1201): Out of memory on a 31961100-byte allocation.
I wonder if this can happen on a real device too or if this could be a genymotion bug.
Is the heap guaranteed to expand up to maxMemory()? The JavaDoc for Runtime.getRuntime().freeMemory() says it "may" expand, whatever that means.
I just need a realiable way to calculate the amount of memory I can use, this is how I did it, please correct me if I'm wrong:
long maxMemory = Runtime.getRuntime().maxMemory();
long usedMemory = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
long availableMemory = maxMemory - usedMemory;
This call causes the OutOfMemoryError:
// outOptions has an appropriate inSampleSize
BitmapFactory.decodeStream(inputStream, null, outOptions);

Out of memory on a 31961100-byte allocation
Your bitmap is 32M. VM can't allocate 32M linear space to store bitmap. Heap is fragmented, so even if your heap has 32M free space it is not always possible to allocate such linear space. You can try free up as much memory as you can and call GC before decoding stream.
Try to decode your bitmap in more effective way. Or process image in parts.
If you tell us why you need this image, we can tell you how to handle it.

You have a 42MB heap , out of which 14MB is already used, 67% (28M) is free/available
D/dalvikvm(1201): GC_BEFORE_OOM freed 2K, 67% free 14689K/43975K, paused ...
E/dalvikvm-heap(1201): Out of memory on a 31961100-byte allocation.
You are trying to allocate ~31M (not 31K) , which is greater than 28M that is available, resulting in OOM.
For details on interpreting dalvikvm memory allocation log message take a look at debugging memory
There is lot of shared memory usage going on in android, to properly calculate per process memory usage refer this SO question
Android best practices on efficient bitmap memory management may be of help

One thing you might try to tweak is build.props file of the ROM.
On Genymotion emulator you can try executing the following via root shell:
cat /system/build.prop | grep dalvik
and it would display the line with dalvik settings:
dalvik.vm.heapsize=256m
dalvik.vm.lockprof.threshold=500
dalvik.vm.stack-trace-file=/data/anr/traces.txt
And maxmemory is also being reported as 268435456 bytes on the emulator I experimented with.
So, you may try playing with this setting. Also, ensure that the memory allocated in VirtualBox's settings is compatible with these values.

OutOfMemory although Heap Size is less than 6MB

In my Android developer console, I see some crashes with
Caused by: java.lang.OutOfMemoryError: (Heap Size=5795KB, Allocated=3859KB)
Especially the small Heap Size (less than 6MB) surprises me.
How do I have to interpret this Heap Size? Is this the size of the heap prior to the OOM call? Can I assume that the max heap is at least 16MB? If so, does this mean that I tried to allocate a block of at least 10MB (16MB - 6MB) ?

You can use the following to check the memory status:
ActivityManager actMgr = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
ActivityManager.MemoryInfo minfo = new ActivityManager.MemoryInfo();
actMgr.getMemoryInfo(minfo);
if(minfo.lowMemory) { //do something
}

Android Heap Memory size doesn't looks correct

i have an Android app that displays alot of images, it works, the images are gatherd from an url, added to a que and gathered by 4 threads,stored in a cache and then displayed in a listview view 4 images for row, there are abot six rows at each time on the screen. There is a total of usually 90 images.
The rows(and imageviews) are always recycled, so the amount of items is always the same and i'm not initializing anything.
This seems to work quite fine, i have always an average used heap size of 13MB.
The problem i have is that at the beginning mi max heap size is quite small and i get GC messages like:
01-20 16:48:39.191: D/dalvikvm(9743): GC_FOR_ALLOC freed <1K, 31% free 12048K/17351K, paused 25ms
but the more i scroll up down the view the heap size grows more and more untile i get things like
01-20 17:02:05.339: D/dalvikvm(11730): GC_FOR_ALLOC freed 544K, 72% free 13871K/49159K, paused 35ms
as you see even if the used is the same the maximum is increased even if i never got to that limit. and the true problem is that at this point i start to get outofmemory errors.
Can someone explain me what's wrong?
Thanks!

What version of Android are you using? If you're testing on pre 3.0 (ie 2.x), the byte arrays that store most of the information in Bitmaps are allocated and stored in native memory. This means that in heap dumps and in the GC notifications, you only see the small amount of memory used for pointers in Bitmaps, rather than the actual size.
For more information check out this google IO talk on memory management and detecting memory leaks: http://www.youtube.com/watch?v=_CruQY55HOk
Also I've worked on several apps doing similar things. My guess is that either your cache size is way too large, or (more likely) the images you're displaying and storing in the cache are much larger than the size you actually want. If you display a bitmap in an image view, the imageview will store the original bitmap in memory, even if it is significantly larger than what would actually fit in the view. Try resizing the images from disk to at least closer to the appropriate size before trying to display them: How do I scale a streaming bitmap in-place without reading the whole image first?

To cache my Images I use Map<String, Drawable> drawableMap. On a OutOfMemoryError I call this function:
private void cacheLeeren()
{
int size = drawableMap.size();
int del = (int) (size * 0.3);
Set<String> s = drawableMap.keySet();
for (String t : s)
{
if (del >= 0)
{
drawableMap.put(t, null);
del--;
}
}
}
I think it's not the best way...but it works ;-)

My guess is that your app reaches a very high peak of memory usage for a short time. It's true that on average you only use 13MB but if your heap grows to as much as 50MB, it means that momentarily you've consumed much more memory than you're thinking.
Let's try to figure out where this is happening. You've mentioned that you're using an LRU cache. This cache frees memory as soon as it fills up. My guess is that you're starting to free memory too late, and this memory isn't freed immediately - since it depends on the system GC. Whenever you're freeing some items from the cache, try to call System.gc() manually.
You've also mentioned that you're calling Bitmap.recycle(). To the best of my knowledge this is useless on Android 3+ because the native heap is no longer used for bitmaps. Since all bitmaps are on the dalvik heap, they will be freed by the GC.. You can't rush this like before unless you call System.GC() yourself.
Another idea for your source of problems is heap fragmentation. See my previous SO answer to a similar issue in this question.