iOS应用网络图片架构的思考

最近考虑对项目的网络图片库进行重构，写点东西记录一下思路。

首先现有的架构有什么问题呢？

现有的网络图片架构只是对网络库做了简单的封装

1. 实现了代理模式的接口
   <pre><code>- (void)downloadImageByUrl:(NSString)url savePath:(NSString)savePath delegate:(id)delegate action:(SEL)action withObject:(id)obj;</code></pre>
2. 基于NSFileManager的文件缓存，但封装度不够，十分难用
3. 用NSThread实现了一个从zip包中解压出图片，异步加载

显然，无论从性能或者接口友好度上看，都很low......

• 下载操作在主线程，
• 代理模式，每次都要写SEL

那么优秀的图片加载库应该是什么样的？

• SDWebImage
• AFNetworking
• YYWebImage

1.友好的接口

应该减少对业务代码的侵入，毫无疑问，Category是最好的方式。这三个框架都是这种方式，SDWebImage为例：
<pre><code>- (void)sd_setImageWithURL:(NSURL *)url placeholderImage:(UIImage *)placeholder;</code></pre>

2.多线程异步下载、全局队列执行下载

多线程异步下载提高性能，全局队列保证不重复加载同一张图片
SDWebImage、AFNetworking的最新版本使用NSURLSession
YYWebImage使用NSURLConnection
我不知道这两套API有多少差别，苹果在iOS9已经宣布弃用NSURLConnection

3.后台图片解码，支持主流格式

UIImage被创建时候，并没有进行解码。当 UIImage 第一次显示到屏幕上时，其内部的解码方法才会被调用，同时解码结果会保存到一个全局缓存去。

所以支持后台解码是能够提高性能的。
这三个框架都支持后台线程解码，至于主流图片格式，不具体分析了。

4.缓存

缓存方式	内存缓存	硬盘缓存
SDWebImage	SDImageCache (基于NSCache）	NSFileManager
AFNetworking(2.x)	NSCache	貌似没有diskCache？
AFNetworking(3.x)	AFAutoPurgingImageCache	NSURLCache
YYWebImage	YYCahce（基于NSCache）	YYCahce（NSFileManager+DB）

• SDWebImage也是支持NSURLCache的，但同时使用会造成重复缓存。
• NSURLCache本身也有内存缓存，有些博客认为NSURLCache缓存的是Http协议中返回的response，response到UIImage这一过程，会带来额外的开销，但我实际使用过程中发现，NSURLCache的硬盘缓存也分成fileSystem和DB，沙盒目录下有个fsCachedData文件夹保存了图片（？欢迎指正）。
• YYCahce 根据作者大神做的测评，性能很屌，甩别人几条街那种~ ibireme大神博客
• 至于disk的缓存时间，NSFileManager应该比较容易实现针对单个缓存的设置缓存时间，但SDWebImage目前是统一的缓存时间；YYCache目前也只有统一的缓存过期时间；NSURLCache缓存时间是由服务器决定的(待验证)。

5. 其他很fashion的特性

• 渐进式加载
• 本地文件加载
• 常见图片处理，裁剪、圆角等等
  这个方面 YYWebImage 做的最好

总结

任意框架来替代项目的现有方案，都可以满足需求，并且会有很大的性能提升（希望是）。我比较中意YYWebImage，美中不足的就是NSURLConnection，毕竟NSURLSession才是美好未来。