iOS 图片解码（decode）笔记

为什么图像在显示到屏幕上之前要进行解码

一般我们使用的图像是JPEG/PNG，这些图像数据不是位图，而是是经过编码压缩后的数据，需要线将它解码转成位图数据，然后才能把位图渲染到屏幕上。

当你用 UIImage 或 CGImageSource 的那几个方法创建图片时，图片数据并不会立刻解码。图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码。这一步是发生在主线程的，并且不可避免。

图片加载的工作流

概括来说，从磁盘中加载一张图片，并将它显示到屏幕上，中间的主要工作流如下：

假设我们使用 +imageWithContentsOfFile: 方法从磁盘中加载一张图片，这个时候的图片并没有解压缩；

然后将生成的 UIImage 赋值给 UIImageView ；

接着一个隐式的 CATransaction 捕获到了 UIImageView 图层树的变化；

在主线程的下一个 run loop 到来时，Core Animation 提交了这个隐式的 transaction ，这个过程可能会对图片进行 copy 操作，而受图片是否字节对齐等因素的影响，这个 copy 操作可能会涉及以下部分或全部步骤：

分配内存缓冲区用于管理文件 IO 和解压缩操作；

将文件数据从磁盘读到内存中；

将压缩的图片数据解码成未压缩的位图形式，这是一个非常耗时的 CPU 操作；

最后 Core Animation 使用未压缩的位图数据渲染 UIImageView 的图层。

在上面的步骤中，我们提到了图片的解压缩是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的。那么当需要加载的图片比较多时，就会对我们应用的响应性造成严重的影响，尤其是在快速滑动的列表上，这个问题会表现得更加突出。

图像的解码

解码操作是比较耗时的，并且没有GPU硬解码，只能通过CPU，iOS默认会在主线程对图像进行解码。解码过程是一个相当复杂的任务，需要消耗非常长的时间。60FPS ≈ 0.01666s per frame = 16.7ms per frame，这意味着在主线程超过16.7ms的任务都会引起掉帧。很多库都解决了图像解码的问题，不过由于解码后的图像太大，一般不会缓存到磁盘，SDWebImage的做法是把解码操作从主线程移到子线程，让耗时的解码操作不占用主线程的时间。

对于PNG图片来说，因为文件可能更大，所以加载会比JPEG更长，但是解码会相对较快，而且Xcode会把PNG图片进行解码优化之后引入工程。JPEG图片更小，加载更快，但是解压的步骤要消耗更长的时间，因为JPEG解压算法比基于zip的PNG算法更加复杂。

当加载图片的时候，iOS通常会延迟解压图片的时间，直到加载到内存之后。因为需要在绘制之前进行解压，这就会在准备绘制图片的时候影响性能。

iOS通常会延时解压图片，等到图片在屏幕上显示的时候解压图片。解压图片是非常耗时的操作。