Teaches you to write the basic architecture of Android Imageloader framework

Objective

In Android development, Imageloader should be considered one of the most important open source libraries, due to project reasons (not to use the Open Source Library), the previous period of time you also need to implement a simple imageloader, so the creation of this library, Let's call it a simpleimageloader. At present, when you surf the internet to check Imageloader data, basically can find a very simple implementation, basically a class on all the work to do, it is very unprofessional, many times we do not just need to implement the function, but want to be able to implement the function at the same time at the design level to improve.

The main purpose of simpleimageloader sharing is not to replace those famous open source libraries, but to provide a simple, but also a certain reference value of the Imageloader implementation of some people need to learn, in-depth understanding of the implementation of the knowledge learned, can also realize in the design of an open source library should do what to consider, what trade-offs, what mode, of course, after understanding the implementation of the Imageloader to use the professional open Source Library will be more handy, the problem when they can not be too laborious to investigate its reasons. It is also a point of view that I have always advocated in my blog to improve myself and to understand the basic principles of the design of some open source libraries.

Of course limited to my level, there are unavoidable bugs, but we are here to learn for the purpose, to understand the design and implementation of Imageloader is our most important purpose, some details do not care, you can in the deep learning process to modify what you think unreasonable or wrong place. If you have a good way to achieve or have good advice, please advise one or two; If you think that what I write is not worth mentioning, then you are deeply buried in your heart.

Basic architecturein general, the implementation of Imageloader is based on the thread pool, in the first version of I also use the thread pool to load the picture, but the later version is replaced with the simplenet similar to the schema mode, because the thread pool has just started to be slightly slower, I'm not feeling very well, I changed the threading model. Of course, I will also give the version of the thread pool on another branch, so that some friends need to refer to. the basic structure of Simpleimageloader is shown in 1.

Figure 1

See this picture has seen Simplenet network framework of friends should be familiar with some, the basic structure and simplenet very similar, in fact, we prefer to take the architectural picture into this layered style, feel better understanding,

The Simpleimageloader class is the user's portal, and the user can submit a request for loading the picture to Simpleimageloader after initializing Simpleimageloader through the configuration class. Simpleimageloader internally maintains a request queue, and user-submitted requests to load pictures are internally encapsulated as Bitmaprequest objects, which are then placed in the request queue. When the queue is created, a user-specified number of threads (the default is CPU + 1) is created to load the pictures, which are internally named RequestDispatcher, which in the run function continuously fetches the load request from the queue and then hand it to the corresponding loader to load the picture.

To facilitate the user's extension, we introduced the loader abstraction, because in Simpleimageloader only two image URIs are supported, that is, the URI of the network picture URI and the local file. The network picture usually starts with "HTTP//" or "https://", while the URI format of the local picture is "file://", and the Simpleimageloader interior uses different loader to load the picture in the format of the picture URI. This allows subsequent users to register loader for other forms of loading, such as "drawable://+ picture name" To load images from the res/drawable. This guarantees the scalability of the Simpleimageloader loadable image URI format. Loader will be managed through Loadermanager, and if you need to register your own loader implementation, call Loadermanager's register function. If you pass in the image URI is not valid, for example, the format is wrong, then Loadermanager will return a default loader, the default loader called Nullloader, it actually does nothing, just to prevent the outside to be sentenced to empty, This mode becomes a null object design pattern. Of course, we'll read from the cache before loading the picture, and if we have a cache we won't load it.

Loader after loading the picture will update the UI, the picture is displayed to the corresponding ImageView, in the construction of the bitmaprequest, the image's URI has been set to the ImageView tag. After the picture is loaded, determine if the ImageView tag and URI are equal, and if equal, the picture is displayed on the ImageView, otherwise the ImageView is not updated. This step is very important, many friends in the use of imageloader when the problem is basically because there is no set of ImageView tag.

The order in which the images are loaded is determined by the loading strategy, and the policy-related content is not given in the schema diagram. The load policy determines the ordering of requests in the queue, which sets a sequence number for each request when the request is added to the queue, and the queue sorts the requests based on the sequence number. This allows us to know which request was added first, and it was convenient to implement our own policy class to customize the loading strategy, such as the last request to load into the queue. For example, when we scroll in the ListView, the last picture request added to the queue should be the one we most need to display, we are on the phone's current screen, and the previous request corresponding to the ImageView has been reused, even if they are loaded, they will not be displayed, Because ImageView's tag has changed. Therefore, the flexibility of the strategy remains important.

After loading the pictures and updating the UI, we'll cache the pictures. There are four types of built-in cache, no cache, memory cache, SD card cache, memory and SD card dual cache, these four kinds of caches have implemented the cache interface, if you do not have the four types of cache to meet your needs, then you can implement the cache interface, and then implement their own caching logic, Then set the desired cache type when configuring Imageloader (follow-up instructions for configuration), and if not configured, the default is to use a memory cache. Here we see an example of interface-oriented programming, where Simpleimageloader relies only on the abstraction of the cache interface, rather than on a particular cache class, so that users can implement their own caching logic in a very specific way and inject the cache implementation into the SDK. Of course, the above-mentioned loader, loading strategy implementation is also based on the same theoretical basis, that is, many times the "interface-oriented programming."

Well, it's time to run through this process.

The user calls the DisplayImage request to load the picture, simpleimageloader the load picture request into a requested and then joins the queue. Several of the squint scheduler threads constantly fetch requests from the queue and then get the corresponding loader to load the picture according to the URI format. Before loading the picture, first look at whether the cache contains the target picture (details in the following blog), if there is a cache to use the cache, otherwise load the target picture. after getting to the picture, we will post the picture to ImageView to update, if the ImageView tag is the same as the URI of the picture, then update ImageView, otherwise it will not be processed. Using the ImageView tag to compare the URI of the image is an important step in imageloader in order to prevent the picture from appearing misaligned. If the target picture is not cached, it will be added to the cache the first time it is loaded from the URI, and of course the picture loaded from SDcard will be cached in memory instead of being cached in another directory on the SD card. In this way, the entire loading process is complete.

simpleimageloader Engineering structure diagram

Four of the above effects are not displayed because there are three pictures in the image URI list, which are not in the emulator, so the loading failed. Another one is an invalid URI, and the load fails.

GitHub Warehouse address will be given in the next blog post, please look forward to!!

Teaches you to write the basic architecture of Android Imageloader framework