UITableView相关
- 重用机制 - 复用池 - 复用池原理
//通过dequeueReusableCellWithIdentifier获取cell就能得到UITableView的重用机制的支持
cell = [tableView dequeueReusableCellWithIdentifier:identifier];
-
多线程下修改或访问数据源的同步解决方案
- 并发访问，数据拷贝
主线程直接访问数据，并对数据操作进行记录(如删除)；
异步线程获取数据源的拷贝，进行数据操作，在返回主线程时，将主线程对操作的记录(如删除)对再进行一遍。
(记录数据删除；需要做数据源拷贝，对内存会有一定开销)
- 串行访问(GCD 串行队列)
将数据操作都添加到GCD的串行队列中，由串行队列保证数据的一致性
(由于主线程数据源操作也加入了串行队列，如果之前有较耗时的操作时，可能主线程的数据操作(如删除)会有一定的延迟)
UI图像显示原理
- UIView与CALayer的关系
UIView 的显示部分是由
view.layer(CALayer)决定的，backgroundColor是对layer的同名属性的封装
UIView为其提供内容，以及负责处理触摸等事件，参与响应链
CALayer负责显示内容contents
在设计原则上，体现了单一职责原则 ，体现了UIView与CALayer在职责上的分工
UILabel绘制和渲染流程绘制和渲染的流程 (参考iOS绘制和渲染与iOS渲染)
- UI的布局(Layout)如：为视图/图层准备层级关系，以及设置图层属性(位置，背景色，边框等等)的阶段。(UI布局、文本计算);
- 显示(Display)如：图层的寄宿图片被绘制的阶段。绘制涉及到-drawRect:和-drawLayer:inContext:方法的调用；
- 一些其他的准备工作(Prepare)如： Image decoding, Image conversion(如果图片类型不是GPU所支持的，需要对图片进行转换)。
- 提交GPU(Commit)：Core Animation打包所有的图层和动画，然后通过IPC(进程内通信)发送到渲染服务(render server，一个单独管理动画和图层组合的一个系统进程)。这个步骤是递归的，所以如果layer tree如果比较复杂此步骤代价比较高
上面4个步骤发生在自己的应用程序内部，动画显示到屏幕之前还有2个步骤的工作：
- 对所有图层属性计算中间值，设置OpenGL几何形状来执行渲染。
- 在屏幕上渲染可见的三角形。
前5个阶段都在软件层面处理(通过CPU)，只有最后一个阶段被GPU执行。6个阶段中只有布局和显示两个阶段是可以被我们控制的，Core Animation框架处理剩下的事务。
GPU(OpenGL)渲染管线()
- 定点着色、图元装配、光栅化、片段着色、片段处理
- 做完上诉操作后，将像素点提交到对应的帧缓存区当中(FrameBuffer)
- 最后由视频控制器在VSync信号到来之前去帧缓冲区中提取要显示的内容
- 卡顿&掉帧
如果屏幕刷新率为60，那么将意味着需要在16.7ms(1000ms/60)内需要将下一帧需要显示的内容准备好，由于垂直同步的机制，如果在一个 HSync(VSync) 时间内，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变。这就是界面卡顿的原因。
UI卡顿、掉帧原理UIView的绘制原理&异步绘制
UIView的绘制原理
UIView调用setNeedsDisplay方法其实是调用layer属性的同名方法，这时layer并不会立刻调用display方法，而是要等到当前runloop即将结束的时候调用display，进入到绘制流程。在UIView中layer.delegate就是UIView本身，UIView并没有实现displayLayer:方法，所以进入系统的绘制流程，我们可以通过实现 displayLayer: 方法来进行异步绘制。
系统绘制流程
系统绘制流程
CALayer会在内部创建一个backing store(CGContextRef)();
判断layer是否有代理;
如果有代理:调用delegete的drawLayer:inContext, 然后在合适的时机回调代理, 在[UIView drawRect]中做一些绘制工作;
如果没有代理:调用layer的drawInContext方法；
最后无论是哪个分支最后都把 backing store 的 bitmap 位图提交到 GPU，也就是将生成的 bitmap 位图赋值给 layer.content 属性。异步绘制流程
> 通过在自定义view的中实现CALayer的delegate方法 displayLayer: 来使用异步绘制，这时整个界面的显示内容都需要我们来绘制了(如UILabel中的文字也需要我们来绘制出来)；
> 异步绘制过程中代理负责生成对应的位图(bitmap)；
> 将bitmap赋值给layer.content属性;离屏渲染问题(iOS-离屏渲染详解, iOS 关于离屏渲染的理解 以及解决方案)
GPU屏幕渲染有两种方式:
（1）On-Screen Rendering (当前屏幕渲染) ：指的是GPU的渲染操作是在当前用于显示的屏幕缓冲区进行。
（2）Off-Screen Rendering (离屏渲染)：指的是在GPU在当前屏幕缓冲区以外开辟一个缓冲区进行渲染操作。
相比于当前屏幕渲染，离屏渲染的代价是很高的，主要体现在两个方面：
（1）创建新缓冲区(要想进行离屏渲染，首先要创建一个新的缓冲区)。
（2）上下文切换何时会触发
- 设置圆角layer.cornerRadius(并且maskToBounds=YES时)
- 为图层设置遮罩（layer.mask）
- 为图层设置阴影（layer.shadow *）
- 光栅化（shouldRasterize，将图转化为一个个栅格组成的图象。 光栅化特点：每个元素对应帧缓冲区中的一像素）
为何要避免离屏渲染
- 离屏渲染需要创建新缓冲区，并且整个过程需要多次切换上下文环境：先是从当前屏幕（On-Screen）切换到离屏（Off-Screen），等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上又需要将上下文环境从离屏切换到当前屏幕。而上下文环境的切换是要付出较大的消耗。
- 离屏渲染发生在GPU上，触发了OpenGL上的多通道渲染管线，产生了额外开销，加大了GPU的工作量，为避免CPU和GPU工作时间超过了一个刷新时(HSync、HSync)，从而造成丢帧，所以应该尽量避免离屏渲染
UIScrollView、UITableView滑动优化方案
减缓CPU的压力 让其有更多时间来处理用户交互
- 对象的创建、调整、销毁操作放到子线程去做(可以节省一部分CPU时间)；
- 预拍版(UI的布局计算、文本计算放到子线程去做)
- 预渲染(文本等异步绘制、图片编解码等)
减缓GPU压力
- 纹理渲染(离屏渲染如圆角、maskToBounds等会加大GPU的压力，可以使用CPU的异步绘制机制来减少离屏渲染)
- 视图混合(视图层级复杂层层叠加，GPU需要做视图混合，并且需要消耗大量的计算量来计算每一个像素值，可以通过减轻视图层级复杂性或者通过CPU的异步绘制来让位图层级层级减少)
事件传递机制与视图响应链
事件传递机制>
//最终那个视图响应事件 - (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event; //判断点是否在当前视图范围 - (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;hitTest: withEvent:方法内部流程
hitTest: withEvent:方法内部实现点击屏幕的事件传递流程
事件传递流程
视图事件响应
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event; - (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event; - (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;点击在View C2上时，如果C2不响应事件，向上找父视图B2，如果B2不响应，继续向上找父视图A，如果A不响应事件，将继续沿着响应链传递如UIWindow，最后直到UIApplocation，如果最后仍然没有视图来处理事件，则这个事件就会被忽略
视图事件响应
