I'm seeing a pretty odd problem. Essentially sometimes large bitmap memory allocations will fail even though there's apparently tons of memory. There are a number of posts that appear to ask a similar question but they are all related to pre-honeycomb android. My understanding is that images are allocated on heap now, instead of some outside memory. Anyway, please look at this log below:
10-14 13:43:53.020: INFO/dalvikvm-heap(31533): Grow heap (frag case) to 40.637MB for 942134-byte allocation
10-14 13:43:53.070: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 126K, 11% free 41399K/46343K, paused 31ms
10-14 13:43:53.130: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 920K, 13% free 40478K/46343K, paused 30ms
10-14 13:43:53.180: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 1026K, 13% free 40479K/46343K, paused 30ms
10-14 13:43:53.250: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 931K, 12% free 41193K/46343K, paused 31ms
10-14 13:43:53.250: INFO/dalvikvm-heap(31533): Grow heap (frag case) to 41.313MB for 1048592-byte allocation
10-14 13:43:53.280: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed <1K, 11% free 42217K/47431K, paused 31ms
10-14 13:44:01.520: DEBUG/dalvikvm(31533): GC_CONCURRENT freed 3493K, 15% free 40646K/47431K, paused 3ms+9ms
10-14 13:44:08.130: DEBUG/dalvikvm(31533): GC_EXPLICIT freed 16461K, 47% free 25527K/47431K, paused 3ms+6ms
10-14 13:44:09.150: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 1007K, 45% free 26191K/47431K, paused 35ms
10-14 13:44:09.160: INFO/dalvikvm-heap(31533): Grow heap (frag case) to 29.334MB for 3850256-byte allocation
10-14 13:44:09.200: DEBUG/dalvikvm(31533): GC_CONCURRENT freed 0K, 37% free 29951K/47431K, paused 2ms+4ms
10-14 13:44:11.970: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 1878K, 38% free 29784K/47431K, paused 37ms
10-14 13:44:12.410: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed 62K, 36% free 30441K/47431K, paused 32ms
10-14 13:44:12.440: DEBUG/dalvikvm(31533): GC_FOR_ALLOC freed <1K, 32% free 32325K/47431K, paused 32ms
10-14 13:44:12.440: INFO/dalvikvm-heap(31533): Forcing collection of SoftReferences for 3850256-byte allocation
10-14 13:44:12.480: DEBUG/dalvikvm(31533): GC_BEFORE_OOM freed 124K, 33% free 32200K/47431K, paused 37ms
10-14 13:44:12.480: ERROR/dalvikvm-heap(31533): Out of memory on a 3850256-byte allocation.
I apologise for including so much logging, I hope it's relevant. The way I read it is that the system continuously readjusts heap size until it eventually reaches heap max. Then, we request an especially large allocation that fails. Clearly there is more than enough memory available (about 15 megs). Does this mean that heap is internally fragmented and there are no contiguous memory segments large enough to handle our allocation? If that's the case what should I do? If that's not it, then what?
Thanks in advance.
The weird behavior is because bitmaps are allocated on the native heap and not on the garbage collected, but android can only track objects on the garbage collected heap. From Android 2.2 (or 2.3 maybe) this has changed and allocated bitmaps are visible too if you make a heap dump.
Back to the question, your problem is most probably that the bitmaps you loaded manually are not freed appropriately. One typical problem is that some callback remains set or the view is still referring the bitmap.
The other common problem is that if you load big bitmaps manually (not as a resource), you will need to call recycle() on them when you don't need it anymore, which will free the bitmap from the native memory so the garbage collector will be able to its work as it should. (The GC only sees objects on the GC heap, and doesn't no which object to free to free memory from the native heap, and actually doesn't even care about it.)
I have this little baby at hand all the time:
public static void stripImageView(ImageView view) {
if ( view.getDrawable() instanceof BitmapDrawable ) {
((BitmapDrawable)view.getDrawable()).getBitmap().recycle();
}
view.getDrawable().setCallback(null);
view.setImageDrawable(null);
view.getResources().flushLayoutCache();
view.destroyDrawingCache();
}
The images are fetched from the Web, each ranging from 300K to 500K in
size, and stored in an arrayList of Drawables.
The kb file size of the image you're loading from the web isn't directly relevant. Since they're converted into bitmaps you need to calculate width * height * 4 bytes per image for regular ARGB images. (width and height in px).
The bitmaps consume native heap, which usually doesn't show in a hprof. The hprof should only show you the number of objects, i.e. BitmapDrawables or Bitmaps that are left.
I use this code in my app to output the current used memory used by the app and native heap:
public static void logHeap(Class clazz) {
Double allocated = new Double(Debug.getNativeHeapAllocatedSize())/new Double((1048576));
Double available = new Double(Debug.getNativeHeapSize())/1048576.0);
Double free = new Double(Debug.getNativeHeapFreeSize())/1048576.0);
DecimalFormat df = new DecimalFormat();
df.setMaximumFractionDigits(2);
df.setMinimumFractionDigits(2);
Log.d(APP, "debug. =================================");
Log.d(APP, "debug.heap native: allocated " + df.format(allocated) + "MB of " + df.format(available) + "MB (" + df.format(free) + "MB free) in [" + clazz.getName().replaceAll("com.myapp.android.","") + "]");
Log.d(APP, "debug.memory: allocated: " + df.format(new Double(Runtime.getRuntime().totalMemory()/1048576)) + "MB of " + df.format(new Double(Runtime.getRuntime().maxMemory()/1048576))+ "MB (" + df.format(new Double(Runtime.getRuntime().freeMemory()/1048576)) +"MB free)");
System.gc();
System.gc();
// don't need to add the following lines, it's just an app specific handling in my app
if (allocated>=(new Double(Runtime.getRuntime().maxMemory())/new Double((1048576))-MEMORY_BUFFER_LIMIT_FOR_RESTART)) {
android.os.Process.killProcess(android.os.Process.myPid());
}
}
which I call when starting or finishing an activity during development.
logHeap(this.getClass());
Here are some informative links - generally there are lots of threads about this topic on here.
Bitmaps in Android
Android: Eclipse MAT does not appear to show all my app's objects
Here's also a useful slide by Romain Guy (Android Framework engineer) about soft references, weak references, simple caches, image handling: http://docs.huihoo.com/google/io/2009/Th_0230_TurboChargeYourUI-HowtomakeyourAndroidUIfastandefficient.pdf
The system doesn't readjust heap sizes. Your app has a (semi-) predefined heap space. Heap sizes can be adjusted in some custom ROMs. This isn't really germane to your problem though.
The order of the garbage collection you're seeing seems to suggest that at the time of the GC_BEFORE_OOM happens your app's running out of its heap space. The stats reported by the Dalvik logger could be system-wide.
yes the error "out of Memory" occur when we are working with big size Bitmap. for that i have an solution, with Decoding of the image we can easily avoid this error.
BitmapFactory.Options o = new BitmapFactory.Options();
o.inJustDecodeBounds = true;
FileInputStream fis = new FileInputStream(files.getAbsolutePath());
BitmapFactory.decodeStream(fis, null, o);
fis.close();
final int REQUIRED_SIZE=70;
int width_tmp=o.outWidth, height_tmp=o.outHeight;
int scale=1;
while(true){
if(width_tmp/2<REQUIRED_SIZE || height_tmp/2<REQUIRED_SIZE)
break;
width_tmp/=2;
height_tmp/=2;
scale*=2;
}
BitmapFactory.Options op = new BitmapFactory.Options();
op.inSampleSize = scale;
fis = new FileInputStream(files.getAbsolutePath());
bitmap[i] = BitmapFactory.decodeStream(fis, null, op);
fis.close();
Related
Here's a sample function that fills a small ByteBuffer, and then that reads it into a large byte array:
// Allocate the two buffers once for all.
const int byteBufferSize = 20;
var byteBuffer = ByteBuffer.Allocate(byteBufferSize);
/* var byteBufferArray = new byte[byteBufferSize];
var byteBuffer = ByteBuffer.Wrap(byteBufferArray);*/
var bytes = new byte[1024 * 1024];
var bytesPos = 0;
for (;;)
{
// Put byteBuffer in "write" mode.
byteBuffer.Clear();
// Write a few bytes in byteBuffer.
for (var i = 0; i < byteBufferSize; ++i)
byteBuffer.Put(0);
// Put byteBuffer in "read" mode.
byteBuffer.Flip();
// Read the written bytes from byteBuffer.
// DEEP BELOW, THIS CALL UNEXPECTEDLY CAUSES A NASTY ALLOCATION OF ABOUT bytes.length BYTES!
byteBuffer.Get(bytes, bytesPos, byteBufferSize);
bytesPos += byteBufferSize;
Thread.Sleep(1000);
}
When I run this code on Nexus 5 running Android 5.0, it seems to be fine. But when I run it on a Samsung Galaxy S3 running Android 4.3, every time ByteBuffer.Get gets called, it seems a buffer of size bytes.length (1 Mo here) gets allocated somewhere inside ByteBuffer.Get, and after a short while the logs look like:
05-15 09:50:28.519: D/dalvikvm(23104): GC_FOR_ALLOC freed 1024K, 48% free 10250K/19624K, paused 49ms, total 49ms
05-15 09:50:29.580: D/dalvikvm(23104): GC_FOR_ALLOC freed 1024K, 48% free 10250K/19624K, paused 48ms, total 48ms
05-15 09:50:30.622: D/dalvikvm(23104): GC_FOR_ALLOC freed 1024K, 48% free 10250K/19624K, paused 39ms, total 39ms
05-15 09:50:31.673: D/dalvikvm(23104): GC_FOR_ALLOC freed 1024K, 48% free 10250K/19624K, paused 45ms, total 45ms
05-15 09:50:32.724: D/dalvikvm(23104): GC_FOR_ALLOC freed 1024K, 48% free 10250K/19624K, paused 42ms, total 42ms
...
Is it something that I do with the ByteBuffer object or it there something wrong with ByteBuffer.Get in Xamarin? Note that I did test the same code in a native Android Java app the code ran as expected, i.e. without the crazy allocations triggered by ByteBuffer.Get.
In case anyone comes across this page first while researching this issue, I have now filed an enhancement request that discusses the underlying causes of this problem as well some possible workarounds:
https://bugzilla.xamarin.com/show_bug.cgi?id=31260
I have 3 activities, while I switch from 2 to 3, my app like restarts and jumps to 1.
I drag bitmap from activity to another one.
What to do? What trick shoul i use less memory?
02-02 06:29:20.017 1509-1509/marty.martzero D/dalvikvm﹕ GC_FOR_ALLOC freed 508K, 6% free 21312K/22663K, paused 29ms, total 29ms
02-02 06:29:20.027 1509-1509/marty.martzero E/io﹕ bitmaptosave = xz
02-02 06:29:20.586 1526-1526/marty.martzero D/dalvikvm﹕ GC_FOR_ALLOC freed 69K, 4% free 8003K/8259K, paused 28ms, total 29ms
02-02 06:29:20.606 1526-1526/marty.martzero I/dalvikvm-heap﹕ Grow heap (frag case) to 10.228MB for 2479056-byte allocation
02-02 06:29:20.656 1526-1528/marty.martzero D/dalvikvm﹕ GC_CONCURRENT freed <1K, 3% free 10424K/10695K, paused 15ms+10ms, total 54ms
02-02 06:29:20.857 1526-1528/marty.martzero D/dalvikvm﹕ GC_CONCURRENT freed 1K, 2% free 11189K/11335K, paused 16ms+3ms, total 56ms
02-02 06:29:20.937 1526-1526/marty.martzero D/libEGL﹕ loaded /system/lib/egl/libEGL_emulation.so
02-02 06:29:20.947 1526-1526/marty.martzero D/﹕ HostConnection::get() New Host Connection established 0x2a0fcf60, tid 1526
First of all, know that Bitmaps are evil in mobile applications. They occupy big chunk of RAM if they are not used efficiently. Following methods might help for a better memory management:
Use a singleton to hold on to your bitmaps.
However, be very careful about memory leak in android, see this.
DO NOT recreate a bitmap which has already been loaded to the memory. For example do not recreate a scaled version of Bitmap while you still hold a reference to the original version of a bitmap. If you need different sizes of a single bitmap, use matrix manipulation, rather than resizing the Bitmap itself each time.
Do this:
canvas.drawBitmap(bitmap, srcRect, dstRec1, null);
canvas.drawBitmap(bitmap, srcRect, dstRec2, null);
canvas.drawBitmap(bitmap, srcRect, dstRec3, null);
And NOT this:
canvas.drawBitmap( bitmap1, left1, top1, null);
canvas.drawBitmap( bitmap2, left2, top2, null);
canvas.drawBitmap( bitmap3, left3, top3, null);
where bitmap1, bitmap2, and bitmap3 are the same file only with different scaling.
Try to load bitmap as small size as you can. Read more details about sampling here.
Finally, if your application really really needs a big heap size, you can request a bigger heap through setting up a flag in your manifest, application section:
android:largeHeap="true"
You can make your bitmap public and static, and use it in another activity. There is no need to drag with activity.
And another way to compress bitmap to reduce memory size
BitmapFactory.Option imageOpts = new BitmapFactory.Options ();
imageOpts.inSampleSize = 2; // for 1/2 the image to be loaded
Bitmap thumb = Bitmap.createScaledBitmap (BitmapFactory.decodeFile(photoPath, imageOpts), 96, 96, false);
I'm getting way too many GC_FOR_ALLOC from the dalvikvm.
I'm getting XML from a REST service: in one activity I parse about 100 lines programatically(me) and in the other activity I use the SimpleXML to parse about 200 lines.
In the first one I get 50 GC_FOR_ALLOC.
In the second one I get like 300!! (I can't even post it all, the body makes 29579 characters and it's allowed only 30k)
I've searched and almost everyone complains about gc_for_"M"alloc and not gc_for_"A"lloc.
Is the SimpleXML the problem because the instances created?
I'll post the logcat dump by dalvikvm, maybe the values have some information.
Thank you very much for your help.
12-11 06:13:49.564: D/dalvikvm(6759): GC_FOR_ALLOC freed 362K, 13% free 4116K/4688K, paused 181ms, total 182ms
12-11 06:13:50.074: D/dalvikvm(6759): GC_FOR_ALLOC freed 303K, 13% free 4134K/4708K, paused 142ms, total 142ms
.... repeated many times .....
12-11 06:14:06.254: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% free 4159K/4768K, paused 53ms, total 53ms
12-11 06:14:06.314: D/dalvikvm(6759): GC_FOR_ALLOC freed 103K, 13% free 4159K/4768K, paused 56ms, total 57ms
12-11 06:14:06.374: D/dalvikvm(6759): GC_FOR_ALLOC freed 29K, 12% free 4203K/4768K, paused 54ms, total 54ms
12-11 06:14:06.424: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% fre
You can see the most-recently-allocated objects using the DDMS Allocation Tracker (memory debugging docs, old blog post, ddms docs). This will show you what's being allocated and give you a stack trace for the place where the allocation is being performed.
Another blog post describes MAT and other relevant tools, though heap-dump analysis is less useful for this sort of problem because it generally shows you the objects that haven't been freed, and you're more interested in the objects that are being freed.
In Android Dalvik VM, GC_FOR_ALLOC is inovked in object alloc step when dlmalloc footprint space is NOT enough for new or heap->bytesAllocated + n > hs->softLimit. You can set dalvik.system.setTargetHeapUtilization lower for more free heap space.
you can use MAT MAT tutorial
to find how many object are creating and garbage collected. so that youcan optimize your code
If you get that multiple GC_FOR_ALLOC while your app is lagging, there is a big possibility that the bug is in a loop. Check where the line of code starts to trigger the GC then start tracing the code from there. In my experience, I mistyped my inner loop iterator which causes the program to make an infinite loop. I created a bug like this:
for(int i=0; i<list.size(); i++) {
for(int j=i+1 j<list.size(); i++) {
// I mistyped the iterator of integer j with i
// making an infinite loop which triggered the GC.
//appears many times
}
}
I encounter the same problem today.
I find a not ended loop in my code such as while(i < xx), but I not implement the i++ statement in the while body.
So the messages like you meet appeared.
Check your code firstly please.
My log:
D/dalvikvm: GC_FOR_ALLOC freed 549K, 9% free 7878K/8596K, paused 30ms, total 34ms
...freed 539K, 9% free 7888K/8596K, paused 30ms, total 30ms
...freed 1856K, 21% free 8083K/10108K, paused 51ms, total 51ms
...freed 582K, 9% free 7845K/8596K, paused 38ms, total 38ms
Explain:
When your app get memory more limit per app. Dalvik/Ant call garbage collector.
What limits memory for your App decide Dalvik/Ant. As you see for my app Dalvik decide 8596K(double case) and 8083K(one case).
And limits change in runtime.
And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.
PS: Decide when call GC teakes Dalvik/Ant. And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.
PS: In "Monitor android" see tab "Monitors", graphics "Memory". And use buttons: "pause(enabled)", Initiate GC, "Dump Java Heap" "Start Alocation Tracking(very useful)". And use official guide for this:
https://developer.android.com/studio/profile/am-memory.html?utm_source=android-studio.
As far as I understand App must not stop/pause working or crashes when VM call GC.
I'm loading an image resource in an Android application using setImageResource(), and for some reason this is using a lot of extra memory.
This is what I see when the image is loaded:
03-29 15:16:56.687: D/dalvikvm(23616): GC_FOR_ALLOC freed 42K, 11% free 16175K/18119K, paused 11ms
I/dalvikvm-heap(23616): Grow heap (frag case) to 23.154MB for 7675216-byte allocation
D/dalvikvm(23616): GC_CONCURRENT freed 3K, 8% free 23667K/25671K, paused 1ms+2ms
D/dalvikvm(23616): GC_FOR_ALLOC freed 0K, 8% free 23667K/25671K, paused 10ms
I/dalvikvm-heap(23616): Grow heap (frag case) to 39.624MB for 17272816-byte allocation
D/dalvikvm(23616): GC_CONCURRENT freed 0K, 5% free 40535K/42567K, paused 1ms+2ms
The jpg is 1599x1200, so I would expect the first allocation - 1599 * 1200 * 4 = 7675200.
What's going on with the 17MB allocation?
It is most likely you put your image into drawable-mdpi or just drawable directory, but run the app on the hdpi device. In this case image's dimensions will be scaled by 1.5.
1599 * 1200 * 4 * 1.5 * 1.5 = 17269200b ~ 17mb
You should probably move the image to drawable-nodpi directory to avoid unwanted scale.
I've got a relatively light weight app that seems to be using large portions of heap memory (in my opinion) and it doesn't shrink after garbage collection.
I haven't been able to identify any memory leaks by using the Eclipse Memory Analyzer. My knowledge of this tool is though very limited.
Snippet from LogCat:
(Note that this is only a small snippet from a log dump. The LogCat seems to output garbage collection messages almost no matter what I do inside my app, continously. The amount of free heap remains relatively stable though, indicating (to me) that there is no actual memory leak?)
01-22 17:04:51.672: D/dalvikvm(16274): GC_CONCURRENT freed 721K, 10% free 8074K/8968K, paused 4ms+7ms, total 33ms
01-22 17:04:53.742: D/dalvikvm(16274): GC_CONCURRENT freed 523K, 12% free 7977K/8968K, paused 4ms+5ms, total 29ms
01-22 17:04:54.012: D/dalvikvm(16274): GC_CONCURRENT freed 457K, 12% free 7941K/8968K, paused 3ms+2ms, total 29ms
01-22 17:04:56.432: D/dalvikvm(16274): GC_CONCURRENT freed 237K, 10% free 8116K/8968K, paused 2ms+2ms, total 22ms
01-22 17:04:58.632: D/dalvikvm(16274): GC_CONCURRENT freed 445K, 10% free 8094K/8968K, paused 3ms+3ms, total 33ms
01-22 17:05:00.332: D/dalvikvm(16274): GC_CONCURRENT freed 499K, 11% free 8013K/8968K, paused 1ms+10ms, total 33ms
01-22 17:05:00.582: D/dalvikvm(16274): GC_CONCURRENT freed 487K, 12% free 7916K/8968K, paused 3ms+6ms, total 38ms
01-22 17:05:02.382: D/dalvikvm(16274): GC_CONCURRENT freed 223K, 10% free 8107K/8968K, paused 3ms+3ms, total 23ms
01-22 17:05:03.882: D/dalvikvm(16274): GC_CONCURRENT freed 436K, 10% free 8107K/8968K, paused 9ms+12ms, total 76ms
01-22 17:05:05.392: D/dalvikvm(16274): GC_CONCURRENT freed 528K, 11% free 8059K/8968K, paused 2ms+3ms, total 35ms
01-22 17:05:06.962: D/dalvikvm(16274): GC_CONCURRENT freed 489K, 11% free 7998K/8968K, paused 4ms+3ms, total 32ms
01-22 17:05:07.212: D/dalvikvm(16274): GC_CONCURRENT freed 487K, 12% free 7928K/8968K, paused 3ms+3ms, total 29ms
01-22 17:05:08.832: D/dalvikvm(16274): GC_CONCURRENT freed 226K, 10% free 8094K/8968K, paused 3ms+3ms, total 22ms
01-22 17:05:12.152: D/dalvikvm(16274): GC_CONCURRENT freed 453K, 10% free 8080K/8968K, paused 4ms+3ms, total 48ms
The above is a result of "heavy use", involving spamming on buttons and changing orientation several times. My concern is the fact that only ~10% of the heap seems to be free/left for further expansions.
For your information, the XML file representing the current fragment's layout (at the time of the above output) is a ScrollView with a TableLayout inside, consisting of about 25 TableRow elements, perhaps this is the cause for such large hogging of heap memory?
Is this something to worry about at all?
Please let me know if you prefer to look at some of my code. Thanks in advance.
Update:
The app is basically just one Activity containing two fragments. One of said fragments get swapped out with other fragments based on user interaction.
Think of it as a typical Menu-Content app (like the default Android Contacts app). MenuFragment (Contacts list) on the left and some ContentFragment (Contacts details) on the right. So far there is not too much functionality
involved except for setting up the UI behavior. There is nothing happening in the background, no saving of states or similar. I've basically focused on making sure that
the correct fragment shows up when I select an item from my MenuFragment, that the correct layouts are drawn when a fragment launches, and that the correct fragment
is displayed when the user presses the back button.
The heap will adjust it's size automatically based upon the needs of your app. Small heaps are faster on the GC so Android will not start you out with a 64 MB heap if you don't need it. While you're app is using a lot of your current heap, the heap is extremely small for an Android 4.x app. A bare bones 4.x app alone will use up 7Mb. From what I see, you're fine.