UI卡顿分析及优化总结
作为一个iOS小菜鸟，当我们需求做完之后，我们该干什么？当然是学习！最近看了很多关于iOS性能优化的文章，为了便于以后回顾学习，所以就写一篇文章记录总结一下，如有雷同，肯定是我用的大神们的，版权归原作者所有。
文章开始我们先来简单了解一下为什么有时候我们在滑动屏幕时会出现卡顿，这背后的原理又是什么呢？下面我们先来看一下屏幕显示的原理。
屏幕显示原理
CRT扫描方式
我们小时候应该都看过那种旧的电视机，成像主要是使用CRT(阴极显像管)的电子枪扫描荧光屏来发光。电子枪按照从左至右、从上到下顺序来扫描，为了把显示器的显示过程和系统的视频控制器进行同步，显示器（或者其他硬件）会用硬件时钟产生一系列的定时信号。每当扫描完一行将要扫描下一行时，显示器会发出一个水平同步信号（horizonal synchronization），简称 HSync；而当一帧画面绘制完成后，电子枪回复到第一行的位置，准备扫描下一帧前，显示器会发出一个垂直同步信号（vertical synchronization），简称 VSync。显示器通常以固定频率进行刷新，这个刷新率就是 VSync 信号产生的频率。尽管现在的设备大都是液晶显示屏了，但原理仍然没有变。
图像计算渲染显示流程
从上图中我们可以看，一帧图片从计算、渲染、显示需要通过CPU、GPU以及显示器来共同处理。CPU主要是创建视图分配内存、计算布局、图片解码以及文本绘制，将要显示的内容准备好，交给GPU渲染，然后GPU将渲染完成的内容交给帧缓冲区，然后视频控制器按照Vsync信号从帧缓冲区逐行提取提取每一帧然后通过处理在显示器上显示。但是如果按照上面的原理来看，如果当我们的GPU渲染速度很快，超过了我们的Vsync信号产生的频率(VSync 信号由硬件时钟生成，每秒钟发出 60 次（这个值取决设备硬件，比如 iPhone 真机上通常是 59.97）。)这样的话当我们上一帧还没被视频控制器提取显示的时候，我们新的一帧已经渲染完成，这样的话新的一帧就会覆盖上一帧，在实际数据处理过程中，缓冲区的数据，在被输出之前，就被GPU不断的刷新重写。但是缓冲区并不是“先清空再写入数据”，这太没有效率，而是采用“新数据覆盖老数据”的方式。
所以就会出现这样一种情况，当帧缓冲区中已经存在渲染完成的一帧A,此时GPU又渲染完成了一帧B,当帧A被帧B数据覆盖的过程中，接收到了Vsync信号，这是视频控制器将会在帧缓冲区中提取帧并给显示显示，但是此时的帧是部分A部分B这样就会出现我们平常看到的画面有割裂的情况。
屏幕撕裂图
上面说的是一个帧缓冲区的情况，为了解决效率问题，显示系统通常会引入两个缓冲区，即双缓冲机制。在这种情况下，GPU 会预先渲染好一帧放入一个缓冲区内，让视频控制器读取，当下一帧渲染好后，GPU 会直接把视频控制器的指针指向第二个缓冲器。如此一来效率会有很大的提升。但是同样的问题也会出现在这里，如果GPU在上一帧提取显示完成之前，渲染完成新的一帧并放入另一个缓冲区，那么视频控制器的指针会马上指向存有新的一帧的缓冲区，这样一来当前显示的一帧就会有部分是新的一帧的数据，同样会出现屏幕撕裂的问题。因为我们无法控制GPU新的一帧渲染完成之前旧的一帧一定已经提取显示完成，所以我们必须要处理帧渲染和提取显示的关系。
为了解决这个问题，GPU 通常有一个机制叫做垂直同步（简写也是 V-Sync），当开启垂直同步后，GPU 会等待显示器的 VSync 信号发出后也就是当前帧已经扫描完成之后，才进行新的一帧渲染和缓冲区更新。这样一来就能确保在当前帧显示完成之后才渲染下一帧，能解决画面撕裂现象，也增加了画面流畅度，但需要消费更多的计算资源，也会带来部分延迟。但是这个同样也带来了一些问题，我们需要在VSync信号发出之后和下一次Vsync信号发出之前计算、渲染完这一帧并提交到缓冲区当中。
卡顿原因
卡顿原因
垂直同步机制决定了如果在一个时钟周期内CPU或者GPU没有完成各自的任务的话，就会将帧缓冲区里的内容直接丢弃，由上图我们可以看到如果我们没有在两次VSync信号之间的时间完成渲染就会出现掉帧和卡顿。所以无论是GPU还是CPU因为载荷过大，导致在一个时钟周期（1s/fps））内没有完成渲染，就会出现卡顿。因此我们优化的重点就在于减轻CPU和GPU的负担。
在我们UI界面创建的过程中，阻塞主线程的任务，主要分为下面这三大类。文本和布局的计算、渲染、解码、绘制都可以通过各种方式异步执行，但 UIKit 和 Core Animation 相关操作必需在主线程进行。
影响性能的主要因素
其中由CPU负责的主要有对象的创建、调整和销毁，以及视图布局的计算，和文本宽高的计算,图片的解码以及文本和图片的绘制。相对于 CPU 来说，GPU 能干的事情比较单一：接收提交的纹理（Texture）和顶点描述（三角形），应用变换（transform）、混合并渲染，然后输出到屏幕上。通常你所能看到的内容，主要也就是纹理（图片）和形状（三角模拟的矢量图形）两类。所以我们看到的一切其实都是在CPU布局计算绘制完成之后然后交给渲染服务使用GPU来渲染显示的。
对象的创建、修改、销毁
首先我们先来看一下对象创建、修改、销毁可能带来的性能问题以及优化的方法:
1.对象的创建
对象的创建会分配内存、调整属性、甚至还有读取文件等操作，比较消耗 CPU 资源。
（1）我们应该尽量用轻量的对象代替重量的对象，可以对性能有所优化。比如 CALayer 比 UIView 要轻量许多，那么不需要响应触摸事件的控件，用 CALayer 显示会更加合适，或者使用UIControl来代替UIButton。如果对象不涉及 UI 操作，则尽量放到后台线程去创建，但可惜的是包含有 CALayer 的控件，都只能在主线程创建和操作。
（2）通过 Storyboard 创建视图对象时，其资源消耗会比直接通过代码创建对象要大非常多，在性能敏感的界面里，Storyboard 并不是一个好的技术选择，但是相比之下XIB可能会更坑，当你加载一个XIB的时候所有内容都被放在了内存里，包括任何图片。如果有一个不会立即用到的view，你这就是在浪费宝贵的内存资源了。Storyboards就是另一码事儿了，storyboard仅在需要时实例化一个view controller。在XIB中，所有图片都是通过imageWithName：来加载的所以会被缓存。当然如果使用XIB内部层级比较简单和使用storyBoard性能相差不多的话使用XIB也未尝不可。
（3）尽量推迟对象创建的时间，当我们需要使用的时候才去创建对象比如懒加载，并把对象的创建分散到多个任务中去，避免当前不需要使用的对象创建消耗CPU性能以及内存空间。如果对象可以复用，并且复用的代价比释放、创建新对象要小，那么这类对象应当尽量放到一个缓存池里复用，例如系统UITablViewCell的复用机制。
2.对象的修改
对象的调整也经常是消耗 CPU 资源的地方。
（1）这里特别说一下 CALayer：CALayer 内部并没有属性，当调用属性方法时，它内部是通过运行时 resolveInstanceMethod 为对象临时添加一个方法，并把对应属性值保存到内部的一个 Dictionary 里，同时还会通知 delegate、创建动画等等，非常消耗资源。UIView 的关于显示相关的属性（比如 frame/bounds/transform）等实际上都是 CALayer 属性映射来的，所以对 UIView 的这些属性进行调整时，消耗的资源要远大于一般的属性。对此你在应用中，应该尽量减少不必要的属性修改。
当视图层次调整时，UIView、CALayer 之间会出现很多方法调用与通知，所以在优化性能时，应该尽量避免调整视图层次、添加和移除视图。
3.对象的销毁
对象的销毁虽然消耗资源不多，但累积起来也是不容忽视的。通常当容器类持有大量对象时，其销毁时的资源消耗就非常明显。
（1）如果对象可以放到后台线程去释放，那就挪到后台线程去。这里有个小技巧：把对象捕获到 block 中，然后扔到后台队列去随便发送个消息以避免编译器警告，就可以让对象在后台线程销毁了。
NSArray* deallocArray = dataArray;
dataArray= nil;//此时对象的引用计数并未为0
dispatch_async(dispatch_get_global_queue(1, 0), ^{
[deallocArray class]; //让block捕获外部变量并持有
});
视图布局计算、文本宽高计算、图片解码、图片文字的绘制
接着我们讨论一下布局和计算的问题以及可以优化的方法：
1.视图布局计算
视图布局的计算是 App 中最为常见的消耗 CPU 资源的地方。如果能在后台线程提前计算好视图布局、并且对视图布局进行缓存，那么这个地方基本就不会产生性能问题了。不论通过何种技术对视图进行布局，其最终都会落到对 UIView.frame/bounds/center 等属性的调整上。对这些属性的调整非常消耗资源，因为如上面对象修改中所说的一样.frame/bounds/center 等属性实际上是CALayer的属性的映射也就是涉及到对象的修改，所以尽量提前计算好布局，在需要时一次性调整好对应属性，而不要多次、频繁的计算和调整这些属性。
（1）我们可以从后台拿到数据后根据我们的布局样式提前计算好视图中各个子视图的高度以及视图自身的高度然后和数据封装在一起，而不是在需要显示时再去计算，同时如果内容不需要变化则高度也无需重新计算，我自己的做法是将布局数据放在model当中。
2.文本宽高的计算
如果视图中有较多的文本空间，文本的宽高计算会占用很大一部分资源，并且不可避免。如果你对文本显示没有特殊要求，可以参考下 UILabel 内部的实现方式：用 [NSAttributedString boundingRectWithSize:options:context:] 来计算文本宽高，用 -[NSAttributedString drawWithRect:options:context:] 来绘制文本。尽管这两个方法性能不错，但仍旧需要放到后台线程进行以避免阻塞主线程。我之前使用的都是sizeTahtFit这个方法，暂时还未比较两个方法在性能上是否会有较大的差异
。
3.Autolayout
Autolayout 是苹果本身提倡的技术，在大部分情况下也能很好的提升开发效率，但是 Autolayout 对于复杂视图来说常常会产生严重的性能问题。随着视图数量的增长，Autolayout 带来的 CPU 消耗会呈指数级上升。具体数据可以看这个文章：http://pilky.me/36/。 如果你不想手动调整 frame 等属性，你可以用一些工具方法替代（比如常见的 left/right/top/bottom/width/height 快捷属性），或者使用 ComponentKit、AsyncDisplayKit 等框架。这个暂时还未深究
如果你用 CoreText 绘制文本，那就可以先生成 CoreText 排版对象，然后自己计算了，并且 CoreText 对象还能保留以供稍后绘制使用。
4.文本绘制
屏幕上能看到的所有文本内容控件，包括 UIWebView，在底层都是通过 CoreText 排版、绘制为 Bitmap 显示的。常见的文本控件 （UILabel、UITextView 等），其排版和绘制都是在主线程进行的，当显示大量文本时，CPU 的压力会非常大。对此解决方案只有一个，那就是自定义文本控件，用 TextKit 或最底层的 CoreText 对文本异步绘制。尽管这实现起来非常麻烦，但其带来的优势也非常大，CoreText 对象创建好后，能直接获取文本的宽高等信息，避免了多次计算（调整 UILabel 大小时算一遍、UILabel 绘制时内部再算一遍）；CoreText 对象占用内存较少，可以缓存下来以备稍后多次渲染。
5.图片解码
当你用 UIImage 或 CGImageSource 的那几个方法创建图片时，图片数据并不会立刻解码。图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码。这一步是发生在主线程的，并且不可避免。如果想要绕开这个机制，常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。目前常见的网络图片库都自带这个功能。代码和下面的图片绘制相同。
6.图像的绘制
（1）图像的绘制通常是指用那些以 CG 开头的方法把图像绘制到画布中，然后从画布创建图片并显示这样一个过程。这个最常见的地方就是 [UIView drawRect:] 里面了，但是不建议随便重写drawRect方法因为一不小心会导致内存暴增，因为每次调用drawRect方法之前系统会创建一个图形上下文的环境并放到图形上下文的栈中，这个上下文占用的内存为4widthheigth*scale Byte。
（2）由于 CoreGraphic 方法通常都是线程安全的，所以图像的绘制可以很容易的放到后台线程进行。一个简单异步绘制的过程大致如下（实际情况会比这个复杂得多，但原理基本一致）：简单来说就是自己开辟一个位图上下文然后将img的内容绘制到这个位图上下文中，然后从这个位图上下文获取CGImageRef 然后赋值给layer.content。因为UIView主要是起到一个容器的作用，真正渲染内容的是CALayer而layer中显示什么内容由content决定如果我们给content赋值为CGImageRef则显示一张图片，因为CALayer的操作属于UI操作所以需要在主线程执行，所以我们在异步绘制得到CGImageRef之后需要在主线程赋值给layer.content。上代码：
-(void)displayWithImg:(UIImage*)img
{
CGImageRef imgRef = img.CGImage;
dispatch_async(dispatch_get_global_queue(0, 0), ^{
CGContextRef context = CGBitmapContextCreate(nil, CGImageGetWidth(imgRef), CGImageGetHeight(imgRef), CGImageGetBitsPerComponent(imgRef), CGImageGetBytesPerRow(imgRef), CGImageGetColorSpace(imgRef), CGImageGetBitmapInfo(imgRef));
CGContextSetInterpolationQuality(context, CGContextSetInterpolationQuality);//设置质量
CGContextDrawImage(context, CGRectMake(0, 0, img.size.width, img.size.height), imgRef);//将图片绘制到图形上下文中 并指定rect
CGImageRef img = CGBitmapContextCreateImage(context);
CFRelease(context);
dispatch_async(dispatch_get_main_queue(), ^{
layer.contents = img;//将cgImgRef赋值给layer的content
});
});
}
上面主要说的是CPU中负责处理的任务，下面来看一下GPU做的工作：
1.纹理的渲染
所有的 Bitmap，包括图片、文本、栅格化的内容，最终都要由内存提交到显存，绑定为 GPU Texture。不论是提交到显存的过程，还是 GPU 调整和渲染 Texture 的过程，都要消耗不少 GPU 资源。当在较短时间显示大量图片时（比如 TableView 存在非常多的图片并且快速滑动时），CPU 占用率很低，GPU 占用非常高，界面仍然会掉帧。
（1）避免这种情况的方法只能是尽量减少在短时间内大量图片的显示，尽可能将多张图片合成为一张进行显示。可以使用UIGraphicsBeginImageContextWithOptions来开启一个临时的图形上下文，然后将所有不需要交互的视图可以绘制为一张图片作为背景，使用UIGraphicsGetImageFromCurrentImageContext来获取之后的图片（因为之前看有人说这个方法不是线程安全的所以需要在主线程调用，但是确认了下应该是在iOS5.0以后已经是线程安全的了，所以可以在任何线程调用，这样我们就可以在后台线程调用避免阻塞主线程了）
（2）当图片过大，超过 GPU 的最大纹理尺寸时，图片需要先由 CPU 进行预处理，这对 CPU 和 GPU 都会带来额外的资源消耗。目前来说，iPhone 4S 以上机型，纹理尺寸上限都是 4096×4096，更详细的资料可以看这里：iosres.com。所以，尽量不要让图片和视图的大小超过这个值。
2.视图的混合 (Composing)
当多个视图（或者说 CALayer）重叠在一起显示时，GPU 会首先把他们混合到一起。如果视图结构过于复杂，混合的过程也会消耗很多 GPU 资源。
（1）为了减轻这种情况的 GPU 消耗，应用应当尽量减少视图数量和层次，并在不透明的视图里标明 opaque 属性以避免无用的 Alpha 通道合成。当然，这也可以用上面的方法，把多个视图预先渲染为一张图片来显示，处理方法与7.（1）类似。
同时我们需要注意的是，对于UIImageView来说，不仅它自身需要是不透明的，它的图片也不能含有alpha通道，而且我们的UIView中opaque默认就是YES,除非我们手动去设置Alpha值。导致图层混合的原因更多的在于我们忽略了backgroundColor这个属性，如果我们没有指定一个视图的背景颜色的话则默认为nil显示出来就是透明的，所以为了避免图层混合，我们不仅需要注意尽量少设置alpha为透明同时也要注意设置backgroundColor的颜色为非透明。
3.图形的生成
CALayer 的 border、圆角、阴影、遮罩（mask），CASharpLayer 的矢量图形显示，通常会触发离屏渲染（offscreen rendering），而离屏渲染通常发生在 GPU 中。当一个列表视图中出现大量圆角的 CALayer，并且快速滑动时，可以观察到 GPU 资源已经占满，而 CPU 资源消耗很少。这时界面仍然能正常滑动，但平均帧数会降到很低。
（1）为了避免这种情况，可以尝试开启 CALayer.shouldRasterize 属性，但这会把原本离屏渲染的操作转嫁到 CPU 上去。对于只需要圆角的某些场合，也可以用一张已经绘制好的圆角图片覆盖到原本视图上面来模拟相同的视觉效果。最彻底的解决办法，就是把需要显示的图形在后台线程绘制为图片，避免使用圆角、阴影、遮罩等属性。下面我们看一下不同视图处理圆角方法：
UIImage:得到的img是带圆角的但是要注意设置UIImageView的背景颜色因为它并不会沿着UIImage边缘切割。
-(UIImage*)imgWithCorner:(float)cornerRadius WithOriginImg:(UIImage*)originImg
{
UIGraphicsBeginImageContext(originImg.size);//创建一个临时的图形上下文
CGContextRef currentRef =UIGraphicsGetCurrentContext();
UIBezierPath * cornerPath = [UIBezierPath bezierPathWithRoundedRect:CGRectMake(0, 0, originImg.size.width, originImg.size.height) cornerRadius:cornerRadius];
CGContextAddPath(currentRef, cornerPath.CGPath);//添加圆角路径
CGContextClip(currentRef);
[originImg drawInRect:CGRectMake(0, 0, originImg.size.width, originImg.size.height)];
CGContextDrawPath(currentRef, kCGPathFillStroke);
UIImage * cornerImg =UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return cornerImg;
}
当然UIView的圆角操作也是和上面的类似的，同时你还可以自己设置路径来实现不同的效果。
（2）还有一点需要注意的是，我们在设置阴影时，我们给设置一个阴影路径，如果没有手动指定，Core Animation会去自动计算，这就会触发离屏渲染。如果人为指定了阴影路径，就可以免去计算，从而避免产生离屏渲染。
（3）设置cornerRadius本身并不会导致离屏渲染，但很多时候它还需要配合layer.masksToBounds = true使用。根据之前的总结，设置masksToBounds会导致离屏渲染。解决方案是尽可能在滑动时避免设置圆角，如果必须设置圆角，可以使用shouldRasterize光栅化技术将圆角缓存起来。
更多的UIKit性能问题我们可以使用Instrument来调试。
