I am trying to create cached image system for Android but the memory consumption just grows and grows. I looked through Android website for some ideas, but the issue just doesn't want to disappear.
Below is my code of getting the image from SD card, setting it and later destroying.
What am I doing wrong?
WeakReference<Bitmap> newImageRef;
public void setImageFromFile(File source){
if(source.exists()){
Bitmap newImage = BitmapFactory.decodeFile(source.getAbsolutePath());
newImageRef = new WeakReference<Bitmap>(newImage);
if(newImage != null){
this.setImageBitmap(newImage);
}
}
}
#Override
protected void onDetachedFromWindow() {
Bitmap newImage = newImageRef.get();
if (newImage != null) {
newImage.recycle();
newImage = null;
}
Drawable drawable = getDrawable();
if (drawable instanceof BitmapDrawable) {
BitmapDrawable bitmapDrawable = (BitmapDrawable) drawable;
Bitmap bitmap = bitmapDrawable.getBitmap();
if (bitmap != null){
bitmap.recycle();
}
}
this.setImageResource(0);
newImage = null;
newImageRef = null;
System.gc();
super.onDetachedFromWindow();
}
If you are using Android version >3.0 you dont have to call recycle()as the gc will clean up bitmaps on its own eventually as long as there are no references to it. So it is safe to remove recycle calls. They do nothing much here.
The code which you posted looks neat but are you sure there the leak is not happening somewhere else. Use Android Memory Analyzer tool to see where the leak is happening and then post the info.
Good luck.
Try to use Drawable.setCallback(null);. In Android 3.0 or newer, you don't even need to recycle because of more automatic memory management or garbage collection than in earlier versions. See also this. It has good information about bitmap memory management in Android.
As of this code it's hard to check if there is a detailed bug as this seems to cleary be a simplifyed version of the "full cache". At least the few lines you provided seem to look ok.
The main issue is the GC seems to be a little strange when handling Bitmaps. If you just remove the hard references, it will sometimes hang onto the Bitmaps for a little while longer, perhaps because of the way Bitmap objects are allocated. As said before recycling is not necessary on Android 3+. So if you are adding a big amount of Bitmaps, it might take some time until this memory is free again. Or the memory leak might be in anothe part of your code. For sophisticated problems like that its wise to check already proven solutions, before re-implementing one.
This brings me to the second issue: the use of weak refrences. This might not target the main problem, but is generally not a good pattern to use for image caches in Android 2.3+ as written by android doc:
Note: In the past, a popular memory cache implementation was a SoftReference or WeakReference bitmap cache, however this is not recommended. Starting from Android 2.3 (API Level 9) the garbage collector is more aggressive with collecting soft/weak references which makes them fairly ineffective. In addition, prior to Android 3.0 (API Level 11), the backing data of a bitmap was stored in native memory which is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash.
The way to go now is to use LRU Caches, which is explained in detail in the link provided about caching.
Related
I am using the Android BitmapFun sample code to manage bitmaps in my application. I have been experiencing garbled or duplicated images in a ViewPager. I have tracked this down to the following code in ImageCache.java:
/**
* Notify the removed entry that is no longer being cached
*/
#Override
protected void entryRemoved(boolean evicted, String key,
BitmapDrawable oldValue, BitmapDrawable newValue) {
if (RecyclingBitmapDrawable.class.isInstance(oldValue)) {
// The removed entry is a recycling drawable, so notify it
// that it has been removed from the memory cache
((RecyclingBitmapDrawable) oldValue).setIsCached(false);
} else {
// The removed entry is a standard BitmapDrawable
if (Utils.hasHoneycomb()) {
// We're running on Honeycomb or later, so add the bitmap
// to a SoftRefrence set for possible use with inBitmap later
mReusableBitmaps.add(new SoftReference<Bitmap>(oldValue.getBitmap()));
}
}
}
The bitmap is added to the reusable bitmap list when it is removed from the cache. In this case the bitmap is still in use by a ViewPager view. When a later view is created the bitmap (still in use) is reused and the bitmap appears in two positions in the ViewPager.
A bitmap that is removed from the LruCache isn't necessarily available for reuse. I have disabled the reuse of bitmaps in this code and am no longer having an issue. This problem doesn't occur with lower resolution images because the bitmaps aren't removed from the cache while in the range of the ViewPager's offscreen limit. I don't have an issue with 60 DPI images but see this issue frequently at 160 DPI. I think this would show up in the original BitmapFun sample with higher resolution images.
Anyone else experienced this problem or I am not understanding the issue properly?
Kevin
What I think the problem with the code is in the line
mReusableBitmaps.add(new SoftReference<Bitmap>(oldValue.getBitmap()));
That line adds a bitmap that was removed from LRU cache to a reusable bitmap set to be used for inBitmap re-use. It doesn't check whether it is still being used by an ImageView or not. If you try to re-use a bitmap that is still being used by an ImageView, the underlying bitmap will be replaced with another bitmap making it not valid anymore. My suggestion is to track whether a bitmap is still being used by an ImageView before adding it to the reusable bitmap set. I've created a sample github project for this issue. Tell me what you think with my solution.
According to Android Developers site, the Bitmap.recycle() method definition is:
Free the native object associated with this bitmap, and clear the reference to the pixel data
I've developed some applications which are creating / decoding a lot of bitmaps, and put the result bitmap objects to ImageViews. Sometimes I've got the famous exceptions such as:
bitmap size excceded vm budget
and
out of memory error
Also I'm sure I don't have any memory leaks that can cause that.
After a lot of searches, I discoverd the "recycle" method, and used it to free the bitmap's native memory when no longer needed. It seems like it helped a lot.
I'm asking if that's something I'm supposed to do on this situation, because
I know the system is doing this anyway without calling it explicitly (is it? maybe I'm wrong).
Should I use this method in situations like this?
In what situations should I use this method?
Should I use this method at all?
thanks in advance.
UPDATE:
google posted this guide recently, which says:
On Android 2.3.3 (API level 10) and lower, using recycle() is recommended. If you're displaying large amounts of bitmap data in your app, you're likely to run into OutOfMemoryError errors. The recycle() method allows an app to reclaim memory as soon as possible.
in what situations should I use this method?
The Bitmaps are GC'ed by GC whenever it decides.But in some situations it may get delayed.
And always remember thumb rule in java (Maybe it applies to othe P.L also).The speed of recycling objects by GC may not be same as speed of creating objects.So sometimes the GC is slow to in recycling.
so recycle() means If you want to free memory ASAP you should call recycle()
should I use this method at all??
This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap.But if you are facing the issues like bitmap size exceeded vm budget or out of memory error then you need to use this.
I do use it in operations where i know that bitmap is not going to be used anymore.
public static Bitmap getMaskedContactImage (Context context, Bitmap contactImageBitmap, int maskToBeApplied) {
Bitmap mask = BitmapFactory.decodeResource(context.getResources(), maskToBeApplied);
Bitmap output = Bitmap.createBitmap(mask.getWidth(),mask.getHeight(), Config.ARGB_8888);
final Rect finalRect = new Rect(0, 0, contactImageBitmap.getWidth(), contactImageBitmap.getHeight());
final Rect originRect = new Rect(0, 0, mask.getWidth(), mask.getHeight());
Canvas canvas = new Canvas(output);
Paint xferPaint = new Paint(Paint.ANTI_ALIAS_FLAG);
xferPaint.setColor(Color.BLACK);
xferPaint.setXfermode(new PorterDuffXfermode(Mode.DST_IN));
canvas.drawBitmap(contactImageBitmap, finalRect, originRect, null);
canvas.drawBitmap(mask, originRect, originRect, xferPaint);
contactImageBitmap.recycle();
mask.recycle();
return output;
}
In places like that one, im sure im not going to use the mask or the contactImage.
I found a really good resource for Bitmap processing that can be helpfull Displaying bitmaps.
Regards,
Alex
I have an application with a menu, where the menu items are screenshots from ViewAnimator's views. Everything is working fine. I do the screeshots with this simple sniplet, using drawing cache as written in many examples:
// Drawing cache is off, so build it manually and create scaled bitmap
layout.buildDrawingCache();
Bitmap bm = layout.getDrawingCache();
Bitmap bm_small = Bitmap.createScaledBitmap(bm, item_width, item_height, true);
In the same function I try to free all memory used for creating screenshot:
layout.destroyDrawingCache();
bm.recycle();
bm = null;
But unfortunatelly the garbage collector does not free this bitmap memory. I used also HPROF memory analyzing to find some references to Bitmap that cannot be freed but I did not succeeded. Important information is, that I am developing for Honeycomb Android 3.0, so the screenshots are quite big - every screenshot takes approx 3MB of memory and do not free it.
I don't understand, why recycle is not working in this example. I suspect, there is some very special problem in my setup: Android 3.0 Honeycomb + Hardware acceleration enabled + Large heap enabled + Using drawing cache. None of the hints I have found are not helping.
Please, can you explain, why recycle isn't working in this case? Any help will be very appreciated.
yes, I had this issue. it is very bad behavior because bitmap won't free itself. best advice is to use smaller bitmap tiles
and other advice is to use SoftReference<Bitmap> to store your data objects. SoftReferenced objects delete themselves when memory is needed. Careful though, you can wind up with missing objects.
the bitmap method though, is just flawed.
I have a bitmap cache in my Android app where the bitmaps are referenced via SoftReference. However the bitmaps are nulled too early. There can be 20 bitmaps max in the cache, if I load more, GC starts to null the SoftReferences. Without SoftReferences, I can have about 110 bitmaps in cache. Isn't SoftReference supposed to null just before OutOfMemoryError would happen?
No, the implication works the other way around:
It is guaranteed that the Java runtime will nullify SoftReferences, if any, before throwing a OutOfMemoryError. However, it does not guarantee that the SoftReference will get nullified only under this condition.
In my case, Hashmap(bitmap cache) got nulls if I got back from the other Activity.
So, I fixed my code like below pseudo-code.
void displayImageFunction() {
if(mImageCacheMap.containsKey(key)) {
Bitmap bitmapToShow = mImageCacheMap.get(url).get();
if(bitmapToShow != null) {
//> Image was cached well
//> Set "bitmapToShow" to UI
return;
}
}
//> Read from file DB(or Web) and...
Bitmap bmp = getBitmap(imageToLoad.url);
//> put it to Hashmap again...
mImageCacheMap.put(key, new SoftReference<Bitmap>(bmp));
//> Set "bmp" to UI
}
I think we should prefare for nulls.
Because, we cannot know when GC collects garbage. :)
When one should take care of Bitmap memory management or recycling bitmap in android ?
For example , there are few ways to create a bitmaps in android like following
Bitmap.createBitmap
Bitmap.createScaledBitmap
BitmapFactory
But when android allocate memory for bitmap which must be cleared so that in future application we won't face running out of memory error problem
In Android versions prior to 3.0, the Bitmaps are allocated outside of the VM. Android gets back this memory in Bitmap's finalize() method. You can let Android reclaim the memory faster by calling Bitmap.recycle() instead of waiting on the GC to call finalize() on them.
This is only really a problem if you're creating and discarding a lot of the Bitmaps. That is, if you are allocating memory faster then the GC can clean up the garbage left behind, at which point you get an OutOfMemoryError.
In android 3.0 and later, the Bitmap memory is allocated inside of the VM, so Bitmap memory can be reclaimed without having to call finalize() on them.
you recycle the bitmap whenever you don't need it. for example
#Override
protected void onPause(){
super.onPause();
if(bitmap !=null){
bitmap.recycle();
bitmap = null;
}
}
#Override
protected void onResume() {
super.onResume();
if(bitmap !=null){
bitmap.recycle();
bitmap = null;
}
}
P.S bitmaps memory are acting different from each devices, what i mean is
Growing Heap
is different from device to another
for example Bitmap size can exceed VM budget(Growing Heap) up to 240MB on the S4 tested and confirmed by personal testing and it doesn't cause OutOfMemoryError but in some other devices if the bitmap size exceed (Growing Heap) up to 16MB it may cause OutOfMemoryError its quite different from device to another because some devices has large heap while some not. and trust me dealing with Growing Heap is not easy task.
additional advice is to use android:largeHeap="true" in your application tag inside of the manifest.
`