Based on the android example Program (bitmapfun), efficient loading of pictures makes people speechless

There is an article on how to load images more efficiently in the android Development Guide. The address is. During a minor version upgrade of our project, we tried to use a git open-source project afinal (bitmapfun package version) to load images, however, a problem was found during the test. The new bitmapfun is much slower than the previous ImageDownloader, especially when the network condition is poor, it takes about 10 seconds to wait for a few minutes. The boss finds me and says the image cannot be loaded. It is too slow. I rely on it, isn't it? It's a little too slow to joke about.

Then I started the debugging. At first I was wondering if the network download part was different. Previously I used httpclient, And now bitmapfun used url. openConnection, replace it with the previous httpclient method, and feel better (in fact, it is a strange idea). Try again and find that sometimes it is fast, sometimes slow, compared with the previous, the previous images have been very stable and won't happen this way. Then I tried to find two pages in the project, one loading with the previous ImageDownload and the other loading with bitmapfun, then we can print out and compare the time periods (which can be divided into three segments, 1 is from memory cache, 2 is from network loading, 3 is from memory cache to internal cache and sdcard cache, it is indeed the most time-consuming part of the code downloaded by bitmapfun (processBitmap method). It should be him to see the synchronization lock. At first glance, no problem, lock only a small block. It should prevent the cache from being initialized... Next, I/O operations are frequently performed on sdcard. Well, it should be here. Repeat the method just now. It takes time to print multiple parts. Check the result, tnnd, the longest time used was the wait operation, that is, the lock wait. Then I went to the code and double-click the lock range. I found that the entire download process was basically locked synchronously, this Nima is too boring. When an image is being downloaded, all the others will be waiting. The three core threads created in front will be synchronized to one by you, I said how to see this picture loaded so neatly that it appears one by one.

I found the problem and asked why. What is the reason for this? In fact, it is for the DiskLruCache log file that does not allow multiple threads to operate at the same time; otherwise, the log will be disordered, no way to count which file is not used for the longest time. I tried to change the lock range and found it a little difficult, because the log files were operated too frequently during the download process. I am very grateful to anyone who has a good way to tell me.

For some suggestions on bitmapfun or afinal, the key to the slow DiskLruCache is that the requirements for log files (journal files under Directories) are too high, A log file is used to record the number of accesses to each file. Therefore, it writes log files for each read and write. This allows you to accurately count the files that have not been used for a long time, however, the cost is too high (frequent io operations and synchronization locks). Remember that the previous version of bitmapfun does not use log files, and the access time is calculated directly from the program's access to the sdcard cache, in fact, this is more suitable for better performance. Therefore, if you use this sample program to load images, the best way is to use the DiskLruCache of the previous version or find a way to achieve log file recording, there are better ways to record log files. Please tell me!

Appendix: for the old version of bitmapfun, if you do not want to rewrite the file lock yourself, you can port the File Cache here. Click to download the file