本地图片显示到屏幕中，经历了哪些过程
代码很easy呀，两行搞定
UIImage *image = [UIImage imageNamed:@"xxxxx"];
imageView.image = image;
但是这中间的图片加载真实过程如下
从磁盘读取原始压缩的图片数据（png/jpeg格式等等）缓存到内存
CPU解压成未压缩的图片数据 （imageBuffer）
渲染图片（会生成frameBuffer，帧缓存，最终显示到手机屏幕）
按照经典的MVC架构，UIImage扮演model角色，负责承载图片数据，UIImageView充当View的角色，负责渲染和展示图片。系统提供接口非常的简单，这中间隐藏了解码的过程。
帧缓冲存储器(Frame Buffer)：简称帧缓存或显存，它是屏幕所显示画面的一个直接映象，又称为位映射图(Bit Map)或光栅。帧缓存的每一存储单元对应屏幕上的一个像素，整个帧缓存对应一帧图像。
Data Buffer
Data Buffer存储了图片的元数据，我们常见的图片格式，jpeg，png等都是压缩图片格式。Data Buffer的内存大小就是源图片在磁盘中的大小。
Image Buffer
Image Buffer存储的就是图片解码后的像素数据，也就是我们常说的位图。 Buffer中每一个元素描述的一个像素的颜色信息，buffer的size和图片的size成正相关关系。
Frame Buffer
fame Buffer 存储了app每帧的实际输出
和OpenGL中FrameBuffer类似，苹果不允许我们直接渲染操作屏幕显示，而是把渲染数据放入帧缓存中，由系统按照60hz-120hz的频率扫描显示。
当app视图层级发生变化时，UIKit 会结合 UIWindow 和 Subviews，渲染出一个 frame buffer，然后按60hz的频率扫描（ipad最高可以达到120hz）显示到屏幕上。
解码操作
UIImage负责解压Data Buffer内容并申请buffer（Image Buffer）存储解压后的图片信息。UIImageView负责将Image Buffer 拷贝至 framebuffer，用于显示屏幕展示。
解压过程会大量占用cpu，所以UIImage会持有解压后的图片数据，以便给需要渲染的地方复用数据。
综上我们可以看到渲染的全过程。这里需要注意的是，解码后的ImageBuffer大小理论上只和图片尺寸相关。
ImageBuffer按照每个像素RGBA四个字节大小，一张1080p的图片解码后的位图大小是1920 * 1080 * 4 / 1024 / 1024，约7.9mb，而原图假设是jpg，压缩比1比20，大约350kb，可见解码后的内存占用是相当大的。
3. 官方最佳实践
内存的占用会导致我们app的CPU占用高，直接导致耗电大，APP响应慢
DownSampling（降低采样）
在视图比较小，图片比较大的场景下，直接展示原图片会造成不必要的内存和CPU消耗，这里就可以使用ImageIO的接口，DownSampling，也就是生成缩略图
具体代码如下，指定显示区域大小
这里有两个注意事项
设置kCGImageSourceShouldCache为false，避免缓存解码后的数据，64位设置上默认是开启缓存的，（很好理解，因为下次使用该图片的时候，可能场景不同，需要生成的缩略图大小是不同的，显然不能做缓存处理）
设置kCGImageSourceShouldCacheImmediately为true，避免在需要渲染的时候才做解码，默认选项是false
这样的缩略图方式可以省去大量的内存和CPU消耗，官方Case给出的前后内存对比
Prefetching && Background decoding
解码过程是非常占用CPU资源的，放在主线程一定会造成阻塞，所以这个操作应该放在异步线程。代码如下
Prefetching：预加载，也就是提前为之后的cell预加载数据（基本上主流的app都有这么做滴，iOS10之后，系统引入的tableView(_:prefetchRowsAt:) 可以更加方便的实现预加载。）
小tips: 这里使用串行队列可以很好地避免Thread Explosion，线程切换的代价是非常昂贵的，所以在我们app中应该使用GCD串行队列创建一个解码线程。
官方实现UI实例
我们现在需要实现下面的live按钮
先看一种不合理的实现方式
我们先来分析这种方案的问题所在，
IView是通过CALayer创建FrameBuffer最后显示的。重写了drawRect方法，Calayer会创建一个Backing Store，然后在Backing Store上执行draw函数，最后将内容传递给frameBuffer最终显示。
Backing Store的默认大小和View的大小成正比，以iphone6为例，750 * 1134 * 4 字节 ≈ 3.4 Mb。
iOS 12，对 backing store 有做优化，它的大小会根据图片的色彩空间，动态改变。 在此之前，如果你使用 sRGB 格式，但是实际绘制的内容，只使用了单通道，那么大小会比实际要的大，造成不必要开销。iOS 12 会自动优化这部分。
总结下这种使用drawRect绘制方案的问题
1.Backing Store的创建造成了不必要的内存开销
2.UIImage先绘制到Backing Store，再渲染到frameBuffer，中间多了一层内存拷贝
3.背景颜色不需要绘制到Backing Store，直接使用BackGroundColor绘制到FrameBuffer
所以，正确的实现姿势是将这个大的view拆分成小的subview逐个实现。
Drawing Off-Screen
对于需要离屏渲染的场景推荐使用UIGraphicsImageRenderer替代UIGraphicsBeginImageContext，性能更好，并且支持广色域。
4. 拓展与思考
用提问的方式来拓展一下，针对每个问题进行深入的思考
问题一：图像展示有这么多细节在里面，可是为什么在平常开发中为什么没有感觉到，可以从哪些地方对自己的工程进行优化。
答：我们平常大部分会使用UIImage imageNamed这样的API加载了本地图片，而网络图片则使用了SDWebImage或者YYWebImage等框架来加载。所以没有去细究。
问题二: 使用imageNamed，系统何时去解码，有没有缓存，缓存的大小是多少，有没有性能问题，和imageWithContentsOfFile有什么区别
答: 一一来解答这个问题
首先先说imageNamed和imageWithContentsOfFile有什么区别，想必大部分小伙伴都很清楚，因为这也是面试老生常谈的东西。imageNamed加载本地图片会缓存图片，也就是加载一千张相同的本地图片，内存中也只会有一份，而imageWithContentsOfFile不会缓存，也就是重复加载相同图片，在内存中会有多份图片数据。
imageNamed加载图片会将图片源数据和解码后的数据加载入内存缓存中，只有收到内存警告的时候才会释放，有兴趣的小伙伴可以自行调试一下。
关于UIImage对象何时去解码，其实刚刚我们在降低采样的时候已经提到了，kCGImageSourceShouldCacheImmediately属性系统默认是false，我们可以看ImageIO/CGImageSource.h文件中kCGImageSourceShouldCache的注释
也就是说UIImage只有在屏幕上渲染时再去解码的。而关于UIImageView的操作一定是在主线程，解码操作是放在主线程的。所以如果在tableview滑动中频繁的创建较大的UIImage渲染展示，会造成主线程阻塞。
总结: imageNamed默认带缓存，缓存通过NSCache实现。适用于需要频繁复用的图片的加载，而imageWithContentsOfFile不会缓存，适用于不常用的较大图片的加载，由于系统默认主线程解码UIImage，所以imageNamed仅仅适用于加载较小的例如APP各个tab的icon，需要在首屏展示的图片。而不适用于滑动的下载好的大量网络图片的本地加载。会造成主线程阻塞。
6. 超大图片的处理
之前我们分析过1080p的图片解码后的内存大小，大约是7.9mb，如果是4k，8k图，这个内存占用将会非常的大，如果使用SDWebImage或者YYWebImage的默认解码缓存技术方案去加载多张这样的大图，带来的结果会是内存爆掉。闪退。
可以设置SDWebImage或者YYWebImage的Option选项不解码下载好的图片
那么大图该怎么处理呢，这里有两个场景
1.一张超大图加载在一个小的view上
解决方法: 使用苹果推荐的缩略图DownSampling方案即可
2.像微信，微博长图详情那样，全屏加载大图，通过拖动来查看不同位置图片细节
解决方法: 使用苹果的CATiledLayer去加载。原理是分片渲染，滑动时通过指定目标位置，通过映射原图指定位置的部分图片数据解码渲染。这里不再累述，有兴趣的小伙伴可以自行了解下官方API。
阳离子层CATiledLayer
5. 正确的网络图片加载方式
其实这里SDWebImage或者YYWebImage等框架已经给出了正确的姿势，细节可以挑其中一个阅读源码即可。
分享下优秀的源码解析
YImage 设计思路，实现细节剖析
YYWebImage 源码剖析：线程处理与缓存策略
下载图片主要简化流程如下
1.从网络下载图片源数据，默认放入内存和磁盘缓存中
2.异步解码，解码后的数据放入内存缓存中
3.回调主线程渲染图片
4.内部维护磁盘和内存的cache，支持设置定时过期清理，内存cache的上限等
加载图片的主要简化流程如下
1.从内存中查找图片数据，如果有并且已经解码，直接返回数据，如果没有解码，异步解码缓存内存后返回
2.内存中未查找到图片数据，从磁盘查找，磁盘查找到后，加载图片源数据到内存，异步解码缓存内存后返回，如果没有去网络下载图片。走上面的流程。
分析:
这样滴流程解决了UIImage imageNamed这种加载一定在主线程解码图片的问题，异步加载，避免了主线程阻塞。
通过缓存内存方式，避开了频繁的磁盘IO
通过缓存解码后的图片数据，避开了频繁解码的CPU消耗。