知道了那么多关于iOS上界面渲染的理论知识后，终于可以回归最开始的问题，将一张 png/jpg 格式的图片渲染到页面上显示有哪些流程？先来区分几个东西。
1.PNG，JPG的区别。
JPG
JPEG是一种针对相片影像而广泛使用的一种失真压缩标准方法。JPEG的压缩方式通常是破坏性资料压缩（lossy compression），意即在压缩过程中图像的品质会遭受到可见的破坏。JPEG不支持动画，不支持半透明。
PNG
便携式网络图片（Portable Network Graphics），简称PNG，是一种无损数据压缩位图图形文件格式。PNG格式是无损数据压缩的，允许使用类似于GIF格式的调色板技术，支持真彩色图像，并具备Alpha（半透明）等特性。
最基本的区别就是jpg图片不支持透明，并且是有损压缩。而png图片支持透明度，无损压缩
2.iOS加载本地图片的方式
imageNamed：
+ (nullable UIImage *)imageNamed:(NSString *)name; // load from main bundle
这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话。如果缓存中没有找到相应的图片，这个方法从指定的文档中加载然后缓存并返回这个对象。
特点：
1.imageNamed加载图片会进行缓存
2.这个方法会在加载图片之后立刻进行解压
imageWithContentsOfFile:
+ (nullable UIImage *)imageWithContentsOfFile:(NSString *)path;
仅加载图片，图像数据不会缓存。因此对于较大的图片以及使用情况较少时，那就可以用该方法，降低内存消耗。
3.图片加载的工作流
进入正题，当我们从磁盘中加载一张图片，并将它显示到频幕上，中间的主要流程如下：
1.假设我们使用 +imageWithContentsOfFile: 方法从磁盘中加载一张图片，这个时候的图片并没有解压缩；
2.然后将生成的 UIImage 赋值给 UIImageView ；
3.接着一个隐式的 CATransaction 捕获到了 UIImageView 图层树的变化；
4.在主线程的下一个 run loop 到来时，Core Animation 提交了这个隐式的 transaction ，这个过程可能会对图片进行 copy 操作，而受图片是否字节对齐等因素的影响，这个 copy 操作可能会涉及以下部分或全部步骤：
·分配内存缓冲区用于管理文件 IO 和解压缩操作；
·将文件数据从磁盘读到内存中；
·将压缩的图片数据解码成未压缩的位图形式，这是一个非常·耗时的 CPU 操作；
·最后 Core Animation 使用未压缩的位图数据渲染 UIImageView 的图层。
在上面的步骤中，图片的解压缩是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的。那么当需要加载的图片比较多时，就会对我们应用的响应性造成严重的影响，尤其是在快速滑动的列表上，这个问题会表现得更加突出。
为什么需要解压缩
什么是位图
位图就是一个像素数组，数组中的每个像素就代表着图片中的一个点。我们在应用中经常用到的 JPEG 和 PNG 图片就是位图。
事实上，不管是 JPEG 还是 PNG 图片，都是一种压缩的位图图形格式。只不过 PNG 图片是无损压缩，并且支持 alpha 通道，而 JPEG 图片则是有损压缩，可以指定 0-100% 的压缩比。
因此，在将磁盘中的图片渲染到屏幕之前，必须先要得到图片的原始像素数据，才能执行后续的绘制操作，这就是为什么需要对图片解压缩的原因。
明白了，我们总不能直接把压缩包拿来用吧。。。
补充：压缩前与压缩后的大小关系
一张 PNG 图片，像素为 30 × 30 ，文件大小为 843B，使用以下代码：
UIImage *image = [UIImage imageNamed:@"check_green"];
CFDataRef rawData = CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage));
就可以获取到这个图片的原始像素数据，大小为 3600B
也就是说，这张文件大小为 843B 的 PNG 图片解压缩后的大小是 3600B ，是原始文件大小的 4.27 倍。那么这个 3600B 是怎么得来的呢？与图片的文件大小或者像素有什么必然的联系吗？事实上，解压缩后的图片大小与原始文件大小之间没有任何关系，而只与图片的像素有关：
解压缩后的图片大小 = 图片的像素宽 30 * 图片的像素高 30 * 每个像素所占的字节数 4
为了加深理解，我把这个图片拖进 Sublime Text 2 中，得到了这个图片的二进制数据，大小与原始文件大小一致，为 843B
强制解压缩的原理
我们前面已经提到了，当未解压缩的图片将要渲染到屏幕时，系统会在主线程对图片进行解压缩，而如果图片已经解压缩了，系统就不会再对图片进行解压缩。因此，也就有了业内的解决方案，在子线程提前对图片进行强制解压缩。
而强制解压缩的原理就是对图片进行重新绘制，得到一张新的解压缩后的位图。其中，用到的最核心的函数是 CGBitmapContextCreate：
这个函数用于创建一个位图上下文，用来绘制一张宽 width 像素，高 height 像素的位图。
好吧，这个函数除了前三个，后面的我基本都不知道。下面挨个儿来说说参数代表什么。
像素格式
我们前面已经提到了，位图其实就是一个像素数组，而像素格式则是用来描述每个像素的组成格式，它包括以下信息：
Bits per component ：一个像素中每个独立的颜色分量使用的 bit 数；
Bits per pixel ：一个像素使用的总 bit 数；
Bytes per row ：位图中的每一行使用的字节数。
颜色空间
在 Quartz 中，一个颜色是由一组值来表示的，比如 0, 0, 1 。而颜色空间则是用来说明如何解析这些值的，离开了颜色空间，它们将变得毫无意义。比如，下面的值都表示蓝色：
位图布局信息 CGBitmapInfo：
它主要提供了三个方面的布局信息：
alpha 的信息；
颜色分量是否为浮点数；
像素格式的字节顺序。
其中，alpha 的信息由枚举值 CGImageAlphaInfo 来表示：
它同样也提供了三个方面的 alpha 信息：
·是否包含 alpha ；
·如果包含 alpha ，那么 alpha 信息所处的位置，在像素的最低有效位，比如 RGBA ，还是最高有效位，比如 ARGB ；
·如果包含 alpha ，那么每个颜色分量是否已经乘以 alpha 的值，这种做法可以加速图片的渲染时间，因为它避免了渲染时的额外乘法运算。比如，对于 RGB 颜色空间，用已经乘以 alpha 的数据来渲染图片，每个像素都可以避免 3 次乘法运算，红色乘以 alpha ，绿色乘以 alpha 和蓝色乘以 alpha 。
根据 Which CGImageAlphaInfo should we use 和官方文档中对 UIGraphicsBeginImageContextWithOptions
函数的讨论：
You use this function to configure the drawing environment for rendering into a bitmap. The format for the bitmap is a ARGB 32-bit integer pixel format using host-byte order. If the opaque parameter is YES, the alpha channel is ignored and the bitmap is treated as fully opaque (kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Host). Otherwise, each pixel uses a premultipled ARGB format (kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host).
我们可以知道，当图片不包含 alpha 的时候使用 kCGImageAlphaNoneSkipFirst ，否则使用 kCGImageAlphaPremultipliedFirst 。另外，这里也提到了字节顺序应该使用 32 位的主机字节顺序 kCGBitmapByteOrder32Host
至于颜色分量是否为浮点数，直接逻辑或 kCGBitmapFloatComponents 就可以了。
然后是字节顺序，它是由枚举值 CGImageByteOrderInfo 来表示的：
它主要提供了两个方面的字节顺序信息：
小端模式还是大端模式；
数据以 16 位还是 32 位为单位。
对于 iPhone 来说，采用的是小端模式，但是为了保证应用的向后兼容性，我们可以使用系统提供的宏，来避免 Hardcoding ：
根据前面的讨论，我们知道字节顺序的值应该使用的是 32 位的主机字节顺序 kCGBitmapByteOrder32Host ，这样的话不管当前设备采用的是小端模式还是大端模式，字节顺序始终与其保持一致。
好了，了解完这些相关知识后，我们再回过头来看看 CGBitmapContextCreate
函数中每个参数所代表的具体含义：
data：如果不为 NULL，那么它应该指向一块大小至少为 bytesPerRow * height字节的内存；如果 为 NULL ，那么系统就会为我们自动分配和释放所需的内存，所以一般指定 NULL、即可；
width和 height：位图的宽度和高度，分别赋值为图片的像素宽度和像素高度即可；
bitsPerComponent：像素的每个颜色分量使用的 bit 数，在 RGB 颜色空间下指定 8 即可；
bytesPerRow：位图的每一行使用的字节数，大小至少为 width * bytes per pixel 字节。有意思的是，当我们指定 0 时，系统不仅会为我们自动计算，而且还会进行 cache line alignment 的优化
space：就是我们前面提到的颜色空间，一般使用 RGB 即可；
bitmapInfo：就是我们前面提到的位图的布局信息。
具体的例子
参照YY大神的YYKit中的使用代码：
CGImageRef YYCGImageCreateDecodedCopy(CGImageRef imageRef, BOOL decodeForDisplay) {
...
if (decodeForDisplay) { // decode with redraw (may lose some precision)
CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(imageRef) & kCGBitmapAlphaInfoMask;
BOOL hasAlpha = NO;
if (alphaInfo == kCGImageAlphaPremultipliedLast ||
alphaInfo == kCGImageAlphaPremultipliedFirst ||
alphaInfo == kCGImageAlphaLast ||
alphaInfo == kCGImageAlphaFirst) {
hasAlpha = YES;
}
// BGRA8888 (premultiplied) or BGRX8888
// same as UIGraphicsBeginImageContext() and -[UIView drawRect:]
CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, YYCGColorSpaceGetDeviceRGB(), bitmapInfo);
if (!context) return NULL;
CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef); // decode
CGImageRef newImage = CGBitmapContextCreateImage(context);
CFRelease(context);
return newImage;
} else {
...
}
}
它接受一个原始的位图参数 imageRef ，最终返回一个新的解压缩后的位图 newImage ，中间主要经过了以下三个步骤：
使用 CGBitmapContextCreate 函数创建一个位图上下文；
使用 CGContextDrawImage 函数将原始位图绘制到上下文中；
使用 CGBitmapContextCreateImage 函数创建一张新的解压缩后的位图。
小结：图片加载到界面，其实就是从磁盘加载到内存解压后再进行渲染。这里我们知道了解压这个过程在主线程并且非常消耗CPU，往往卡顿都是因为它。为了解决这个问题，我们需要在子线程强行解压图片。强行解压的方法其实就是对图片进行重新绘制。
相关文章：
谈谈 iOS 中图片的解压缩
加载和潜伏
