Has anyone else encountered problems with the performance of the FriendPickerFragment from Facebook? I'm following the tutorial for showing friends ( https://developers.facebook.com/docs/tutorials/androidsdk/3.0/scrumptious/show-friends/ ), but it takes minutes to scroll down a list of less than 300 friends.
Since no one else has posted this concern, I'm inclined to think I'm doing something wrong. Does anyone have any suggestions on how to get it to perform as well as the "native" friend list in Facebook's Android app?
Your guidance is greatly appreciated!
-Tim
You can try use Universal image loader.
This is for listView optimization and improving performance if your listView contain images from web.
Features:
Multithread image loading Possibility of wide tuning ImageLoader's
configuration (thread executors, downlaoder, decoder, memory and disc
cache, display image options, and others) Possibility of image
caching in memory and/or on device's file sysytem (or SD card)
Possibility to "listen" loading process Possibility to customize
every display image call with separated options Widget support
Related
I have a xamarin forms project for the company I work for. I have 6000+ images used in two ways : a thumbnail page and a full size page. I have both the thumbnail image and the full size image. The thumbnail page shows 12 products at a time, but it lives in a carousel page so it could have up to 18 content pages within the carousel.
I've tried three ways of saving/accessing the images:
Including them as bundle/android resources. This works the best but takes forever to build the project and on android will mean I have to use expansion files.
Included the binary image from the database when downloading the product listing. Causes the app to crash randomly on download.
Downloading all of the files from the web. This works, but on both Android and iOS, the thumbnail screen slows to a crawl and half of the time crashes on Android.
Has anyone had to do something similar and if so, what way did you decide to go? Unfortunately, this app does have to be usable offline so I need the images local. I'm kind of in a time crunch so any help would be appreciated!!
I had similar issues someday back and understood that it won't be successful with standard Image class with such a large amount of images (no memory caching, no task queueing, etc). Then I made CachedImage. It's basically an API compatible replacement for Image with advanced caching capabilities (and some other features). You could try that.
Just remember to use:
Downsampling feature : that way image would be resized to view size to save memory
Caching feature (it's enabled by default not including StreamImageSource for which you have to provide custom cache key factory)
Use FileImageSource (app dir) or StreamImageSource (eg. from image database) with custom cache keys
https://github.com/molinch/FFImageLoading (See WIKI for docs)
The question regarding thumbnail creation seems to get asked a great deal, and each time there seems to be a great many different solutions proposed. From my experience none of the supplied answers are actually sufficient and all seem to have their own flaws.
a) Memory issues when re-sizing
b) Performance issues / slow to render
I therefore wanted to post a question regarding a very common functional requirement that I am hoping someone can assist with.
'User generates a report using activity and takes associated photo using internal camera. The report along with the image path is saved to SQLLite database. User wants to view reports in a scrollable list view at some point in the future. Number of reports could be 1..100'
So given these requirements the questions I have are as follows
1) Given that to data I have not found a reliable / performent / memory optimised way of resizing full size images at run time to a given thumbnail, should I create a smaller image at image capture time?
2) If you need to display many items in a ListView should you use paging or should it be possible to display a 100 items in one ListView?
Thanks
Regarding number 2: What you could do is load a subset first (say the first 30, depending on your listview item size), and load the rest asynchronously and append them to your adapter. This will decrease the loading time of your screen.
1/ Why do you want to reinvent the wheel :) There are libraries that already do for you and do it well. See picasso or AQuery for instance (there are other libraries too).
Basically, they have a thumbnail cache somewhere on the SDcard/internal memory to keep last N requested thumbnails.
I don't know if you are keeping the image data within the database, in which case you may have to adapt one of those libraries to load the image data from the DB and not from a file as it is usually the case.
2/ Why do you want to reinvent the wheel :) There are libraries that already do for you and do it well. See https://github.com/commonsguy/cwac-endless for instance (and google for more)
I'm making an android app, here the images are getting from Cloud, is it good idea to download images and save it & use it further. Or download images every-time user uses the app, what idea you prefer is the best?
Because downloading images always is slow & its bad i know but at some point if the images are updated then how to get to know about it?
You should definitely cache your downloaded files!
Do it in your internal app directory where only you do have access to (or otherwise external storage, thats still ok).
Bandwidth and connections are always expensive and should kept low as much as possible.
So your user can see images fast even on a bad connection and your app doesn't waste his valuable bandwidth of a users data plan.
Maybe this could also help you:
https://github.com/novoda/ImageLoader
http://www.androidhive.info/2012/07/android-loading-image-from-url-http/
Make it easy on yourself and use something like Android Smart Image View. It takes care of loading and caching, and it's just about a drop-in replacement for Android's ImageView. Universal Image Loader is another alternative, more configurable, but not as quick to implement.
I used https://github.com/nostra13/Android-Universal-Image-Loader
but I think you not want only download and cache.
these no trick ,if you want check weather the image update or not, you can add metadata for image, just like md5 .
in html and browser, you can set expires header for a image:
enter link description here
but in android app, you control all yourself.
Downloading images and saving them is probably the best way to do it because you don't want to download the same images over and over. If the images are updated you can delete the older one and download the new ones. Just make sure you don't download/save a million images. Take a look at this library. It has a built-in cache on sdcard/external sd.
Downloading images from the net for display, with possible requirement of caching is a very common problem that many people have solved, you can try these solutions to see which fits you:
Ion (https://github.com/koush/ion) - very flexible and feature complete, plus it can download more than images but JSON, Strings, Files, and Java types as well. The part that I really like about this is that it can automatically cancel operations when the calling Activity finishes, so users don't waste time & bandwidth downloading images that will no longer be displayed
Universal Image Loader (https://github.com/nostra13/Android-Universal-Image-Loader) - equally capable for most use cases but for downloading/caching images only
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.