Android List picture optimization experience

First, after the optimization of the FPS diagram, silky smooth, specific implementation please see the final optimized app

Background: A Contacts app (open source address), each time you log on, for each user, if the avatar picture is not local, then generate an asynchronous download task (Asynctask).

Tips: Judging whether the picture is local, we use the method:

Depending on the URL of the picture, such as Http://images0.cnblogs.com/blog2015/339868/201507/230955108345303.png

After intercepting COM's string, the local address is: app's package name/files/blog2015/339868/201507/230955108345303.png

It is then judged based on the exists () method of the File object.

In actual use, the address book probably 400来 people, more than 400 aysnctask, and then a lot of concurrent file.exists () IO requests, resulting in the download of the few seconds of the very card, FPS low and put the same slide.

I really can't accept it.

Optimization Scenario Version 1.0:

1: No asynctask, introduce a fixed thread pool, control the maximum number of threads concurrently 5.

2: Do not file.exists () to determine whether the picture exists, in SQLite create a Picture index table, select this network address exists; Once the picture is written locally, the network address and local address are inserted into the Picture Index table.

Result: The effect is immediate, and FPS climbs up.

New Requirement 1:

Users are sure to need him to see the Avatar first show, just wait for you backstage all the pictures downloaded!

Optimization Scenario version 1.1:

For a network request for the same image resource, we divide the intent of this request into 1: Download Local 2: Load the display

The load show has the highest priority, at the top of the stack, after each push in, to determine whether the URL already exists in the request list (whether it is downloaded or loaded)

If it already exists, delete the request with the old resource and push it in to make sure the new task is at the top of the stack.

Tips: Loading is likely to be repeated oh, for example, the network is slow, the user to slide the list will repeatedly trigger the Load event, so before joining to delete the URL old request

New Requirement 2:

Everyone knows that the alphabetical list on the right side of the Address book is a quick way to navigate to a phonetic match, and if you swipe back and forth fast for the first time, you'll still feel a little stuck.

Although after each load of the image, the passive will put the bitmap into the cache, but for the first time in the alphabetical list of sliding, still will be card.

Optimization Scenario Version 1.2:

The lag is because the IO request is too frequent, we know that the memory cache is much faster than the disk cache, so it is best to proactively put the Avatar bitmap in the memory cache when using it.

Memory cache type lrucache<string,bitmap>; LruCache; we just need to know that this type is a fixed-size memory, using the LRU algorithm, when the capacity is full, will be the less common elements to delete.

The string parameter represents the HTTP address, and bitmap represents the image data corresponding to the address.

Remember the image index table provided in Optimization scenario 1.0?

We add a instruction thread at the bottom of the request stack, which traverses the picture Index table as it executes to that thread.

For each HTTP address, if it is not in the memory cache, add a thread that loads the local image to memory on the request stack.

This is the final version of the idea, specific details please refer to the source code implementation

Android List picture optimization experience