IOS Image Caching. Libraries Benchmark (sdwebimage vs Fastimagecache)

<span id="Label3"></p><p><p>Http://www.cocoachina.com/ios/20150128/11053.html</p></p><p><p></p></p><p><p><strong>1. Introduction</strong></p></p><p><p>iOS apps have become more visually appealing in the past few Years. Image presentation is a key part of this, as most image displays need to be downloaded and Rendered. Most developers use an image to populate a tabular view (table Views) or a collection view (collection views). Downloading pictures consumes some resources (such as cellular data, batteries, and cpus). In order to reduce resource consumption, Some cache models have been Created.</p></p><p><p>To get a good user experience, it is important to understand how the iOS underlying is handled when we cache and load Images. In addition, most open source libraries that use the image cache are a good Solution.</p></p><p><p><strong>2. Common ways to solve</strong></p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>Downloading images asynchronously</p></li> <li><p>Process images (stretch, go red-eye, go to Border) to show</p></li> <li><p>Write to disk</p></li> <li><p>Read and show from disk when needed</p></li> </ul> </ul><pre class="brush:js;toolbar:false">  Suppose we have a  NSURL *imageUrl and UIImageView *imageView,  We need to download the images via Nsurl and show the if  on Uiimageview ([self hasimagedataforurl:imageurl] {     Nsdata *data = [self imagedataforurl:imageurl];    uiimage *image  = [uiimage imagewithdata:imagedata];    dispatch_async (dispatch_get_main_ Queue (), ^{        imageview.image = image;     });}  else {    [self downloadimagefromurl:imageurl withcompletion:^ (NSData  *imagedata,&nbsp, ...)  {        [self storeImageData:imageData ...];         uiimage *image = [uiimage imagewithdata: Imagedata];        dispatch_async (dispatch_get_main_queue (),  ^{& nbsp;           imageview.image = image;         });     }];}</pre><p><p>FPS Introduction</p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>UI rendering Ideal Fps=60</p></li> <li><p>60FPS = 16.7ms per frame This means that if any of the main thread operations are greater than 16.7ms, the dynamic FPS will be degraded because the CPU is busy processing other things rather than rendering the Ui.</p></li> </ul> </ul><p><p><strong>3. Disadvantages of common solution approaches</strong></p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>Loading images or files from disk is expensive (disk reads are about 10-1000 times slower than memory reads, and if the SSD drive may be closer to memory read Speed (about 10 times times slower). Refer to the comparison here: Introduction to RAM Disks. If you use an ssd, you will get close to memory (about 10 times times slower than memory access), but there is no phone or tablet integrated SSD module at this Time.</p></li> <li><p>Creating a UIImage instance will generate a compressed version of the image in the memory Area. But the compressed image is too small to render, and if we load the image from disk, the image is not even loaded into memory. Extracting images also consumes resources.</p></li> <li><p>Sets the image property of the imageview, in which case a catransaction is created and added to the main loop. In the next iteration of the loop, catransaction copies any image that is set to layer Contents.</p></li> </ul> </ul><p><p>The copy image contains the following procedures:</p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>allocating buffers to file IO and decompression</p></li> <li><p>Read disk data to memory</p></li> <li><p>Extract image Data (generate an In-situ Map)-high CPU consumption</p></li> <li><p>Coreanimation using extract data and render</p></li> </ul> </ul><p><p>Images that are not properly aligned in byte bits will be coreanimation copied to fix byte-bit alignment and make it render. This is not stated in the Apple documentation, but using instruments indicates that ca::render::copy_image will do so even if the core aniation does not copy the Image.</p></p><p><p>Starting with iOS7, Third-party apps cannot use the JPEG hardware decoder. This means that we can only use a much slower soft decoder. This is noted on the GitHub homepage of the Fastimagecache team and on Nick Lockwood's Tweets.</p></p><p><p><strong>4. A powerful iOS image cache should contain the following sections:</strong></p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>Asynchronously downloads the image, minimizing the use of the main thread Queue.</p></li> <li><p>Unzip the image using the background Queue. This is a complicated process, please read avoiding Image decompression sickness (http://www.cocoanetics.com/2011/10/ Avoiding-image-decompression-sickness/).</p></li> <li><p>Caches images on memory and on Disk. It is important to cache images on disk because the app may be forcibly shut down or need to clean up memory because of insufficient memory. In this case, reloading the image from disk is much faster than downloading. Note: If you use Nscache as the memory cache, Nscache empties the cached content when there is a memory warning. Nscache for details please see nshipster on this article: nscache</p></li> <li><p>Save the extracted images to the hard drive and memory in order to avoid Re-decompression.</p></li> <li><p>Using GCD and blocks, This will make your code more efficient and Simple. Today GCD and blocks are required for asynchronous operations.</p></li> <li><p>It is best to use the Uiimageview classification for integration</p></li> <li><p>It is best to process the image after downloading and before it is saved to the cache</p></li> </ul> </ul><p><p><strong>iOS image optimization</strong></p></p><p><p>For more imaging related and how the SDK framework (coregraphics,imageio,coreanimation,coreimage) works, CPU vs GPU, etc., Read the @rsebbe article: advanced Imaging on IOS</p></p><p><p><strong>Is Core Data a good choice?</strong></p></p><p><p>Here is an article--coredata the benchmark for image caching in contrast to the file System. As a result, the file system behaves better (as we expected)</p></p><p><p>Take a look at the ideas listed above and make your own image caching complex, time-consuming and Painful. That's why I'm inclined to use an open source image caching Solution. Most of you have heard of sdwebimage or new Fastimagecache.</p></p><p><p>To let you know which open Source Library is best for you, I have tested and analyzed how they meet these requirements.</p></p><p><p><strong>5. Benchmark Test</strong></p></p><p><p>Test library:</p></p> <ul class=" list-paddingleft-2"> <ul class=" list-paddingleft-2"> <li><p>Sdwebimage-version 3.5.4</p></li> <li><p>Fastimagecache-version 1.2</p></li> <li><p>Afnetworking-version 2.2.1</p></li> <li><p>Tmcache-version 1.2.0</p></li> <li><p>Haneke-version 0.0.5</p></li> </ul> </ul><p><p>Note: afnetworking addition is due to its excellent performance in disk caching since IOS7 (based on Nsurlcache Implementation)</p></p><p><p><strong>Test scenario</strong></p></p><p><p>For each library, i'll use the new test app, then launch the app, and then swipe slowly after all the images are Loaded. Then swipe back and forth (from slow to fast) with varying intensity. Then turn off the app to force the app to load the image from the disk cache, and finally repeat the above test scenario.</p></p><p><p><strong>About testing App Engineering</strong></p></p><p><p>-the relevant demo can be found and retrieved on github, with the name Imagecachingbenchmark. There are also charts of this experiment, results data sheets, and More.</p></p><p><p>-please Note that the engineering and image cache libraries on GitHub need to be adjusted so that we can see that each cached image can be Loaded. Since I do not want to check the Cocoapods source file (not A good habit), it is necessary to cocoapods clean after the project code is Recompiled. The current version on GitHub is somewhat different from the version I Tested.</p></p><p><p>-if you want to run the test again, you need to write the same completionblock for the image load, and all the libraries have to return Sdimagecachetype as the default Sdwebimage.</p></p><p><p><strong>Fastest and slowest device comparison results</strong></p></p><p><p>I can see the full benchmark results on the GitHub project, because these tables are large, I only use the fastest device on iphone 5s and the slowest iphone 4来 test to Run.</p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p><strong>Summary:</strong></p></p><p><p></p></p><p><p>Table noun Explanation</p></p><p><p>-asynchronous download = library supports asynchronous download</p></p><p><p>-background decompression = Perform image decompression via background queue or thread</p></p><p><p>-storage decompression = Storage of extracted image versions</p></p><p><p>-memory/disk cache = Supports Memory/disk cache</p></p><p><p>-uiimageview classification = Uiimageview category in library</p></p><p><p>-average time from memory/disk = read from cache (memory/disk)</p></p><p><p><strong>6. Conclusion</strong></p></p><p><p>-writing iOS image cache components from scratch is difficult</p></p><p><p>-sdwebimage and afnetworking are stable projects. Because there are many contributors, this ensures that the code is maintained in a timely manner. The Fastimagecache is updated very quickly in terms of maintenance.</p></p><p><p>-based on all of the above data, I think sdwebimage is a good solution at the Moment. Even some projects use afnetworking or Fastimagecache better. But these all depend on the project Requirements.</p></p><p><p>IOS Image Caching. Libraries Benchmark (sdwebimage vs Fastimagecache)</p></p></span>