7

I have a block of images that I want to load on my screen. All the images are files that I downloaded and stored on SD-CARD.

So far I found two ways to do it, first is loading them on the main thread, when the activity is starting, (I got about 70 images and it takes me about 2.1 seconds to load them all).

Another way is what I am testing right now. Load them on separated thread, so meanwhile I can show loading animation for the user. For now my implemintation with ThreadPoolExecutor took 4.3 sec. I did it on 10 threads.

And the last method, (it's the only thing that I didn't test yet) is working with sprite sheet.

I can't use application cache because in my application I have lots of screens and each screen has its own images set.

What do you think, what is the fastest way to load large amount of images and what acceleration technics do you know that can help me up?

MrZander
  • 3,031
  • 1
  • 26
  • 50
Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216
  • You haven't mentioned the size of your images and if you can reduce their size when you load them (e.g. take a 5 megapixel JPEG and load it as a 320x240 thumbnail). If you allow this, it can greatly accelerate the loading of images. – BitBank Feb 25 '12 at 00:05

4 Answers4

9

  1. Don't load on main thread. With 2.1 sec delay you're close to being killed with ANR (app not responding) error if you block main thread.

  2. Load in separate thread. Don't create 10 threads, but one AsyncTask, and load all your images one after another in doInBackground.

    Loading in AsyncTask should take (nearly) same time as loading in main thread. Don't put too much fancy animations, so that main thread doesn't consume too much CPU time.

Community
  • 1
  • 1
Pointer Null
  • 39,597
  • 13
  • 90
  • 111
2

One option would be to use create image cache using the WeakReference so that the image would be removed from the memory when system encounter low memory situation. This way you can keep images in memory and only need load from sdcard when they are not in memory. So your current activity would always keep the hard reference to the bitmap's required and the image cache would keep the weak reference to the bitmap's.

Following is some more information about weak reference:

JavaDoc weakReference

StackOverflow post discussing using weak reference for cache

Community
  • 1
  • 1
Praful Bhatnagar
  • 7,425
  • 2
  • 36
  • 44
  • 1
    -1: this approach is parctically useless on all devices sdk 9 and up since the garbage collector is so aggressive it nearly imediatly clears all weak refrences, current recommend approach is LRU Cache (see http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html) – Patrick Apr 08 '14 at 10:51
0

One way to do this will be to implement a kind of listener/observer.

From your UI thread, launch other thread that will load the image. Once the image is loaded, thread will invoke a call back method implemented in the activity class to update the corresponding image view.

Instead of android asynch task, I will go for my threads (pooled/Executors). I will get all the possible image paths before loading them, and dispatching them to thread loading the image.And in the call back I know where to updated the image.

Alternatively you can also check how the Loader perform in your case.

user1050134
  • 572
  • 1
  • 7
  • 20
0

Clearly, you should not leave a 2s-long operation in the UI thread.

I suppose the ThreadPoolExecutor is a godd solution, but it is not optimal to create many threads in your pool. On background thread is sufficient. I bet you'll have better performance simply by changing this.

I don't recommend an AsyncTask directly from the Activity, because it is fragile to config change.

I don't recommend working with sprites. Increasing the size of one image is very dangerous on a mobile where memory is limited. In particular with sprites, you'll have to get parts of the Bitmap, hence having the full bitmap in memory for a moment.

Now that I unanwsered your specific questions, I think you go throuh Lazy loading of images in a listview because the problem is very similar.

Community
  • 1
  • 1
rds
  • 26,253
  • 19
  • 107
  • 134