I have an app that shows a lot of activities, each one showing a bitmap that fits the 100% of the width of the screen and normally more than the 100% of the height.
When you touch the screen, a new activity is created, and in the previous activity is being called finish and recycle for the bitmap:
public void clean() {
if(this.myBitmap != null){
Log.d(DEBUG_TAG, " Cleaning "+this);
this.myBitmap.recycle();
this.myBitmap=null;
System.gc();
}
}
the problem is that the memory required is growing and growing and when i am launching more than 12-13 activities these messages are being showed at logcat:
05-05 16:03:02.909: I/dalvikvm-heap(24794): Clamp target GC heap from 65.790MB to 64.000MB
05-05 16:03:02.969: D/dalvikvm(24794): GC_EXPLICIT freed 71K, 5% free 59008K/61680K, paused 2ms+13ms, total 55ms
05-05 16:03:03.559: I/dalvikvm-heap(24794): Clamp target GC heap from 67.197MB to 64.000MB
05-05 16:03:03.569: D/dalvikvm(24794): GC_EXPLICIT freed 418K, 2% free 60521K/61680K, paused 3ms+28ms, total 109ms
after a few activities more i got this crash:
05-05 16:03:05.049: E/AndroidRuntime(24794): java.lang.OutOfMemoryError
05-05 16:03:05.049: E/AndroidRuntime(24794): at android.graphics.Bitmap.nativeCreate(Native Method)
05-05 16:03:05.049: E/AndroidRuntime(24794): at android.graphics.Bitmap.createBitmap(Bitmap.java:809)
05-05 16:03:05.049: E/AndroidRuntime(24794): at android.graphics.Bitmap.createBitmap(Bitmap.java:786)
05-05 16:03:05.049: E/AndroidRuntime(24794): at android.graphics.Bitmap.createBitmap(Bitmap.java:718)
I dont know what is going wrong here, i am doing recycle() of the bitmap and also i tryed with and without System.gc(), in both cases i got the crash
Its a known bug, its not because of large files. Since Android Caches the Drawables, its going out of memory after using few images. But i found alternate way for it, by skipping the android default cache system.
Soultion:
Create a drawable folder in Assets and move the images to "drawable" folder in assets and use the following function to get BitmapDrawable
public static Drawable getAssetImage(Context context, String filename) throws IOException {
AssetManager assets = context.getResources().getAssets();
InputStream buffer = new BufferedInputStream((assets.open("drawable/" + filename + ".png")));
Bitmap bitmap = BitmapFactory.decodeStream(buffer);
return new BitmapDrawable(context.getResources(), bitmap);
}
Refrence : https://stackoverflow.com/posts/6116316/revisions
Also that add the line below in your manifest file
android:largeHeap="true"
Use DDMS to grab a heap dump and do some analysis on the dump using Eclipse Memory Analyzer (built into Eclipse ADT or can run stand-alone). What your looking for is objects that you allocated but are not being freed. One possibility is that you are leaking activities. You say the OOM error occurs after launching 12-13 activities. Only one of the activities should be visible at a time so you can free memory from the paused activities in the onPause() or onStop() method. Again, analyzing the heap dump will give you a good idea of what is eating up the heap memory.
FYI - Bitmap#recycle() is only really necessary on Gingerbread and lower devices. On newer version of the OS bitmaps are stored on the heap and are garbage collected like other objects. See, the "Manage Memory on Android 2.3.3 and Lower" section of this document: https://developer.android.com/training/displaying-bitmaps/manage-memory.html
Related
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.
i have an android app with 3 acitivtys:
A1 --starts--> A2 --starts--> A3 --when finished his process: starts--> A1
(so i don't "finish();" an app. i start the next activitys with "startActivity(..);" the whole time after userinteraction)
so there is a loop in these 3 activitys.
On each Activity, i display 3-9 pictures, located on the SD-card, which i load with my following function:
try
{
Uri selectedImageURI = Uri.parse(strImagePath);
File imgFile = new File(getRealPathFromURI(selectedImageURI, c));
Bitmap myBitmap = BitmapFactory.decodeFile(imgFile.getAbsolutePath());
ivTmp.setImageBitmap(myBitmap);
}catch (Exception e)
{
return null;
}
This all works.
But sometimes (after looping a few times through my activitys), my app crashes..
Logcat tells me:
01-16 13:42:15.863: DEBUG/dalvikvm(23161): GC_BEFORE_OOM freed 10K, 9% free 59019K/64400K, paused 29ms, total 30ms
01-16 13:42:15.863: ERROR/dalvikvm-heap(23161): Out of memory on a 8018704-byte allocation.
01-16 13:42:15.863: ERROR/AndroidRuntime(23161): FATAL EXCEPTION: main
java.lang.OutOfMemoryError
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:502)
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:355)
at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:785)
at android.content.res.Resources.loadDrawable(Resources.java:1965)
at android.content.res.Resources.getDrawable(Resources.java:660)
at android.widget.ImageView.resolveUri(ImageView.java:616)
at android.widget.ImageView.setImageResource(ImageView.java:349)
at <MyApp>.MyActivity$6.run(MyActivity.java:143)
at android.os.Handler.handleCallback(Handler.java:725)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5039)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
at dalvik.system.NativeStart.main(Native Method)
Someone can give my some tips how to handle the crashes?
Maybe its because my activitys are set to state "paused" instead of closing them correctly?
for quick fix you can add
android:largeHeap="true" in your manifest application tag
link here:
I face OOM problem for my table in kindle and nook
Heap size (large)
android:largeHeap="true"
there specification is mentioned to use larger heap link here:
edit: use Caching Bitmaps technique link here
I had the similar problem while displaying high resolution images. I have searched and applied all the android bitmap solutions given in http://developer.android.com/training/displaying-bitmaps/index.html and the following caches mekanism in the link. but none of them work. not any right solution anywhere. Then I figured out that the problem is : I couldnt use the drawable folder structure right. I was keeping high resolution images in mdpi and hdpi folders . this cause android scale up the images to the ultra sizes. 100 kb image was causing 20 mb increase in memory thanks to the android monitor / memory section.
so I have added these ultra resolution images to xxhdpi folder , then It was FIXED suddenly. then my image slider work flawlessly
Yeah android doesnt immediately destroy activities when they are not visible to the user, but there are a number of lifecycle methods that are called depending on the current state. Check out http://developer.android.com/guide/components/activities.html#Lifecycle
You could try finishing the activities in onStop() or onDestroy() as these will be called when the activity is not visible and when the system runs low on memory respectively. :-)
This is due to the high resolution of image you have to scaling the bitmap use the following code
Bitmap myBitmap = BitmapFactory.decodeFile(imgFile.getAbsolutePath());
int h = 100; // height in pixels
int w = 100; // width in pixels
Bitmap photoBitMap = Bitmap.createScaledBitmap(myBitmap,h, w, true);
ivTmp.setImageBitmap(photoBitMap);
I know this subject has been discussed a lot, but I can't find workaround/solution for my memory problem.
Problem is that in android 4.0 garbage colletor does not work (at least I am starting to believe so). Below is a snapshot traces from acer iconia tablet(4.0, 48M heap) and motorola defy(2.2, 30M heap) about same situation in my code. That is, get next stage from game -> ditch the old images and load new ones to memory.
4.0
08-15 21:33:07.020: V/ThemePacket(25564): debugSaveMemInfo: D:23.61 N:2.12 O:2.65
08-15 21:33:07.020: ThemePacket(25564): ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
08-15 21:33:07.050: D/dalvikvm(25564): GC_EXPLICIT freed 4K, 74% free 10909K/41671K, paused 2ms+3ms
08-15 21:33:07.260: V/ThemePacket(25564): debugSaveMemInfo: D:23.61 N:2.12 O:2.65
08-15 21:33:07.260: V/DrawableResourceDataReference(25564): Bitmap size is: w:1875 h:1250 Asking for: w:1215 h:780
08-15 21:33:07.280: D/dalvikvm(25564): GC_FOR_ALLOC freed 36K, 74% free 10940K/41671K, paused 18ms
08-15 21:33:07.410: I/dalvikvm-heap(25564): Forcing collection of SoftReferences for 9375016-byte allocation
08-15 21:33:07.450: D/dalvikvm(25564): GC_BEFORE_OOM freed <1K, 74% free 10940K/41671K, paused 44ms
08-15 21:33:07.510: E/dalvikvm-heap(25564): Out of memory on a 9375016-byte allocation.
2.2
08-15 22:10:53.132: V/ThemePacket(15074): GetStage(1)
08-15 22:10:53.155: V/ThemePacket(15074): debugSaveMemInfo: D:2,73 N:3,36 O:15,97
08-15 22:10:53.155: V/ThemePacket(15074): ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
08-15 22:10:53.218: D/dalvikvm(15074): GC_EXPLICIT freed 911 objects / 115904 bytes in 54ms
08-15 22:10:53.241: V/ThemePacket(15074): debugSaveMemInfo: D:2,73 N:3,36 O:9,02
08-15 22:10:53.241: V/DrawableResourceDataReference(15074): Bitmap size is: w:1875 h:1250 Asking for: w:885 h:600
08-15 22:10:53.241: V/DrawableResourceDataReference(15074): Scaling down by 2
// all goes fine
Note these lines:
debugSaveMemInfo: D:23.61 N:2.12 O:2.65
ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
debugSaveMemInfo: D:23.61 N:2.12 O:2.6
vs.
debugSaveMemInfo: D:2,73 N:3,36 O:15,97
ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
debugSaveMemInfo: D:2,73 N:3,36 O:9,02
And to decrypt those traces a bit, this is how I get the memory info:
Debug.MemoryInfo memInfo = new Debug.MemoryInfo();
Debug.getMemoryInfo(memInfo);
double nativeMem = memInfo.nativePss/(double)1024;
double otherMem = memInfo.otherPss/(double)1024;
double dalvikMem = memInfo.dalvikPss/(double)1024;
//some formatting...
Log.v(LOG_TAG, "debugSaveMemInfo: D:" + dalvik + " N:" + nativeM + " O:" + other);
Clear bitmaps from memory beef looks like this:
// Bitmap mBitmap
mBitmap.recycle();
mBitmap = null;
and yes, I have debugged the code in both platforms and everything goes exactly the same way in my code. So if anyone is still reading this, some questions arise. Why recycling bitmaps in 4.0 does not free any memory? Isn't the GC suppose to be finding every bits of free memory before throwing OoM? If I reduce the amount of memory used totally, so that I prevent OoM, those bitmaps are eventually freed. But not when I would need the memory...
To make things more interesting, I took a hprof file from case where the ghost bitmaps are in memory and you know what, they are not! Memory analyzer says that dalvik heap is about 10M at the same moment when I print those 23M figures to the screen and get OoM from that 9M allocation. I am kind of out od ideas here so any suggestions are welcome. I guess my next solution is to lower the image quality if I get OoM
This happens when the app loads from Splash screen to Main page. It happens only on the device not on simulator:
05-17 08:10:16.627: I/dalvikvm-heap(14021): Grow heap (frag case) to 20.580MB for 2424256-byte allocation
05-17 08:10:16.666: D/dalvikvm(14021): GC_FOR_ALLOC freed 1K, 3% free 21000K/21511K, paused 21ms
05-17 08:10:16.697: D/dalvikvm(14021): GC_CONCURRENT freed 116K, 3% free 20885K/21511K, paused 2ms+2ms
05-17 08:10:16.720: D/dalvikvm(14021): GC_FOR_ALLOC freed 44K, 4% free 20841K/21511K, paused 10ms
05-17 08:10:16.728: I/dalvikvm-heap(14021): Grow heap (frag case) to 24.533MB for 4310896-byte allocation
I used Ecplise MAT - the byte allocation resolved - Android.Graphics.Bitmap $preloaded images...
The device I am using is Google Nexus Prime, Android 4.0
Has anyone encountered the same? Can someone throw some expertise....
I have experienced the same issue and found a solution to it.
Are you loading your bitmaps from resource? if so try placing them in corresponding drawable folders instead of keeping them in "drawable" or "drawable-mdpi".
When you have your image resources in plain drawable folder, to the system it means drawable-mdpi. Therefore devices with high or extra high dpi (Galaxy Nexus I believe is Extra high) will expand that resource to match the dpi of the device.
If you only have 1 size for your resources, put them in drawable-nodpi and it will be used as is. However some of your layouts may be affected by this, so I kept certain images in the drawable folder (like button images etc.) and moved backgrounds and other bigger resources into drawable-nodpi.
Hope this helps ;)
You are probably trying to decode a very big Bitmap which results in an OutOfMemory exception. It means that the operation you are trying to achieve is exceeding the VM Budget allowed for each application on your device, in terms of heap memory consumption (which appears to be 24 MB on your device, probably more on your emulator which is why it doesn't happen there!).
Try to sample your Bitmapby a factor of two for instance:
BitmapFactory.Options o = new BitmapFactory.Options();
o.inSampleSize = 2;
Bitmap b = BitmapFactory.decodeFile(pathToBitmap, o);
I am running a stack of image filters and seem to be hitting some memory issues.
At the beginning of the image processing I am using this much memory:
GC_FOR_MALLOC freed 3K, 45% free 3237K/5831K, external 47586K/49634K, paused 17ms
At the end I am using this much (after all processing is finished):
GC_EXTERNAL_ALLOC freed 5K, 16% free 16056K/18951K, external 51430K/52196K, paused 23ms
After I am finished with each bitmap I set it to recycle and to null:
someBitmap.recycle();
someBitmap = null;
Is there anything else I should be doing to them? Is there any cleanup I should do to the Canvas being used?
Also my filters are objects instantiated like:
BoxBlurFilter blurFilter = new BoxBlurFilter();
Is there anything I should do to release them? In iOS memory allocated with "new" I am responsible to free.
Sorry for the trivial memory management questions, but I am quite new to Android dev and things are quite different than iOS.
Thank you!
EDIT 2, I removed my full filter code.
So after setting the filter instances to null and all the byte arrays to null (in the code above and in the filter objects) I now have approximately the same size heap as I did before I run the filter:
GC_EXPLICIT freed 5126K, 77% free 3243K/13703K, external 51430K/53478K, paused 18ms
That means it went from 16mb being used to 3.2mb. Much better!
So I guess the answer to my question is make sure you set everything to null if you want it to be freed.