导语：这是SDWebImage源码理解的第一篇，本篇先介绍图片解码相关的背景知识，然后介绍SDWebImage中解码的源码及其解码相关的问题。
一、背景知识
在SDWebImage中处理图片解码的是SDWebImageDecoder。
1、图片加载
iOS 提供了两种加载图片方法，分别是UIIImage的imageNamed: 和 UIIImage的imageWithContentsOfFile:。
其中，imageNamed: 方法的特点在于可以缓存已经加载的图片；使用时，先根据文件名在系统缓存中寻找图片，如果找到了就返回；如果没有，从Bundle内找到该文件，在渲染到屏幕时才解码图片，并将解码结果保留到缓存中；当收到内存警告时，缓存会被清空。当频繁加载同一张图片时，使用imageNamed: 效果比较好。而imageWithContentsOfFile：仅加载图片，不缓存图像数据。
-
虽然imageNamed: 方法利用缓存优化了图片的加载性能，但是第一次加载图片时，只在渲染的时候才在主线程解码，性能并不高效，尤其是在列表中加载多张高分辨率的图片（大图），可能会造成卡顿；
说明：这里抛出图片解码的概念，SDWebImageDecoder这个类是为了优化解码效率存在的。
2、图片解码
图像可以分为矢量图和位图，显示到屏幕中的图像是位图图像，位图图片格式有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负责的。
3、图片重采样
在图片显示到屏幕前，除了要在主线程中解码，还会在主线程中完成重采样的工作。重采样算法一般有： Nearest Neighbour Resampling （最邻近重采样）、 Bilinear Resampling（双线性/两次线性重采样）、Bicubic Resampling （双立方/两次立方重采样）等。
Nearest Neighbour Resampling比较简单暴力，根据目标图像的宽高 与源图像的宽高比值，取源图像相对位置的像素点的值作为目标像素点的值；而Bilinear Resampling参考源像素位置周围4个点的值，按一定权重获得目标图像像素点的值；而Bicubic Resampling参考源像素点周围4*4个点的值，按一定权重获得目标图像像素点的值。
图像的放大和缩小都会引起重采样，放大图像称为上采样/插值（upsamping），缩小图像称为小采样（downsampling）。当图片的size和imageView的size不同时，发生重采样。
4、总结
总结1：SDWebImage 利用空间换时间的做法，在子线程中解码图片并缓存位图结果，避免图片的重复解码，提升图片展示性能。如果列表中需要展示很多网络图片，SDWebImage这种做法，有利于提高列表的流畅度。
总结2：SDWebImage中下载的图片，即使解码缩放(decodedAndScaledDownImageWithImage:)后，图片大小 未必 和imageView的大小相同，这会引发重采样，我们可以在图片显示前，将图片裁剪成和imageView的大小相同，提升性能（一个小的优化点）。
二、源码说明
SDWebImageDecoder的源码有200多行，重要的函数两个。其一是：（默认）解码图片办法decodedImageWithImage: ；其二是：处理大图缩放和解码办法decodedAndScaledDownImageWithImage：。
1、decodedImageWithImage:函数
decodedImageWithImage实现了PNG、GIF、TIFF三类图片解码的问题，这是SDWebImage默认的解码操作；当它解码高分辨率图片，会导致内存暴增，甚至Crash。它造成的问题就是网上很多博客说的，“SDWebImage加载大图（高分辨率图），内存暴涨，导致加载失败的问题”。
-
decodedImageWithImage函数很简单，主要步骤可以看成：先过滤掉不符合解码条件；再获得图片的信息；最后绘制出位图图片。
1）shouldDecodeImage:过滤点不适合解码的image，分别是：image为nil、animated images 或 有透明度的图片 2）获取图片的像素宽高(width、height)、颜色空间(colorspaceRef) 、行字节数（bytesPerRow，4 * width）等数据。 3）使用创建CGBitmapContextCreate没有透明度的位图上下文，然后在该上下文中绘制出图像。
说明：解码操作在@autoreleasepool中，可以使得局部变量能尽早释放掉，避免内存峰值过高。
2、decodedAndScaledDownImageWithImage:函数处理流程
decodedAndScaledDownImageWithImage解决了PNG、GIF、TIFF三类高分辨率图片因解码导致内存暴增的问题，采用办法是：将大的原图缩放成指定大小的图片（个人感觉，思路应该来自苹果的LargeImageDownsizing）。
decodedAndScaledDownImageWithImage: 函数中主要步骤可以看成：先过滤掉不符合解码条件，位图大小不达标的（小于60MB）；再将原图按照固定大小分割，然后依次绘制到目标画布上（这部分最关键）。
-
在裁剪绘制过程中，主要步骤如下：
1）根据sourceTotalPixels（原图像素大小）和kDestTotalPixels（60MB对应的像素大小）获取imageScale； 2）根据imageScale和原图的像素宽高获取 目标图的大小destResolution.size, 并创建目标位图上下文； 3）获得原图分割图的size(sourceTile.size)，宽度和原图宽一样，高度是 (int)(kTileTotalPixels / sourceTile.size.width )，其中 kTileTotalPixels为20MB 4）获取目标分割图的size(destTile.size)，宽度和目标图宽一样，高度是sourceTile.size.height * imageScale 5）根据原图高（sourceResolution.height）除以原图分割图的高（sourceTile.size.height）获得获取分割块的个数iterations，如果还有余数，分割块个数（iterations）载累加1。 6）从原图中裁剪出指定大小的分割图，然后绘制到目标上下文的指定位置。注意：Core Graphics的坐标系则是y轴向上的，UIKit框架坐标系是y轴向下的；使用CGContextDrawImage将sourceTileImageRef绘制到destContext中，为了避免图片上下文颠倒，注意destTile.origin.y和sourceTile.origin.y的计算方式。
for( int y = 0; y < iterations; ++y ) { @autoreleasepool { //注意sourceTile.origin.y和destTile.origin.y的计算 sourceTile.origin.y = y * sourceTileHeightMinusOverlap + sourceSeemOverlap; destTile.origin.y = destResolution.height - (( y + 1 ) * sourceTileHeightMinusOverlap * imageScale + kDestSeemOverlap); sourceTileImageRef = CGImageCreateWithImageInRect( sourceImageRef, sourceTile ); if( y == iterations - 1 && remainder ) { float dify = destTile.size.height; destTile.size.height = CGImageGetHeight( sourceTileImageRef ) * imageScale; dify -= destTile.size.height; destTile.origin.y += dify; } CGContextDrawImage( destContext, destTile, sourceTileImageRef ); CGImageRelease( sourceTileImageRef ); } }
3、CGBitmapContextCreate创建位图上下文
函数原型：CGBitmapContextCreate(void *data,size_t width,size_t height,size_t bitsPerComponent,size_t bytesPerRow,CGColorSpaceRef colorspace,CGBitmapInfo bitmapInfo)
- 参数data：渲染目标的内存地址，内存块大小至少是(bytesPerRow * height) 个字节；一般传递NULL，让系统去分配和释放内存空间，避免内存泄漏问题。
- 参数width和height分别是：位图的宽高像素；
- 参数bitsPerComponent是：位图像素中每个组件的位数（number of bits）。对于32位像素格式和RGB 颜色空间，这个值是8；
- 参数bytesPerRow：在内存中，位图每一行所占的字节数。
- 参数 colorspace：位图的颜色空间。
- 参数 bitmapInfo：指出该位图是否包含 alpha 通道和它是如何产生的(RGB/RGBA/RGBX…)，还有每个通道应该用整数标识还是浮点数。值为kCGBitmapByteOrderDefault | kCGImageAlphaNoneSkipLast，表示着新的位图图像不使用后面8位的 alpha 通道的。
说明：一个新的位图上下文的像素格式由三个参数决定：每个组件的位数（bitsPerComponent），颜色空间（colorspace），alpha选项（bitmapInfo），alpha值决定了绘制像素的透明性。
三、解码高分辨率图的担忧
1、“被嫌弃”的解码
-
网络上，很多博客都说到了使用SDWebImage加载（高分辨率）图片，发生内存暴涨，甚至导致Crash的问题；提出的解决的办法是，关闭解码操作。
// 关闭解码操作 [[SDImageCache sharedImageCache] setShouldDecompressImages:NO]; [[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO]; 关闭解码操作，将decodedImageWithImage解码高分辨率图的内存问题避开了，但是这意味着：如果大图多次加载显示，意味着在主线程要多次重复解码（这好像不是什么好事）；此外显示大图时，App依然会占用大量的内存，还可能造成卡顿；放弃SDWebImage解码并不能保证能应对所有高分辨图。所以说，关闭解码操作并不是一个很好的选择。
2、加载高分辨率图问题
项目中，加载高分辨率图不可避免，如后台下发给我们一张大图（高分辨率图）；主线程解码（默认）可能导致卡顿；子线程解码可能因内存暴涨而Crash。解决办法可以参考 LargeImageDownsizing。该Demo展示加载显示一个高分辨率（7033 × 10110 像素，位图大小271MB）图片的做法；其主要优化思路是：将大的原图缩放成指定大小的图片。decodedAndScaledDownImageWithImage就是采用这种思路。
-
在decodedAndScaledDownImageWithImage:函数中，为了避免内存暴增，将原图裁剪成多个小图，然后依次绘制到目标位图context中。项目中，我更愿意decodedAndScaledDownImageWithImage方法去解码高清晰图片，而不愿意禁止解码操作。
//SDWebImageOptions选择SDWebImageScaleDownLargeImages，处理网络高分辨率图 [self.imageView sd_setImageWithURL:url placeholderImage:nil options:SDWebImageScaleDownLargeImages]; Apple提供了一个异步绘制内容的图层CATiledLayer，不需要加载全部图片，可以将大图分解成小图片，然后再载入显示，具体参考下CATiledLayer
3、需要考虑的问题
凭心而论，后台不经处理，任意下发高分辨率大图这类事发生可能性很少；绝大部分场景下，iOS设备上不需要分辨率过高的图（iPhone X的屏幕尺寸也不过是1125px × 2436px），那我们应该考虑什么呢。
考虑1：因为SDWebImage支持并发的解码操作，同时解码多张分辨率中等图片，占用的内存空间比较大，可能会给内存带来压力（小图不必担心）。可行的处理办法是，限制并发解码的个数。
考虑2：如果后台下发的图片是带透明度的图片，SDWebImage并不会去做解码，这样的图片只能让iOS系统去解码。我能想到的办法：尽可能让后台下发不透明的图片。
四、解码中的小问题
SDWebImageDecoder的解码工作中，有两个小问题值得留意一下。
1、颜色空间的问题
-
在创建位图，选用颜色空间时，如果图片的颜色空间模式是kCGColorSpaceModelUnknown（未知）、kCGColorSpaceModelMonochrome、kCGColorSpaceModelCMYK和kCGColorSpaceModelIndexed，默认使用设备RGB颜色空间(通过CGColorSpaceCreateDeviceRGB获得)，详见代码：
+ (CGColorSpaceRef)colorSpaceForImageRef:(CGImageRef)imageRef { // current CGColorSpaceModel imageColorSpaceModel = CGColorSpaceGetModel(CGImageGetColorSpace(imageRef)); CGColorSpaceRef colorspaceRef = CGImageGetColorSpace(imageRef); BOOL unsupportedColorSpace = (imageColorSpaceModel == kCGColorSpaceModelUnknown || imageColorSpaceModel == kCGColorSpaceModelMonochrome || imageColorSpaceModel == kCGColorSpaceModelCMYK || imageColorSpaceModel == kCGColorSpaceModelIndexed); if (unsupportedColorSpace) { colorspaceRef = CGColorSpaceCreateDeviceRGB(); CFAutorelease(colorspaceRef); } return colorspaceRef; }
这么做的原因，我认为只要有两点：
RGB颜色模式几乎包括了人类视力所能感知的所有颜色，而SDWebImageDecoder中主要支持PNG、JPG、TIFF常见图片格式的解码，它们大部分采用RGB色彩模式；目前手机屏、电脑显示屏大都采用了RGB颜色模式。
对应Monochrome、CMYK和Indexed这样的模式，使用设备RGB颜色空间(device color space)，其结果是可以接受的。一张灰度图片，颜色空间模式是kCGColorSpaceModelMonochrome，使用设备灰度颜色空间和设备RGB颜色空间都可以，只是使用设备灰度颜色空间内存上效果会好一些。
2、解码不透明图片的问题
- SDWebImage中不解码透明的图片，猜测原因是：在UI渲染视图时，如果某个layer透明时，需要叠加计算下方多层的像素；如果某个layer不透明，可以忽略掉下方的图层，减少了GPU像素混合计算。使用CGBitmapContextCreate 时 bitmapInfo 参数设置为忽略掉 alpha 通道，绘制出不透明的位图图片，在渲染视图，能减少GPU的计算，提高性能。
End
