iOS图片缓存库基准对比

1. 引言

过去的几年里，iOS 应用在视觉方面愈来愈吸引人。图像展现是其中很关键的部分，由于大部分图像展现都须要下载而且渲染。大部分开发者都要使用图像填充表格视图（table views）或者集合视图（collection views）。下载图片消耗一些资源（如蜂窝数据、电池以及 CPU 等）。为了减小资源消耗，一些缓存模型也应运而生。

为了得到良好的用户体验，当咱们缓存和加载图像时，了解 iOS 底层如何处理是很重要的。此外，大多数使用了图片缓存的开源库也是个不错解决方案。

2. 经常使用的解决途径

• 异步下载图像
• 处理图像（拉伸，去红眼，去边框）以便展现
• 写入磁盘
• 须要时从磁盘读取并展现

// 假设咱们有一个 NSURL *imageUrl and UIImageView *imageView, 咱们须要经过NSURL下载图片并在UIImageview上展现
    if ([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, …) {
            [self storeImageData:imageData …];
            UIImage *image = [UIImage imageWithData:imageData];
            dispatch_async(dispatch_get_main_queue(), ^{
                imageView.image = image;
            });
        }];
    }

FPS 简介

• UI 渲染理想状况 FPS=60
• 60FPS => 16.7ms 每帧，这就意味着若是任何主线程操做大于 16.7ms，动态 FPS 将会降低，由于 CPU 忙于处理其余事情，而不是渲染 UI。

3. 经常使用解决途径的缺点

• 从磁盘加载图像或文件时间消耗昂贵（磁盘读取比内存读取慢大概 10-1000 倍，若是是 SSD 硬盘，则可能与内存读取速度更接近（大概慢 10 倍）。参考这里的比较：Introduction to RAM Disks
  若是使用 SSD，将得到接近内存的速度（大概比内存访问速度慢十倍），但目前尚未手机和平板集成 SSD 模块。
• 建立 UIImage 实例将会在内存区生成一个图片的压缩版。可是压缩后的图像过小且没法渲染，若是咱们从磁盘加载图像，图像甚至都没有加载到内存。解压图片一样也很消耗资源。
• 设置 imageView 的 image 属性，这种状况下将会建立一个 CATransaction 并加入主循环中。在下一次循环迭代中，CATransaction 会对任何设置为 layer contents 的图像进行拷贝。

拷贝图像包含如下过程：

• 给文件 io 和解压缩分配缓冲区
• 读取磁盘数据到内存
• 解压图像数据（生成原位图） - 高 CPU 消耗
• CoreAnimation 使用解压数据并渲染

字节位没有正确对齐的图像将被 CoreAnimation 拷贝，以修复字节位对齐并使之能被渲染。这一点在 Apple 文档里没有说明，可是使用 Instruments 代表 CA::Render::copy_image 会执行此操做，即便 Core Aniation 即便没有拷贝图像。

从 iOS7 开始，第三方应用不能使用JPEG硬件解码器。这意味着咱们只能使用慢不少的软解码器。这一点在 FastImageCache 团队的 GitHub 主页以及 Nick Lockwood 的推文上都有指出。

4. 一个强大的 iOS 图像缓存需包含如下部分：

• 异步下载图像，尽量减小使用主线程队列
• 使用后台队列解压图像。这是个复杂的过程，请阅读 Avoiding Image Decompression Sickness
• 在内存和磁盘上缓存图像。在磁盘上缓存图像很重要，由于 App 可能由于内存不足而被强行关闭或者须要清理内存。这种状况下，从新从磁盘加载图像比下载会快不少。
  备注：若是使用 NSCache 做为内存缓存，当有内存警告时，NSCache 会清空缓存内容。NSCache 相关细节请查看 nshipster 文章：NSCache
• 保存解压过的图片到硬盘以及内存中，以免再次解压。
• 使用 GCD 和 blocks，这将使得代码更加高效和简单，现在 GCD 和 blocks 是异步操做时必需的。
• 最好使用 UIImageView 的分类以便集成
• 最好在下载后以及存入到缓存前可以处理图像

iOS图像优化

更多的成像相关以及 SDK 框架（CoreGraphics, ImageIO, CoreAnimation, CoreImage)工做原理，CPU vs GPU 等，请阅读 @rsebbe 的文章：Advanced Imaging on iOS

Core Data 是一个好的选择吗？

这有一篇文章--CoreData 对比 File System，实现图像缓存的基准测试，结果 File System 的表现更好。

看一看上面罗列的观点，本身实现图像缓存不只复杂，耗时并且痛苦。这也是为何我倾向于使用开源的图像缓存解决方案，大家大部分已经据说过 SDWebImage 或 new FastImageCache。

为了让你知道哪一个开源库最适合你，我作了测试而且分析它们如何知足上述要求。

5. 基准测试

测试库：

• SDWebImage - version 3.5.4
• FastImageCache - version 1.2
• AFNetworking - version 2.2.1
• TMCache - version 1.2.0
• Haneke - version 0.0.5

注：AFNetworking 加入对比是因为其自iOS7后在磁盘缓存方面出色的表现（基于 NSURLCache 实现）

测试场景

对于每一个库，我都会使用全新的测试app，而后启动app，等全部图像加载完后，慢慢滑动。而后以不一样力度来回滑动（从慢到快）。接着关掉app强制应用从磁盘缓存中加载图像，最后重复以上测试场景。

关于测试 App 工程

• 相关 demo 能够在 GitHub 找到并获取，名字是 ImageCachingBenchmark，同时还有本次实验的图表、结果数据表以及更多。

• 请注意，请注意 GitHub 上的工程和图像缓存库都须要作一些调整，以便能让咱们看到每一张缓存的图片都可以被加载出来。因为我不想检查 Cocoapods 源码文件（不是个好习惯），因此须要对 Cocoapods clean 后从新编译工程代码，目前 GitHub 上的版本与我作测试的版本有些差异。

• 若是大家想从新跑一下测试，你须要编写相同 completionBlock 用于图像加载，全部库得要跟默认的 SDWebImage 同样返回 SDImageCacheType。

最快与最慢的设备对比结果

在 GitHub 工程上能看到完整的基准测试结果，因为这些表格很大，我只使用运行最快的设备 iPhone 5s 和运行最慢的 iPhone 4 来测试。

汇总：

表格名词解释：

• 异步下载：库支持异步下载
• 后台解压：经过后台队列或线程执行图像解压
• 存储解压：存储解压后的图像版本
• 内存/磁盘缓存：支持内存/磁盘缓存
• UIImageView 分类：库中含 UIImageView 类别
• 从内存/磁盘：从缓存（内存/磁盘）中读取的平均时间

6. 结论

• 从头开始编写 iOS 图像缓存组件很困难

• SDWebImage 和 AFNetworking 是稳定的工程。因为有不少贡献者，这样保证代码可以及时获得维护，FastImageCache 在维护方面更新很快。

• 基于以上全部数据，我认为 SDWebImage 在目前是一个很好的解决方案。即便有些工程使用 AFNetworking 或 FastImageCache 更好，可是这些都依赖于项目需求。

---

原文：iOS image caching. Libraries benchmark (SDWebImage vs FastImageCache)
译者：夜微眠
校对：蓝魂、Cocoa
首发 CocoaChina

---