原文:iOS image caching. Libraries benchmark (SDWebImage vs FastImageCache),译者夜微眠(github地址),校对蓝魂(博客)、Cocoa(博客)。 过去的几年里,iOS应用在视觉方面越来越吸引人。图像展示是其中很关键的部分,因为大部分图像展示都需要下载并且渲染。大部分开发者都要使用图像填充表格视图(table views) 或者 集合视图(collection views) 。下载图片消耗一些资源(如蜂窝数据、电池以及CPU 等)。为了减少资源消耗,一些缓存模型也应运而生。 为了获得良好的用户体验,当我们缓存和加载图像时,了解iOS底层如何处理是很重要的。此外,大多数使用了图片缓存的开源库也是个不错解决方案。 2.常用的解决途径
FPS 简介
3.常用解决途径的缺点
拷贝图像包含以下过程:
字节位没有正确对齐的图像将被CoreAnimation拷贝,以修复字节位对齐并使之能被渲染。这一点在Apple 文档里没有说明,但是使用Instruments表明 CA::Render::copy_image会执行此操作,即使Core Aniation 即使没有拷贝图像。 从iOS7 开始,第三方应用不能使用JPEG硬件解码器。这意味着我们只能使用慢很多的软解码器。这一点在FastImageCache团队的 GitHub主页以及 Nick Lockwood的推文上都有指出。 4.一个强大的iOS图像缓存需包含以下部分:
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.基准测试 测试库:
注: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更好。但是这些都依赖于项目需求。 |
|