Develop Reference

When is an Image Cache removed from disk in fresco android?

I need to know how long a cached version of URI would be on the disk in fresco cache?

As it is written at http://frescolib.org/docs/caching.html#trimming-the-caches:
When configuring the image pipeline, you can set the maximum size of
each of the caches. But there are times when you might want to go
lower than that. For instance, your application might have caches for
other kinds of data that might need more space and crowd out Fresco's.
Or you might be checking to see if the device as a whole is running
out of storage space.
Fresco's caches implement the DiskTrimmable or MemoryTrimmable
interfaces. These are hooks into which your app can tell them to do
emergency evictions.
Your application can then configure the pipeline with objects
implementing the DiskTrimmableRegistry and MemoryTrimmableRegistry
interfaces.
These objects must keep a list of trimmables. They must use
app-specific logic to determine when memory or disk space must be
preserved. They then notify the trimmable objects to carry out their
trims.
So, if you don't specify DiskTrimmable or MemoryTrimmable while configuration your ImagePipeline will be using default DiskTrimmable, MemoryTrimmable. So, after looking for default values in sources i found this:
private static DiskCacheConfig getDefaultMainDiskCacheConfig(final Context context) {
return DiskCacheConfig.newBuilder()
.setBaseDirectoryPathSupplier(
new Supplier<File>() {
#Override
public File get() {
return context.getApplicationContext().getCacheDir();
}
})
.setBaseDirectoryName("image_cache")
.setMaxCacheSize(40 * ByteConstants.MB)
.setMaxCacheSizeOnLowDiskSpace(10 * ByteConstants.MB)
.setMaxCacheSizeOnVeryLowDiskSpace(2 * ByteConstants.MB)
.build();
}
So conclusion is next: when the memory is full (40 ByteConstants.MB or 10 ByteConstants.MB or 2 ByteConstants.MB) - Fresco will delete old records and write new records(images).
Maybe Fresco use this method.

Android Bitmap memory leak

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.

Bitmap recycle with largeHeap enabled

Before enabling largeHeap option, I was handling large bitmaps and it's consume almost the entire memory available for the application, and recycling it over navigation and loading new ones works round on almost the full heap available. However when some operations needs a bit more memory the application crashes. So I enabled largeHeap=true to have a bit more memory.
But doing this has a unexpected behavior, it's looks like that recycle() method of bitmaps do not work most of times, and the application that worked in 58Mb of memory (and exceeds sometimes throwing a OutOfMemoryException) now consumes memory exponentially and keeps growing (for now the test I did came to 231Mb allocated memory), the expected behavior is that the memory management keeps working and the application will not use more than 60Mb.
How can I avoid that? Or efficiently recycle bitmaps?
EDIT: Actually, I made it give a OutOfMemoryError when allocating more than 390Mb of memory on the device.
Reading GC_* logs shown that only GC_FOR_ALLOC that freed 3.8Mb sometimes, but almost never other GC runs freed something.

You should probably have a look at Displaying Bitmaps Efficiently which includes several ways to handle large Bitmaps Efficiently,
Loading Large Bitmaps Efficiently
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
This will give you the size of the image before downloading and on that basis you can check the size of your device and scale it using calculateInSampleSize() and decodeSampledBitmapFromResource() given in the explanation of docs.
Calculating how much we need to scale the image,
First way
if (imageHeight > reqHeight || imageWidth > reqWidth) {
if (imageWidth > imageHeight ) {
inSampleSize = Math.round((float)imageHeight / (float)reqHeight);
} else {
inSampleSize = Math.round((float)imageWidth / (float)reqWidth);
}
}
Second way
int inSampleSize = Math.min(imageWidth / reqWidth,imageHeight / reqHeight);
The you can set the inSampleSize,
options.inSampleSize = inSampleSize;
Then finally make sure you call,
options.inJustDecodeBounds = false;
else it will return Bitmap as null
Processing Bitmaps Off the UI Thread
Processing Bitmap on UI thread is never safe so its always better to do that in a background thread and update UI after the process is completed.
Caching Bitmaps
LruCache is available from API 12 but if you are interested it using below versions it is also available in Support Library too. So caching of Images should be done efficiently using that. Also you can use DiskLruCache for images where you want then to remain for longer period in extenal storage.
Clearing the Cache
Sometimes when your image size is too large even caching the image causes OutOfMemoryError so in that case its better to clear the cache when your image is out of the scope or not used for longer period so that other images can be cached.
I had created a demo example for the same, you can download from here

Your case behaves as expected. Before Honeycomb, recycle() was unconditionally freeing the memory. But on 3.0 and above, bitmaps are part of normal garbage collected memory. You have plenty of RAM on the device, you allowed the JVM to allocate more than the 58M limit, now the garbage collector is satisfied and has no incentive to reclaim memory occupied by your bitmaps.
You can verify this by running on an emulator with controlled amount of RAM, or load some memory consuming service on your device - GC will jump to work. You can use DDMS to further investigate your memory usage.
You can try some solutions for bitmap memory management: Bitmaps in Android Bitmap memory leaks http://blog.javia.org/how-to-work-around-androids-24-mb-memory-limit/, but start with the official Android bitmap tips, as explained in #Lalit Poptani's detailed answer.
Note that moving the bitmaps to OpenGL memory as textures has some performance implications (but perfect if you will render these bitmaps through OpenGL in the end). Both textures and malloc solutions require that you explicitly free the bitmap memory which you don't use anymore.

