一、UIView和CALayer
1、关系
UIView属性：MyView、layer、backgroundColor。其中layer其实就是CALayer的类型，backgroundColor是对CALayer同名属性方法的包装，UIView显示是由CALayer的contents决定的。关系图如下：
2、区别
UIView 为其提供内容，以及负责处理触摸等事件，参与响应链。
CALayer 负责显示内容contents。
注：这里体现的是单一职责。
二、视图事件传递和响应机制
1、事件传递
- 事件传递系统方法如下:
/**
哪个视图响应事件就把哪个视图返回
@param point 接收器局部坐标系中指定的点（边界）
@param event 保证调用此方法的事件，如果从事件处理代码外部调用此方法，则可以指定nil
@return 响应的UIView。如果该点完全位于接收者的视图层次结构之外，则返回nil。
*/
- (UIView*)hitTest:(CGPoint)point withEvent:(UIEvent*)event;
/**
判断某一个点击的位置是否在当前视图的范围内
@param point 点击点的位置
@param event 保证调用此方法的事件，如果从事件处理代码外部调用此方法，则可以指定nil
@return 如果点位于接收者的界限内，则为YES; 否则，不。
*/
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent*)event;
- 事件传递流程：
点击屏幕某一位置,这个事件就会传递到UIApplication，再由UIApplication传递到当前的UIWindow ，然后UIWindow里就会判断hitTest: withEvent:来返回最终的响应视图，这个是通过调用pointInside: withEvent:来判断当前点击位置是否在UIWindow范围内，如果在范围内就会(最后添加到UIWindow上的视图最优先被遍历到)子视图来查找最终响应这个事件的视图，即在每一个视图都会调用
hitTest: withEvent:方法，并返回一个响应视图，如果视图有值，这个视图就做为最终的事件响应视图。如果事件一直传递到UIAppliction还是没处理，那就会忽略掉。如图所示：
-
hitTest: withEvent:系统实现
在这个系统方法内部会优先判断当前视图的hidden、userInteractionEnabled和alpha属性，如果当前视图不隐藏，可交互且alpha>0.01 则会调用pointInside: withEvent:，否则返回nil结束事件。通过调用pointInside: withEvent:判断当前点是否在视图内，如果其返回YES则会遍历当前视图的子视图的hitTest: withEvent:直到找到sv!=nil返回sv ，结束事件；如果没有子视图就返回当前视图，结束事件。如图所示：
2、响应机制
视图响应传递链的流程图。注意：箭头表示
- 视图事件响应系统方法
///告诉此对象在视图或窗口中发生了一个或多个新触摸
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
///当与事件关联的一个或多个触摸发生更改时，告知响应者
- (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
///当从视图或窗口抬起一个或多个手指时告诉响应者
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
三、图像显示原理
原理：CPU和GPU都是通过总线连接起来，在CPU中输出的位图经由总线在合适的时机上传给GPU，GPU拿到位图做相应位图的图层渲染、纹理合成，之后将渲染好的结果放到帧缓冲区，由视频控制器根据Vsync（垂直同步信号）在指定时间之前去提取对应帧缓冲区当中的屏幕显示内容，最终显示到显示器即手机屏幕上。如图所示：
CPU工作
1.Layout: UI布局，文本计算
2.Display: 绘制
3.Prepare: 图片解码
4.Commit：提交位图GPU渲染管线
顶点着色，图元装配，光栅化，片段着色，片段处理UI卡顿、掉帧原因
由图像的显示原理，我们知道一帧的显示是由CPU和GPU共同决定的。一般来说，页面滑动流畅是60fps，也就是1s有60帧更新，即每隔16.7ms就要产生一帧画面，而如果CPU和GPU加起来的处理时间超过了16.7ms，就会造成掉帧甚至卡顿。
四、滑动优化方案
因为图像原理可知CPU和GPU共同决定了UI是否卡顿、掉帧，所以优化需从解决。优化方案是从iOS 保持界面流畅的技巧中copy😆的，大家可以看看这篇文章。
- CPU 资源消耗原因和解决方案
对象的创建会分配内存、调整属性、甚至还有读取文件等操作，比较消耗 CPU 资源。尽量用轻量的对象代替重量的对象，可以对性能有所优化。比如 CALayer 比 UIView 要轻量许多，那么不需要响应触摸事件的控件，用 CALayer 显示会更加合适。如果对象不涉及 UI 操作，则尽量放到后台线程去创建，但可惜的是包含有 CALayer 的控件，都只能在主线程创建和操作。通过 Storyboard 创建视图对象时，其资源消耗会比直接通过代码创建对象要大非常多，在性能敏感的界面里，Storyboard 并不是一个好的技术选择。
尽量推迟对象创建的时间，并把对象的创建分散到多个任务中去。尽管这实现起来比较麻烦，并且带来的优势并不多，但如果有能力做，还是要尽量尝试一下。如果对象可以复用，并且复用的代价比释放、创建新对象要小，那么这类对象应当尽量放到一个缓存池里复用。
对象的调整也经常是消耗 CPU 资源的地方。这里特别说一下 CALayer：CALayer 内部并没有属性，当调用属性方法时，它内部是通过运行时 resolveInstanceMethod 为对象临时添加一个方法，并把对应属性值保存到内部的一个 Dictionary 里，同时还会通知 delegate、创建动画等等，非常消耗资源。UIView 的关于显示相关的属性（比如 frame/bounds/transform）等实际上都是 CALayer 属性映射来的，所以对 UIView 的这些属性进行调整时，消耗的资源要远大于一般的属性。对此你在应用中，应该尽量减少不必要的属性修改。
当视图层次调整时，UIView、CALayer 之间会出现很多方法调用与通知，所以在优化性能时，应该尽量避免调整视图层次、添加和移除视图。
对象的销毁虽然消耗资源不多，但累积起来也是不容忽视的。通常当容器类持有大量对象时，其销毁时的资源消耗就非常明显。同样的，如果对象可以放到后台线程去释放，那就挪到后台线程去。这里有个小 Tip：把对象捕获到 block 中，然后扔到后台队列去随便发送个消息以避免编译器警告，就可以让对象在后台线程销毁了。
NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
[tmp class];
});
视图布局的计算是 App 中最为常见的消耗 CPU 资源的地方。如果能在后台线程提前计算好视图布局、并且对视图布局进行缓存，那么这个地方基本就不会产生性能问题了。
不论通过何种技术对视图进行布局，其最终都会落到对 UIView.frame/bounds/center 等属性的调整上。上面也说过，对这些属性的调整非常消耗资源，所以尽量提前计算好布局，在需要时一次性调整好对应属性，而不要多次、频繁的计算和调整这些属性。
Autolayout 是苹果本身提倡的技术，在大部分情况下也能很好的提升开发效率，但是 Autolayout 对于复杂视图来说常常会产生严重的性能问题。随着视图数量的增长，Autolayout 带来的 CPU 消耗会呈指数级上升。具体数据可以看这个文章：http://pilky.me/36/。 如果你不想手动调整 frame 等属性，你可以用一些工具方法替代（比如常见的 left/right/top/bottom/width/height 快捷属性），或者使用 ComponentKit、AsyncDisplayKit 等框架。
如果一个界面中包含大量文本（比如微博微信朋友圈等），文本的宽高计算会占用很大一部分资源，并且不可避免。如果你对文本显示没有特殊要求，可以参考下 UILabel 内部的实现方式：用 [NSAttributedString boundingRectWithSize:options:context:] 来计算文本宽高，用 -[NSAttributedString drawWithRect:options:context:] 来绘制文本。尽管这两个方法性能不错，但仍旧需要放到后台线程进行以避免阻塞主线程。
如果你用 CoreText 绘制文本，那就可以先生成 CoreText 排版对象，然后自己计算了，并且 CoreText 对象还能保留以供稍后绘制使用。
屏幕上能看到的所有文本内容控件，包括 UIWebView，在底层都是通过 CoreText 排版、绘制为 Bitmap 显示的。常见的文本控件 （UILabel、UITextView 等），其排版和绘制都是在主线程进行的，当显示大量文本时，CPU 的压力会非常大。对此解决方案只有一个，那就是自定义文本控件，用 TextKit 或最底层的 CoreText 对文本异步绘制。尽管这实现起来非常麻烦，但其带来的优势也非常大，CoreText 对象创建好后，能直接获取文本的宽高等信息，避免了多次计算（调整 UILabel 大小时算一遍、UILabel 绘制时内部再算一遍）；CoreText 对象占用内存较少，可以缓存下来以备稍后多次渲染。
当你用 UIImage 或 CGImageSource 的那几个方法创建图片时，图片数据并不会立刻解码。图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码。这一步是发生在主线程的，并且不可避免。如果想要绕开这个机制，常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。目前常见的网络图片库都自带这个功能。
图像的绘制通常是指用那些以 CG 开头的方法把图像绘制到画布中，然后从画布创建图片并显示这样一个过程。这个最常见的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是线程安全的，所以图像的绘制可以很容易的放到后台线程进行。一个简单异步绘制的过程大致如下（实际情况会比这个复杂得多，但原理基本一致）：
- (void)display {
dispatch_async(backgroundQueue, ^{
CGContextRef ctx = CGBitmapContextCreate(...);
// draw in context...
CGImageRef img = CGBitmapContextCreateImage(ctx);
CFRelease(ctx);
dispatch_async(mainQueue, ^{
layer.contents = img;
});
});
}
- GPU 资源消耗原因和解决方案
相对于 CPU 来说，GPU 能干的事情比较单一：接收提交的纹理（Texture）和顶点描述（三角形），应用变换（transform）、混合并渲染，然后输出到屏幕上。通常你所能看到的内容，主要也就是纹理（图片）和形状（三角模拟的矢量图形）两类。
所有的 Bitmap，包括图片、文本、栅格化的内容，最终都要由内存提交到显存，绑定为 GPU Texture。不论是提交到显存的过程，还是 GPU 调整和渲染 Texture 的过程，都要消耗不少 GPU 资源。当在较短时间显示大量图片时（比如 TableView 存在非常多的图片并且快速滑动时），CPU 占用率很低，GPU 占用非常高，界面仍然会掉帧。避免这种情况的方法只能是尽量减少在短时间内大量图片的显示，尽可能将多张图片合成为一张进行显示。
当图片过大，超过 GPU 的最大纹理尺寸时，图片需要先由 CPU 进行预处理，这对 CPU 和 GPU 都会带来额外的资源消耗。目前来说，iPhone 4S 以上机型，纹理尺寸上限都是 4096×4096，更详细的资料可以看这里：iosres.com。所以，尽量不要让图片和视图的大小超过这个值。
当多个视图（或者说 CALayer）重叠在一起显示时，GPU 会首先把他们混合到一起。如果视图结构过于复杂，混合的过程也会消耗很多 GPU 资源。为了减轻这种情况的 GPU 消耗，应用应当尽量减少视图数量和层次，并在不透明的视图里标明 opaque 属性以避免无用的 Alpha 通道合成。当然，这也可以用上面的方法，把多个视图预先渲染为一张图片来显示。
CALayer 的 border、圆角、阴影、遮罩（mask），CASharpLayer 的矢量图形显示，通常会触发离屏渲染（offscreen rendering），而离屏渲染通常发生在 GPU 中。当一个列表视图中出现大量圆角的 CALayer，并且快速滑动时，可以观察到 GPU 资源已经占满，而 CPU 资源消耗很少。这时界面仍然能正常滑动，但平均帧数会降到很低。为了避免这种情况，可以尝试开启 CALayer.shouldRasterize 属性，但这会把原本离屏渲染的操作转嫁到 CPU 上去。对于只需要圆角的某些场合，也可以用一张已经绘制好的圆角图片覆盖到原本视图上面来模拟相同的视觉效果。最彻底的解决办法，就是把需要显示的图形在后台线程绘制为图片，避免使用圆角、阴影、遮罩等属性。
五、UIView的绘制原理
绘制原理：首先调用[UIView setNeedsDisplay]，此时并没有立刻发生UIView的绘制工作，接下来会调用[UIView.layer setNeedsDisplay]方法，之后会等到当前RunLoop时调用
[CALayer display]，然后进入当前UIView真正的绘制流程。[CALayer display]内部实现中有layer.delegate respondsTo@selector(displayLayer:)这个代理方法判断是否响应displayLayer:方法。若是代理不响应displayLayer:方法就会进入到系统绘制流程；若是代理响应displayLayer:方法就会进入异步绘制入口。如图所示:
- 系统绘制流程
- 异步绘制
实现-[layer.delegate displayLayer]方法就会进入异步绘制。在异步绘制流程的过程当中就需要1.代理负责生成对应的bitmap；2.设置该bitmap作为layer.contents属性的设置。
六、离屏渲染
- On-Screen Rendering
在屏渲染：指的是的渲染操作是在当前用于显示的屏幕缓冲区中进行。
- Off-Screen Rendering
离屏渲染：指的是在当前屏幕缓冲区以外
一个缓冲区进行渲染操作。
1.为什么离屏渲染耗性能？
在进行离屏渲染时，首选需要新开辟一个缓冲区，屏幕渲染会有一个上下文环境的概念，离屏渲染的整个过程需要切换上下文环境，先从当前屏幕切换到离屏，等结束后又要将上下文环境切换回来，这就是离屏渲染消耗性能的原因。
2.为什么有离屏渲染这套机制呢?
因为在设置视图的图层属性圆角，阴影，遮罩的时候，图层属性的混合体被指定为在未预合成之前(下一个VSync信号开始前)不能直接在屏幕中绘制，所以就需要屏幕外渲染。
3.哪些操作会触发离屏渲染?
官方公开的的资料里关于离屏渲染的信息最早是在 2011年的 WWDC，在多个 session 里都提到了尽量避免会触发离屏渲染的效果，包括：
1.mask, shadow, group opacity, edge antialiasing。
2.shouldRasterize（光栅化）： 将图转化为一个个栅格组成的图象。 光栅化特点：每个元素对应帧缓冲区中的一像素。
3.masks（遮罩）是layer的一个属性.
4.shadows（阴影）
5.edge antialiasing（抗锯齿）
6.group opacity（不透明）
7.复杂形状设置圆角等
8.渐变
9.Text（UILabel, CATextLayer, Core Text, etc）
写这篇文章目的主要是当做开发笔记，当中有的内容是在其他文章中看到的，打算分享一下，大家可以参考一下。
