A general picture caching scheme in mobile application development (ios/android, etc.) explained (with flowchart)

In mobile app development, we often encounter scenes from Web request images to devices.

If the request is repeated each time, wasting traffic, wasting power, the user experience is also poor;

It is also a strategy to persist pictures to disk, but there is also a certain IO cost to read pictures from a file, and even with this strategy, we need to control the capacity of the disk cache to avoid consuming too much system resources.

In fact, no solution can be said to be the perfect solution, only the most suitable for their business needs of the program, it can be said to be a good solution .

The solutions we have explained below are very versatile, simple and clear:

1. Assume that the URL of each network picture is unique, if the picture on the network changes, it will cause the input source URL changes;

2. Based on 1, we use the URL as a unique identifier of the image cache (can do hash, do MD5, can also use urlstring as key, all can be)

3. Access priority: Memory Cache > Disk Cache > Network resources

The above 3 points is the basic strategy of our program, the following is the technical details :

1. For the management of the cache, we can set the threshold (including the cache time and cache capacity), to achieve conditional triggering cleanup, can also be combined with LRU (Least Recently used least recently used algorithm ) algorithm to improve the cache access efficiency, This requires that the cache be tagged when the cache is written, and that the algorithm is not expanded here and is interested in Google itself.

2. For the load of network resources we have to adopt an asynchronous scheme that does not block the display of the UI; You can add requests to the queue to support concurrent requests, and be aware that we can set the maximum number of concurrent requests based on the number of URLs that an address can support for simultaneous connections to improve efficiency.

3. When accessing the disk cache/network resource succeeds, the high priority cache needs to be populated, the memory cache is populated when the disk cache access succeeds, and the memory cache + disk cache is populated when network resource access is successful.

For specific use cases we can decide whether or not to adopt or partially adopt this scenario according to business needs, or to adapt some of the policies in this scenario to meet the business requirements based on the needs of the project, such as when the disk cache is not accessed, when the cache is emptied, when the cache is forced to refresh, and so on.