iOS图片的渲染过程与性能优化

图片的存储方式

图片和其他所有资源一样，在内存中本质上都是0和1的二进制数据，用户无法接触到这些二进制数据，他们看到的都是经过某种二进制编码之后的图片。这种将图片以某种规则进行二进制编码的方式，就是图片的格式。
常见的格式有：
JPEG
只支持有损压缩，其压缩算法可以精确控制压缩比，以图像质量换得存储空间。
PNG
只支持无损压缩，最大的优势在于支持完整的透明通道。
GIF
支持多帧动画。
WebP
支持有损和无损压缩、支持完整的透明通道、无损压缩后的 webp 比 png 少了45%的体积，相同质量的 webp 和 jpg，前者也能节省一半的流量。同时 webp 还支持动图，可谓图片压缩格式的集大成者。缺点：WebP格式图像的编码时间很长，是JPEG的8倍；浏览器和移动端支持还不是很完善。

这里简单介绍下有损压缩和无损压缩：
有损压缩：相较于颜色，人眼对光线亮度信息更为敏感，基于此，通过合并图片中的颜色信息，保留亮度信息，可以在尽量不影响图片观感的前提下减少存储体积。顾名思义，这样压缩后的图片将会永久损失一些细节。最典型的有损压缩格式是 jpg。

无损压缩：和有损压缩不同，无损压缩不会损失图片细节。它降低图片体积的方式是通过索引，对图片中不同的颜色特征建立索引表，减少了重复的颜色数据，从而达到压缩的效果。常见的无损压缩格式是 png，gif。

如何判断图片的格式：
由原始的二进制数据，根据不同压缩方式的编码特征，就可以拿到,以SDWebImage为例

+ (SDImageFormat)sd_imageFormatForImageData:(nullable NSData *)data {
    if (!data) {
        return SDImageFormatUndefined;
    }
    
    // File signatures table: http://www.garykessler.net/library/file_sigs.html
    uint8_t c;
    [data getBytes:&c length:1];
    switch (c) {
        case 0xFF:
            return SDImageFormatJPEG;
        case 0x89:
            return SDImageFormatPNG;
        case 0x47:
            return SDImageFormatGIF;
        case 0x49:
        case 0x4D:
            return SDImageFormatTIFF;
        case 0x52: {
            if (data.length >= 12) {
                //RIFF....WEBP
                NSString *testString = [[NSString alloc] initWithData:[data subdataWithRange:NSMakeRange(0, 12)] encoding:NSASCIIStringEncoding];
                if ([testString hasPrefix:@"RIFF"] && [testString hasSuffix:@"WEBP"]) {
                    return SDImageFormatWebP;
                }
            }
            break;
        }
        case 0x00: {
            if (data.length >= 12) {
                //....ftypheic ....ftypheix ....ftyphevc ....ftyphevx
                NSString *testString = [[NSString alloc] initWithData:[data subdataWithRange:NSMakeRange(4, 8)] encoding:NSASCIIStringEncoding];
                if ([testString isEqualToString:@"ftypheic"]
                    || [testString isEqualToString:@"ftypheix"]
                    || [testString isEqualToString:@"ftyphevc"]
                    || [testString isEqualToString:@"ftyphevx"]) {
                    return SDImageFormatHEIC;
                }
                if ([testString isEqualToString:@"ftypmif1"] || [testString isEqualToString:@"ftypmsf1"]) {
                    return SDImageFormatHEIF;
                }
            }
            break;
        }
    }
    return SDImageFormatUndefined;
}

iOS中的图片加载过程

图片显示到屏幕主要是依靠CPU和GPU协同合作完成的。分工具体如下：

CPU: 计算视图frame，图片解码，需要绘制纹理图片通过数据总线交给GPU
GPU: 纹理混合，顶点变换与计算,像素点的填充计算，渲染到帧缓冲区。
时钟信号：垂直同步信号V-Sync / 水平同步信号H-Sync。
iOS设备双缓冲机制：显示系统通常会引入两个帧缓冲区，双缓冲机制。

开发中拿到的图片大部分都是jpg，png，gif等经过格式化的文件，这些图片都是被压缩过的，在渲染到屏幕之前，都需要先解码成bitmap(未压缩的位图)
以UIImageView显示一张图片为例，会经过以下步骤：
1.使用 +imageWithContentsOfFile:方法从磁盘中加载一张图片，这个时候的图片并没有解压缩。
2.将生成的image赋值给UIImageView。
3.接着一个隐式的 CATransaction 捕获到了 UIImageView 图层树的变化。
4.在主线程的下一个 runloop 到来时，Core Animation 提交了这个隐式的 transaction ，这个过程可能会对图片进行 copy 操作，而受图片是否字节对齐等因素的影响，这个 copy 操作可能会涉及以下部分或全部步骤：

