1. 前言
2018 WWDC 苹果官方给出了关于iOS图像处理的最佳实践，本文主要是就官方文档进行分析总结以及较为全面的拓展延伸。
官方文档：Image and Graphics Best Practices
2. 基础预备知识
本地图片显示到屏幕中，经历了哪些过程
代码很easy呀，两行搞定
UIImage *image = [UIImage imageNamed:@"xxxxx"];
imageView.image = image;
但是这中间的图片加载真实过程如下
- 从磁盘读取原始压缩的图片数据（png/jpeg格式等等）缓存到内存
- CPU解压成未压缩的图片数据 （imageBuffer）
- 渲染图片（会生成frameBuffer，帧缓存，最终显示到手机屏幕）
按照经典的MVC架构，UIImage扮演model角色，负责承载图片数据，UIImageView充当View的角色，负责渲染和展示图片。系统提供接口非常的简单，这中间隐藏了解码的过程。
Buffers
Buffer是一段连续的内存区域，下面我们看下图片处理相关的Buffer
Data Buffer
Data Buffer存储了图片的元数据，我们常见的图片格式，jpeg，png等都是压缩图片格式。Data Buffer的内存大小就是源图片在磁盘中的大小。
Image Buffer
Image Buffer存储的就是图片解码后的像素数据，也就是我们常说的位图。
Buffer中每一个元素描述的一个像素的颜色信息，buffer的size和图片的size成正相关关系。
Frame Buffer
Frame 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按钮
先看一种不合理的实现方式
我们先来分析这种方案的问题所在，
UIView是通过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绘制方案的问题
- Backing Store的创建造成了不必要的内存开销
- UIImage先绘制到Backing Store，再渲染到frameBuffer，中间多了一层内存拷贝
- 背景颜色不需要绘制到Backing Store，直接使用BackGroundColor绘制到FrameBuffer
所以，正确的实现姿势是将这个大的view拆分成小的subview逐个实现。
背景颜色实现
这里有一个圆角的处理
UIView的maskView 及CALayer.maskLayer都会将图层渲染到临时的image buffer中，也就是我们常说的离屏渲染，而CALayer.cornerRadius不会造成离屏渲染，真正造成离屏渲染的是设置MaskToBounds这样的属性。所以背景图直接使用UIView设置BackGroudColor即可。
这里拓展下圆角的处理，先看一种不正确的做法
override func drawRect(rect: CGRect) {
let maskPath = UIBezierPath(roundedRect: rect,
byRoundingCorners: .AllCorners,
cornerRadii: CGSize(width: 5, height: 5))
let maskLayer = CAShapeLayer()
maskLayer.frame = self.bounds
maskLayer.path = maskPath.CGPath
self.layer.mask = maskLayer
}
首先同理，重写drawRect会造成不必要的backing store内存开销，并且这种做法的本质是创建遮罩mask，再进行图层混合，同样会离屏渲染。
正确的姿势，
对于UIView直接使用CornerRadius，CoreAnimation可以为我们在不额外创建内存开销的情况下绘制出圆角。
对于UIImageView可以使用CoreGraphics自己裁剪出带圆角的Image，实例代码如下
extension UIImage {
func drawRectWithRoundedCorner(radius radius: CGFloat, _ sizetoFit: CGSize) -> UIImage {
let rect = CGRect(origin: CGPoint(x: 0, y: 0), size: sizetoFit)
UIGraphicsBeginImageContextWithOptions(rect.size, false, UIScreen.mainScreen().scale)
CGContextAddPath(UIGraphicsGetCurrentContext(),
UIBezierPath(roundedRect: rect, byRoundingCorners: UIRectCorner.AllCorners,
cornerRadii: CGSize(width: radius, height: radius)).CGPath)
CGContextClip(UIGraphicsGetCurrentContext())
self.drawInRect(rect)
CGContextDrawPath(UIGraphicsGetCurrentContext(), .FillStroke)
let output = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return output
}
}
Live图片实现
直接使用UIImageView，这里有个技巧，如果是纯色图片，想要展示不同颜色的同一张图片，可以使用UIImageView的tintColor属性平铺颜色，来达到复用图片的目的。
代码如下：
UIImage.withRenderingMode(_:)
UIImageView.tintColor
文本实现
文本使用UILabel可以减少百分之75的Backing Store开销，系统针对UILabel做了优化,并且自动更新Backing Store的size，针对emoji和富文本内容。
最终实现
最终Live按钮的正确实现方案如下图
推荐使用Image Assets
- 基于名称和特效优化了查找效率，更快的查找图片
- 运行时，对内存的管理也有优化
- App Slicing，app安装包瘦身。iOS 9 后会从 Image Assets 中保留设备支持的图片 （2x 或者 3x）
- iOS 11 后的 Preserve Vector Data。支持矢量图的功能，放大也不会失真
Advanced Image Effects
对于图片的实时处理推荐使用CoreImage框架。
例如将一张图片的灰度值进行调整这样的操作，有滴小伙伴可能使用CoreGraphics获取图像的每个像素点数据，然后改变灰度值，最终生成目标图标，这种做法将大量gpu擅长的工作放在了cpu上处理，合理的做法是: 使用CoreImage的滤镜filter或者metal，OpenGL的shader，让图像处理的工作交给GPU去做。
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的注释
pecifies whether image decoding and caching should happen at image creation time.
The value of this key must be a CFBooleanRef. The default value is kCFBooleanFalse (image decoding will happen at rendering time).
也就是说UIImage只有在屏幕上渲染时再去解码的。而关于UIImageView的操作一定是在主线程，解码操作是放在主线程的。所以如果在tableview滑动中频繁的创建较大的UIImage渲染展示，会造成主线程阻塞。
总结: imageNamed默认带缓存，缓存通过NSCache实现。适用于需要频繁复用的图片的加载，而imageWithContentsOfFile不会缓存，适用于不常用的较大图片的加载，由于系统默认主线程解码UIImage，所以imageNamed仅仅适用于加载较小的例如APP各个tab的icon，需要在首屏展示的图片。而不适用于滑动的下载好的大量网络图片的本地加载。会造成主线程阻塞。
5. 正确的网络图片加载方式
其实这里SDWebImage或者YYWebImage等框架已经给出了正确的姿势，细节可以挑其中一个阅读源码即可。
分享下优秀的源码解析
下载图片主要简化流程如下
- 从网络下载图片源数据，默认放入内存和磁盘缓存中
- 异步解码，解码后的数据放入内存缓存中
- 回调主线程渲染图片
- 内部维护磁盘和内存的cache，支持设置定时过期清理，内存cache的上限等
加载图片的主要简化流程如下
- 从内存中查找图片数据，如果有并且已经解码，直接返回数据，如果没有解码，异步解码缓存内存后返回
- 内存中未查找到图片数据，从磁盘查找，磁盘查找到后，加载图片源数据到内存，异步解码缓存内存后返回，如果没有去网络下载图片。走上面的流程。
分析:
- 这样滴流程解决了UIImage imageNamed这种加载一定在主线程解码图片的问题，异步加载，避免了主线程阻塞。
- 通过缓存内存方式，避开了频繁的磁盘IO
- 通过缓存解码后的图片数据，避开了频繁解码的CPU消耗。
6. 超大图片的处理
之前我们分析过1080p的图片解码后的内存大小，大约是7.9mb，如果是4k，8k图，这个内存占用将会非常的大，如果使用SDWebImage或者YYWebImage的默认解码缓存技术方案去加载多张这样的大图，带来的结果会是内存爆掉。闪退。
可以设置SDWebImage或者YYWebImage的Option选项不解码下载好的图片
那么大图该怎么处理呢，这里有两个场景
- 一张超大图加载在一个小的view上
解决方法: 使用苹果推荐的缩略图DownSampling方案即可
- 像微信，微博长图详情那样，全屏加载大图，通过拖动来查看不同位置图片细节
解决方法: 使用苹果的CATiledLayer去加载。原理是分片渲染，滑动时通过指定目标位置，通过映射原图指定位置的部分图片数据解码渲染。这里不再累述，有兴趣的小伙伴可以自行了解下官方API。
7. 总结
了解图像加载的细节和全过程非常有必要，有助于我们在平常开发中选择合适的方案，做出合理的性能优化。
