SDWebImage为什么下载图片后先进行解码操作？

iOS 提供了两种加载图片方法，分别是UIIImage的imageNamed: 和 UIIImage的imageWithContentsOfFile:。其中，imageNamed: 方法的特点在于可以缓存已经加载的图片；使用时，先根据文件名在系统缓存中寻找图片，如果找到了就返回；如果没有，从Bundle内找到该文件，在渲染到屏幕时才解码图片，并将解码结果保留到缓存中；当收到内存警告时，缓存会被清空。当频繁加载同一张图片时，使用imageNamed: 效果比较好。而imageWithContentsOfFile：仅加载图片，不缓存图像数据。
虽然imageNamed: 方法利用缓存优化了图片的加载性能，但是第一次加载图片时，只在渲染的时候才在主线程解码，性能并不高效，尤其是在列表中加载多张高分辨率的图片（大图），可能会造成卡顿。这里抛出图片解码的概念，SDWebImageDecoder这个类是为了优化解码效率存在的。

• 图片解码
  图像可以分为矢量图和位图，显示到屏幕中的图像是位图图像，位图图片格式有RGB、CMYK等颜色模式；其中RGB是最常用的颜色模式，它通过红(R)、绿(G)、蓝(B)三个颜色通道的数值表示颜色。手机显示屏使用自带Aphal通道(RGBA)的RGB32格式。
  在项目中，通常使用的图片是JPG或PNG压缩格式，它们是经过编码压缩后的图片格式；而图片显示到屏幕之前，需要将JPG/PNG格式的图片解码成位图图像；这个解码工作是比较耗时的，而且不能使用GPU硬解码，只能通过CPU软解码实现（硬解码是通过解码电路实现，软解码是通过解码算法、CPU的通用计算等方式实现软件层面的解码，效率不如GPU硬解码）。
  iOS默认会在UI主线程对图像进行解码，解码后的图像大小和图片的宽高像素有关，宽高像素越大，位图图像就越大。假设一个3MB的图片，其宽高像素为2048 * 2048的图片，解码后的位图图像大小是16MB（2048 * 2048 * 4）。

//位图大小的计算公式，其中bytesPerPixel = 4B
bitmap_size = imageSize.width * imageSize.height * bytesPerPixel

优化解码耗时的思路是：将耗时的解码工作放在子线程中完成。SDWebImage和FastImageCache就是这么做的。具体的解码工作就是SDWebImageDecoder负责的。