I had a question related to whether or not (and how) I should store images loaded from the web. Let's say I am calling a web service from my Android app. In this web service I get a URL for an image on the web. I download and show this image on the left side of a list item in a ListView. My question is, what method should I use for possibly storing the image? Should I:
Save it to the SDCard, checking if it exists when the ListView is created (on subsequent requests) and re-downloading as necessary (while updating the image occasionally, in case it changes).
Store it in the cache using Context.getCacheDir(), but possibly being forced to re-download it more often since I cannot rely on the image staying in the cache.
Always download it and never store the image.
The image files themselves are fairly small, but I expect some users could have dozens of these small images downloaded/stored. Which would work best, and/or what is the preferred method?
As a side question, should I load all of the images in my ListView first (and possibly lock the UI for some time) or load them asynchronously but show a placeholder graphic in the meantime (which might be a bit more "ugly")? What's the standard here?
About where to store:
The answer depends on what is being downloaded and how much. Then you make a choice.
For instance: If you are downloading something that is temporary, less in number(less remote fetches) and size(less memory) and is local to an Activity then you should consider holding the images in memory using SoftReferences. SoftReferences can lead to refetches but since the number of items is small it should be affordable.
However, if the number of items to be downloaded exceeds a certain threshold(meaning more fetches and memory) you should consider reducing the fetches and also the Runtime memory consumption by caching them. Here you can either choose to save them on Sdcard or on temporary storage(cache directories local to app). For items that are small and hold meaning only in the context of Application(e.g thumbnails), the user will mostly not use it outside of your application. So, you can store such things in the cache directory. The best part of using them is that you don't have to clean the mess. It is handled automatically. It might lead to re-fetches though.
However, if the downloaded items are large in size and can stand alone outside the context of the application such as pictures, video, audio clips then SDcard should be your option.
You should also read: Handling large Bitmaps to avoid OOM error during BitmapFactory.decodeStream(..)
Note that you can also check to see if using a database can help here.See this
Some considerations while lazy loading items in a ListView:
You should do the loading in the background and not block the UI thread.You should consider showing a temporary image while the item is being downloaded. This is apparent in many native applications. For an example implementation of lazy loading see this.
Additionally, for large lists, you can implement the SlowAdapter pattern(check API demos).
It basically stalls download while the list is scrolling.
Example Projects that can help you here:
Romain Guy's Shelves project uses two level of caching wherein he employs an in-memory cache(HashMap containing SoftReferences) and storage on Sdcard.Browse Source code here
There are also some open source libraries that Mark Murphy wrote(CWAC) and DroidFu that can help here.
Good Luck!
In regards to your "side question" -- I think that loading them asynchronously would be the preferred behavior, especially since you need to consider that with network transactions, it might not just be "lock the UI for some time", but "lock the UI permanently" in case it never loads.
If you consider this behavior ugly, though, you could set a timer (1 or 2 seconds) that gives a few of the images a chance to load, and if they have all loaded or the timer has expired, go ahead and show the UI anyway with placeholder images and let the rest load asynchronously. This would be the way to go to prevent permanent locks anyway.
As for the first part of your question, I think it is somewhat dependent on the context and type of images you are displaying. With most web assets, though, I think #2 would be the preferred approach, since you certainly don't want to download multiple times in the same session, but you probably don't want to eat up permanent storage either.
In regards to your "side question" -- I think that loading them asynchronously would be the preferred behavior, especially since you need to consider that with network transactions, it might not just be "lock the UI for some time", but "lock the UI permanently" in case it never loads.
To avoid this , If we are talking about WebImageView by droid-fu you can change the ImageLoader.java initialize() function to this
static int alive=-1;
public static synchronized void initialize(Context context) {
if (executor == null) {
executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);
}
else if(alive==executor.getActiveCount()){
executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);
}
alive=executor.getActiveCount();
if (imageCache == null) {
imageCache = new ImageCacheHope(context, 25, 5);
}
}
I wrote an Android Image Manager that handles caching transparently (memory and disk). The code is on Github https://github.com/felipecsl/Android-ImageManager
Related
My app uses images from a URL and I want to reduce resources usage for both server and client.
I wonder if the Android SDK already offers something for this (if there's some standard way to do it) or I just have to figure it out.
What I have in mind is:
download images on local storage (external or internal) when accessing content (lazy loading, progress bar) and keeping them there for next use
update images (download and replace) if changed on server (keep checksum in a database that is queried when the application is started)
in order to avoid excessive local disk usage (they are quite big), delete images for content that has not been accessed for N days. This is done while loading the app or in a background asynchronous service
Should I do this step by step or is there something that already takes care of it. Are there libraries to do this properly?
I think Picasso library is best for this, it has many capabilities and is really easy to use, its features include smooth image caching (the features you need), image processing and Async downloading from URL too. It has so many useful features.
Here is its url link
http://square.github.io/picasso/
Is there a general guideline or rule of thumb on when I should cache a photo?
For example I have a grid view of smaller icon images. This page isn't at the beginning of the app so there's no guarantee a user sees it, these images could change server-side but for the most part they won't. Should I cache them because there are so many or not worry about them because they are small?
Another example would be if I click on one of the images mentioned above it will lead me to a view with one larger image, should I cache this image since it's larger or should I let the user make a network request each time?
I'm not looking for an answer for these specific questions, but rather a guideline to follow.
To clarify by caching I mean saving the file to storage. Also, is there a better method than this?
Thanks for the help!
Caching is an important feature in user experience, so even if there's no guarantee the user sees that particular 'page', it a nice thing to have.
Saving images in a cache depends directly on many variables:
- How much time does it take to regenerate images if not cached
- How many images are we talking about
- How often do they change
- What size is each image
For example, having 100 thumbnails of images that change every month makes a lot of sense. Caching 200 images with 1024x768 resolution that change very often doesn't.... or does it? The answer is very variable.
Also cache should always have storage boundaries. Even in the previous example with the large images, you could limit the cache to a a certain storage capacity.
Normally the cache saves a local copy of the most recently used items. But you can implement a more sophisticated algorithm, for example, saving the most visited images instead of caching the most recently used.
I have a listview and each listview item when clicked opens a gallery (conating 30 + images ) to be downloaded (using the urls).I don't want to re - download the images on next visit and also want the images to be present when i click on list in offline mode.
I went through several links in SO and am a bit confused on which approach to follow:
1> Use bytearray and store the images in sqlite db.
2> use context -> getExternalCacheDir() to store it on the
external memory (this wont work on devices with no external
memory.)
3> Use SoftReferences as suggested in following link
http://android-developers.blogspot.in/2010/07/multithreading-for-performance.html
Please help to guide me on the best approach to handle around 1000 + images which works in offline mode as well.
1000 images.....I sure hope they're thumbnails or you're going to end using a lot of storage space.
You should really only cache what you need and what images are used repeatedly. Both options 1 and 2 are dependant on the phone even having storage space, if there's no space then you won't be caching much to disk. 3 won't store images permanently, if the app is put in the background and gets killed and so will the cache.
It's hard to say what the correct decision here is without knowing the inner workings and requirements of the app.
Just going by what you want then I would say go with several solutions
If there's external storage write to that, if not use internal storage, if there's not enough space internally use the soft references.
I have always found that out of the box caching solutions never fit quite right with my apps and wind up writing my own cache. Sorry I can't give a better answer.
PS. If you're not careful with 3 you might download too much and run into an OutOfMemoryException.
PPS. 3 can also throw a RejectedExecutionException which is caused by too many async tasks being started at once (eg scrolling quickly through a listview that gets an image via asynctask)
I'm using Jake Wharton's DiskLruCache lib.
I'm curious about app performance, caching strategy, using caching both in a view and across a whole application. Most of the time, the image won't change.
Let's say for example I have a 320x320 photo on my server. I open the stream, save the image.
In my list views, I show bitmaps and in the detail, I show a larger image. Should I save a thumbnail bitmap too? Is that more efficient?
What is your experience with sharing the cache "object" across the entire app (let's say I have multiple views that might leverage the same data. What are the issues with this?
For the sake of performance and currency, what if the image changes on the server. What's the best strategy to know that it's changed? I don't have access to modified date. Only size and yet, I don't really want to query size every time either. Set a flag in the app on the server and then query the flag?
In a traditional application (if there is such a thing), what's the best practice for clearing the cache from time to time? (indent weirded out.)
(I was inspired to write this after seeing all of the performance improvements by Facebook in iOS. I don't have billions to do caching but I would like to at least be smart about it! LOL)
A lot of these answers depend on the type of app you're writing, how important image updates are (and how likely images will change, etc), and total images produced. Aside from disk caching, you should be using memory caching as well, especially in ListViews and other areas where the same images will be scrolled through repeatedly. Look at LruCache and read the Caching Bitmaps entry from Google.
320x320 is probably too big for a listview, you will likely want to create thumbnails (depending on device, and how you're implementing your listviews).
1) You should be using Disk caching fairly aggressively (how you define that is up to the app you're writing). Use the external storage directory, and if they have a few GB left over, it's not an issue if you take 100 mb for your app for instance. It can all be cleared away if it's ever needed anyway.
2) There shouldn't be an issue. Disk IO (even to a flash medium) should never be handled on the main thread. Use AsyncTasks to load the images. There can only be one main foreground activity at once anyway, and while an activity is sleeping, it shouldn't be trying to read from the disk anyway.
3) Again this depends on how you're implementing your app. You should be able to get additional information when retrieving the file (even Apache can tell your app the last modified date).
3.1) You can have a sqllite db that keeps track of how often certain images are used, and most recent read. If the most recent read is a few days old, let that image expire.
Edit: There's a library from Jake Wharton now called Picasso that I would recommend using, which handles the Network/local IO as well as memory and disk caching. Check it ou here: http://square.github.io/picasso/ . A lot of what you will need to do can be accomplished with one line: Picasso.with(this).load(imageFileURL).into(imageView);
I have to believe there's a way to clear image data from memory once it's no longer required, but despite exhaustive searching I can't find a solution. Both stack and the google android dev list are full of questions regarding OOM errors, specifically "bitmap size exceeds VM budget", but I still don't see a clear answer.
I understand there are hard memory limits on devices, and I understand it's not realistic to load up and display or cache large amounts of image data, but there should be away to discard data that's no longer required.
For example, imagine this very basic hypothetical app, that emulates a lot of the behavior of the native gallery app:
An image gallery that allows the user to peruse images from a remote server.
There might be any number of images on that server.
The app displays 1 image at a time, and allows a user to go back or forward 1 image at a time through button presses or swiping.
There'd be a maximum of 3 images rendered at any one time (so the user can see the one immediately to the left or right of the current image when swiping). All other image data should be discarded.
Images are loaded using URL.openStream and Drawable.createFromStream or BitmapFactory.decodeStream. Streams are closed appropriately.
Images are sized appropriately on the server before being fetched.
Loading happens in AsyncTasks. Tasks that are no longer needed (due to moving away from an image with an incomplete task) are cancelled. Any references in the AyncTask are WeaklyReferenced.
When any image is no longer required, it's "cleared" via:
getBackground().setCallback(null)
Listeners are set to null
setImageDrawable/Bitmap(null)
removeView
This simple construct, that takes into account all the suggest practices I'm aware of, will inevitably crash with an OOM error at some point. Using BitmapFactory.Options inSampleSize and inPreferredConfig will delay the inevitable, but not forever, and at the cost of image quality. In this example, I've used remote images, but the issue exists with images stored in /assets/ or in internal memory, etc.
My feeling is that if we can display X amount of image data at one point, and we take all steps to remove that image data from memory, we should be able to display that same amount of data later, without having to compensate for what has happened before.
With the sheer quantity of questions about this very issue, I'd hope to have a standard solution documented, but if there is one, I can't find it. I've seen answers posted by Romain Guy, who otherwise seems very generous with his knowledge and active in the community, that say something like "Simple. Don't use so much memory". OK. Tell me how.
I should also mention that System.gc does nothing to help this. I'm also aware of bitmap.recycle, but unless I'm mistaken this can't be used in this fashion.
Am I missing something fundamental? Is there a way to discard image data once it's no longer being used? What is missing from the above to create a simple photo gallery? Assuming the built-in gallery app uses the framework and not the NDK, I imagine there has to be a way...
TYIA.
/this question has also been posted on the android developer google group list.
Through my work with Prime I found a few tips, one of which you have not mentioned. When you decode your Bitmaps make sure to use the inPurgeable and inInputShareable flags in your BitmapFactory.Options. That will help a little bit but I would recommend you look at my implementation of image loading in Prime. I use it in all of my products without any memory issues. I have found that 95% of memory problems are from the incorrect usage of the Bitmap class.
There is a very detailed article about the use of bitmaps on the android developer website.
Did you look at it ?
It explains how to load, cache and display bitmaps efficently and how to get rid of this famous OutofMemoryError.
There is also a sample application from an image gallery.
I think that's what you're looking for.