阅读 3303

iOS图像最佳实践总结

1. 前言

2018 WWDC 苹果官方给出了关于iOS图像处理的最佳实践,本文主要是就官方文档进行分析总结以及较为全面的拓展延伸。

官方文档:Image and Graphics Best Practices

2. 基础预备知识

本地图片显示到屏幕中,经历了哪些过程

代码很easy呀,两行搞定

    UIImage *image = [UIImage imageNamed:@"xxxxx"];
    imageView.image = image;
复制代码

但是这中间的图片加载真实过程如下

图片加载过程

  1. 从磁盘读取原始压缩的图片数据(png/jpeg格式等等)缓存到内存
  2. CPU解压成未压缩的图片数据 (imageBuffer)
  3. 渲染图片(会生成frameBuffer,帧缓存,最终显示到手机屏幕)

按照经典的MVC架构,UIImage扮演model角色,负责承载图片数据,UIImageView充当View的角色,负责渲染和展示图片。系统提供接口非常的简单,这中间隐藏了解码的过程。

Buffers

Buffer是一段连续的内存区域,下面我们看下图片处理相关的Buffer

Data Buffer

Data Buffer

Data Buffer存储了图片的元数据,我们常见的图片格式,jpeg,png等都是压缩图片格式。Data Buffer的内存大小就是源图片在磁盘中的大小。

Image Buffer

Image Buffer

Image Buffer存储的就是图片解码后的像素数据,也就是我们常说的位图。 Buffer中每一个元素描述的一个像素的颜色信息,buffer的size和图片的size成正相关关系。

Frame Buffer

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响应慢

Memory & CPU

DownSampling(降低采样)

在视图比较小,图片比较大的场景下,直接展示原图片会造成不必要的内存和CPU消耗,这里就可以使用ImageIO的接口,DownSampling,也就是生成缩略图

DownSampling

具体代码如下,指定显示区域大小

DownSampling Code

这里有两个注意事项

  • 设置kCGImageSourceShouldCache为false,避免缓存解码后的数据,64位设置上默认是开启缓存的,(很好理解,因为下次使用该图片的时候,可能场景不同,需要生成的缩略图大小是不同的,显然不能做缓存处理)
  • 设置kCGImageSourceShouldCacheImmediately为true,避免在需要渲染的时候才做解码,默认选项是false

这样的缩略图方式可以省去大量的内存和CPU消耗,官方Case给出的前后内存对比

DownSampling内存对比

Prefetching && Background decoding

解码过程是非常占用CPU资源的,放在主线程一定会造成阻塞,所以这个操作应该放在异步线程。代码如下

code

Prefetching:预加载,也就是提前为之后的cell预加载数据(基本上主流的app都有这么做滴,iOS10之后,系统引入的tableView(_:prefetchRowsAt:) 可以更加方便的实现预加载。)

小tips: 这里使用串行队列可以很好地避免Thread Explosion,线程切换的代价是非常昂贵的,所以在我们app中应该使用GCD串行队列创建一个解码线程。

官方实现UI实例

我们现在需要实现下面的live按钮

Live按钮

先看一种不合理的实现方式

不合理绘制

我们先来分析这种方案的问题所在,

系统draw实现

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绘制方案的问题

    1. Backing Store的创建造成了不必要的内存开销
    1. UIImage先绘制到Backing Store,再渲染到frameBuffer,中间多了一层内存拷贝
    1. 背景颜色不需要绘制到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有什么区别

答: 一一来解答这个问题

  1. 首先先说imageNamed和imageWithContentsOfFile有什么区别,想必大部分小伙伴都很清楚,因为这也是面试老生常谈的东西。imageNamed加载本地图片会缓存图片,也就是加载一千张相同的本地图片,内存中也只会有一份,而imageWithContentsOfFile不会缓存,也就是重复加载相同图片,在内存中会有多份图片数据。
  2. imageNamed加载图片会将图片源数据和解码后的数据加载入内存缓存中,只有收到内存警告的时候才会释放,有兴趣的小伙伴可以自行调试一下。
  3. 关于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等框架已经给出了正确的姿势,细节可以挑其中一个阅读源码即可。

分享下优秀的源码解析

YImage 设计思路,实现细节剖析

YYWebImage 源码剖析:线程处理与缓存策略

下载图片主要简化流程如下

  1. 从网络下载图片源数据,默认放入内存和磁盘缓存中
  2. 异步解码,解码后的数据放入内存缓存中
  3. 回调主线程渲染图片
  4. 内部维护磁盘和内存的cache,支持设置定时过期清理,内存cache的上限等

加载图片的主要简化流程如下

  1. 从内存中查找图片数据,如果有并且已经解码,直接返回数据,如果没有解码,异步解码缓存内存后返回
  2. 内存中未查找到图片数据,从磁盘查找,磁盘查找到后,加载图片源数据到内存,异步解码缓存内存后返回,如果没有去网络下载图片。走上面的流程。

分析:

  • 这样滴流程解决了UIImage imageNamed这种加载一定在主线程解码图片的问题,异步加载,避免了主线程阻塞。
  • 通过缓存内存方式,避开了频繁的磁盘IO
  • 通过缓存解码后的图片数据,避开了频繁解码的CPU消耗。

6. 超大图片的处理

之前我们分析过1080p的图片解码后的内存大小,大约是7.9mb,如果是4k,8k图,这个内存占用将会非常的大,如果使用SDWebImage或者YYWebImage的默认解码缓存技术方案去加载多张这样的大图,带来的结果会是内存爆掉。闪退。

可以设置SDWebImage或者YYWebImage的Option选项不解码下载好的图片

那么大图该怎么处理呢,这里有两个场景

  1. 一张超大图加载在一个小的view上

解决方法: 使用苹果推荐的缩略图DownSampling方案即可

  1. 像微信,微博长图详情那样,全屏加载大图,通过拖动来查看不同位置图片细节

解决方法: 使用苹果的CATiledLayer去加载。原理是分片渲染,滑动时通过指定目标位置,通过映射原图指定位置的部分图片数据解码渲染。这里不再累述,有兴趣的小伙伴可以自行了解下官方API。

7. 总结

了解图像加载的细节和全过程非常有必要,有助于我们在平常开发中选择合适的方案,做出合理的性能优化。

关注下面的标签,发现更多相似文章
评论