*   分配内存缓冲区用于管理文件 IO 和解压缩操作；
*   将文件数据从磁盘读到内存中；
*   将压缩的图片数据解码成未压缩的位图形式，这是一个非常耗时的 CPU 操作；
*   最后 `Core Animation` 中`CALayer`使用未压缩的位图数据渲染 `UIImageView` 的图层。
*   CPU计算好图片的Frame,对图片解压之后.就会交给GPU来做图片渲染渲染流程
*   GPU获取获取图片的坐标
*   将坐标交给顶点着色器(顶点计算)
*   将图片光栅化(获取图片对应屏幕上的像素点)
*   片元着色器计算(计算每个像素点的最终显示的颜色值)
*   从帧缓存区中渲染到屏幕上

图片渲染到屏幕的过程: 读取文件->cpu计算Frame->cpu图片解码->解码后纹理图片位图数据通过数据总线交给GPU->GPU获取图片Frame->顶点变换计算->光栅化->根据纹理坐标获取每个像素点的颜色值(如果出现透明值需要将每个像素点的颜色*透明度值)->渲染到帧缓存区->渲染到屏幕

图片的解压缩是非常耗时的cpu操作，且默认是在主线程执行。当在快速滑动的列表上有多张图片显示时，应用的响应性就会比较差。

解压缩是否必须

是必须的。因为将图片渲染到屏幕之前，必须拿到图片的原始像素数据bitmap(位图)。之前提到的jpg，png，gif，webp都是一种压缩的位图图形格式。只不过png是无损压缩，jpg是有损压缩。

位图：
就是bitmap文件，它是一种非压缩的图片格式。所谓的非压缩，就是图片每个像素的原始信息在存储器中依次排列，比如1920*1080像素的 bitmap 图片，每个像素由 RGBA 四个字节表示颜色，那么它的体积就是 1920 * 1080 * 4 / 8 = 1012.5kb。
由于 bitmap 简单顺序存储图片的像素信息，它可以不经过解码就直接被渲染到 UI 上。实际上，其它格式的图片都需要先被首先解码为 bitmap，然后才能渲染到界面上。

图片解压缩的过程其实就是将图片的二进制数据转换成像素数据的过程

如何做到性能优化：

未解压缩的图片将要渲染到屏幕时，cpu会在在主线程解压缩，而解压缩过的图片，就不会再去解压缩了。
常见的解决方案是在子线程提前对图片进行解压缩。强制解压缩的原理就是对图片进行重新绘制，得到一张新的解压缩后的位图。
YYImage\SDWebImage主流框架的也大致是这么实现的。

// 1. 从 UIImage 对象中获取 CGImageRef 的引用。这两个结构是苹果在不同层级上对图片的表示方式，UIImage 属于 UIKit，是 UI 层级图片的抽象，用于图片的展示；CGImageRef 是 QuartzCore 中的一个结构体指针，用C语言编写，用来创建像素位图，可以通过操作存储的像素位来编辑图片。这两种结构可以方便的互转：
CGImageRef imageRef = image.CGImage;

// 2. 调用 UIImage 的 +colorSpaceForImageRef: 方法来获取原始图片的颜色空间参数。
CGColorSpaceRef colorspaceRef = [UIImage colorSpaceForImageRef:imageRef];
        
size_t width = CGImageGetWidth(imageRef);
size_t height = CGImageGetHeight(imageRef);

// 3. 计算图片解码后每行需要的比特数，由两个参数相乘得到：每行的像素数 width，和存储一个像素需要的比特数4(这里的4，其实是由每张图片的像素格式和像素组合来决定的)
size_t bytesPerRow = 4 * width;

// 4. 最关键的函数：调用 CGBitmapContextCreate() 方法，生成一个空白的图片绘制上下文，我们传入了上述的一些参数，指定了图片的大小、颜色空间、像素排列等等属性。
CGContextRef context = CGBitmapContextCreate(NULL,
                                             width,
                                             height,
                                             kBitsPerComponent,
                                             bytesPerRow,
                                             colorspaceRef,
                                             kCGBitmapByteOrderDefault|kCGImageAlphaNoneSkipLast);
if (context == NULL) {
    return image;
}
        
// 5. 调用 CGContextDrawImage() 方法，将未解码的 imageRef 指针内容，写入到我们创建的上下文中，这个步骤，完成了隐式的解码工作。
CGContextDrawImage(context, CGRectMake(0, 0, width, height), imageRef);

// 6. 从 context 上下文中创建一个新的 imageRef，这是解码后的图片了。
CGImageRef newImageRef = CGBitmapContextCreateImage(context);

// 7. 从 imageRef 生成供UI层使用的 UIImage 对象，同时指定图片的 scale 和 orientation 两个参数。
UIImage *newImage = [UIImage imageWithCGImage:newImageRef
                                        scale:image.scale
                                  orientation:image.imageOrientation];

CGContextRelease(context);
CGImageRelease(newImageRef);

return newImage;

YYImage 中对图片的解压缩过程与上述完全一致，只是传递给 CGBitmapContextCreate 函数的部分参数存在细微的差别

性能对比:

在解压PNG图片,SDWebImage>YYImage
在解压JPEG图片,SDWebImage<YYImage

这样就在子线程中对图片进行了强制解码，回调给主线程使用，从而大大提高了图片的渲染效率。这也是现在主流三方库图片解码的最佳实践。