Definitely #Lalit Poptani answer is the way to do it, you should really scale your Bitmaps if they are very large. A preferable way is that this is done server-side if this is possible, since you will also reduce NetworkOperation time.
Regarding the implementation of a MemoryCache and DiskCache this again is the best way to do it, but I would still recommend to use an existing library, which does exactly that (Ignition) and you will save yourself a lot of time, and also a lot of memory leaks, since because your Heap does not get emptied after GC I can assume that you probably have some memory leaks too.

To address your dilemma, I believe this is the expected behaviour.
If you want to free up memory you can occasionally call System.gc(), but really you should for the most part let it manage the garbage collection itself.
What I recommend is that you keep a simple cache (url/filename to bitmap) of some sort which keeps track of its own memory usage by calculating the number of bytes that each Bitmap is taking up.
/**
* Estimates size of Bitmap in bytes depending on dimensions and Bitmap.Config
* #param width
* #param height
* #param config
* #return
*/
public static long estimateBitmapBytes(int width, int height, Bitmap.Config config){
long pixels=width*height;
switch(config){
case ALPHA_8: // 1 byte per pixel
return pixels;
case ARGB_4444: // 2 bytes per pixel, but depreciated
return pixels*2;
case ARGB_8888: // 4 bytes per pixel
return pixels*4;
case RGB_565: // 2 bytes per pixel
return pixels*2;
default:
return pixels;
}
}
Then you query how much memory the app is using and how much is available, maybe take half of that and try to keep the total image cache size under that, by simply removing (dereferencing) the older images from your list when your are coming up against this limit, not recycling. Let the garbage collector clean up the bitmaps when they are both derefrrenced from your cache and are not being used by any views.
/**
* Calculates and adjusts the cache size based on amount of memory available and average file size
* #return
*/
synchronized private int calculateCacheSize(){
if(this.cachedBitmaps.size()>0){
long maxMemory = this.getMaxMemory(); // Total max VM memory minus runtime memory
long maxAllocation = (long) (ImageCache.MEMORY_FRACTION*maxMemory);
long avgSize = this.bitmapCacheAllocated / this.cachedBitmaps.size();
this.bitmapCacheSize = (int) (maxAllocation/avgSize);
}
return this.bitmapCacheSize;
}
I would recommend you stay away from using recycle(), it causes a lot of intermittent exceptions (like when seemingly finalized views try to access recycled bitmaps) and in general seems buggy.

You have to be very careful with handling bitmaps on Android. Let me rephrase that: you have to watch out handling bitmaps even on a system with 4 gigs of RAM. How large are these guys and do you have a lot? You might have to chop and tile it up if it's large. Remember that you use using video RAM, which is a different animal than system RAM.
Pre-Honeycomb, the Bitmaps were allocated on the C++ layer, so that RAM usage was invisible to Java and couldn't be accessed by the garbage collector. A 3 MP uncompressed Bitmap with the RGB24 colorspace uses around 9-10 megabytes (around 2048x1512). So, larger images can easily fill up your heap. Also remember that in whatever is being used for video RAM (sometimes dedicated RAM, sometimes shared with system), the data is usually stored uncompressed.
Basically, if you are targeting pre-Honeycomb devices, you almost have to manage Bitmap object as if you were coding a C++ program. Running the bitmap recycle() onDestory() usually works if there aren't many images, but if you have a ton of images on the screen, you may have to handle them on-the-fly. Also, if you launch another activity, you may have to consider putting in logic into onPause() and onResume().
You can also cache the images using the Android file system or SQLite when they aren't in video RAM. You may be able to get away with caching it in RAM if you are using a format like .jpg or a .png with a lot of repeated data/

Computing the optimal size of a LruCache

Is there a formula I could use to compute for the size of a LruCache?
Could I base it on the VM memory statistics offered by Runtime.getRuntime().
I am storing bitmap files - the file data, and not the decompressed Bitmap.

Here's an excerpt from Caching Bitmaps guide:
// Get memory class of this device, exceeding this amount will throw an
// OutOfMemory exception.
final int memClass = ((ActivityManager) context.getSystemService(
Context.ACTIVITY_SERVICE)).getMemoryClass();
// Use 1/8th of the available memory for this memory cache.
final int cacheSize = 1024 * 1024 * memClass / 8;

You are thinking the wrong way around your problem. Instead of trying to make the cache fit the available memory, you should have the system remove things from the cache when memory goes down. And that is what soft references are used for.
There are some available Java implementations for caches based on soft references like Googles MapMaker, but I'm not sure how much footprint those libraries bring with them and if you maybe are better suited with a selfmade implementation on Android.

Can't free memory of built drawing cache in Android 3.0

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.