UITableView 复用机制
为什么要用重用机制?
当UITableView滚动时,如果不用重用机制,会重复初始化原来已经有初始化过的cell,因此用重用机制会节省性能,避免出现卡顿现象
重用机制的原理
重用机制主要用到了一个可变数组visiableCells和一个可变的字典类型reusableTableCells,其中visiableCells用来存储当前UITableView显示的cell,reusableTableCells用来存储已经用'identify'缓存的cell。当UITableView滚动的时候,会先在reusableTableCells中根据identify找是否有有已经缓存的cell,如果有直接用,没有再去初始化。
数据源同步问题
- 并发访问 数据拷贝
- 并发即多个线程都可以执行同一段时间,不需要相互等待,主线程与用户互动,子线程做所需要的网络数据请求、数据解析及预排版等
- 主线程事先拷贝一份数据给子线程做网络请求、数据解析、预排版等,如果主线程有相关操作,记录操作,在子线程完成相关操作后将这条操作,与子线程的数据进行同步,再回到主线程刷新界面
- 缺点:需要拷贝大量数据,耗内存
2.串行访问
- 创建一个GCD串行队列,主线程的操作需要等待子线程操作完成
- 缺点:需要等待子线程完成,可能会耗时较长
UIView的事件传递以及视图响应的机制和流程
UIView以及CALayer的关系和区别
- 关系:
UIView的内部包含CALayer层。创建UIView时,会自动创建一个CALyer层的对象,通过UIView的layer属性可以访问到。UIView需要显示时,会调用drawRect方法进行绘制,并将所有内容绘制在自己的layer层。也就是CALayer层才有显示功能。 - 区别:
UIView负责提供内容,以及负责处理触摸等事件,参与响应链
CALayer负责显示内容contents
事件传递与视图响应链
-
事件的分发与传递
当iOS程序中发生触摸事件,系统会将事件加入到UIApplication管理的一个任务队列
UIApplication将处于任务队列最前端的事件向下分发。即UIWindow ->UIView
3.UIView首先看自己是否能处理事件,触摸点是否在自己身上。如果能,那么继续寻找子视图。
5.遍历子控件,重复以上两步
6.如果没有找到,那么自己就是事件处理者
7.如果自己不能处理,那么不做任何处理
其中不接受处理的事件情况如下三种:
- alpha <0.01
- userInteractionEnabled = NO
- hidden = YES.
如果父视图不接受事件处理,则子视图也不能接收。事件只要触摸就会产生,关键在于是否有合适的View处理接收事件 如何寻找最合适的View呢?以下两个方法
// 此方法返回的View是本次点击事件需要的最佳View
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
// 判断一个点是否落在范围内
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
事件传递给窗口或控件的后,就调用hitTest:withEvent:方法寻找更合适的view,如果子控件是合适的view,则在子控件再调用hitTest:withEvent:直到找到最合适的为止
- 响应者链
响应者链的传递方法是事件传递的反方法,如果所有的响应者都不处理,则事件被丢弃
图像显示原理(为了关于UI卡顿掉帧原因做的铺垫 了解)
CPU GPU通过总线连接 通过CPU进行绘图,将位图经由总线在合适的时机给GPU,GPU做位图的涂层渲染和纹理合成,再放到帧缓冲区域(Frame Buffer)中, 由视频控制器根据VSync在帧缓冲区域中提取屏幕显示内容,显示到手机屏幕中
CPU
需要做Layout布局(UI布局),Display显示(绘制 drawRect),Prepare准备工作(图片编解码),Commit提交(提交位图)
GPU
需要做 顶点着色 图源装配 光栅化 片段着色 片段处理 再放到帧缓冲区域(Frame Buffer)
UI卡顿 掉帧的原因 以及优化方案
UI卡顿 掉帧的原因
保持流畅的UI交互,FPS应该保持在60,即16.7ms刷新一次页面,如果CPU处理时间过长,导致VSync信号到来之前CPU和GPU无法完成下一帧画面的合成,就会造成肉眼可见的卡顿
tableView的滑动优化方案
- CPU
对象创建、调整、销毁
预排版(布局计算、文本计算)
预渲染(文本异步绘制、图片编解码)
-GPU
纹理渲染(减少不必要的离屏渲染)
视图混合(减轻视图层级的复杂性)
如何具体优化呢?
- 官方在iOS9.0后对UIImageView设置圆角进行优化,但是设置阴影依然会触发离屏渲染
- 圆角优化
1.使用贝塞尔曲线UIBezierPath和Core Graphics框架画出一个圆角
2.使用CAShapeLayer和UIBezierPath设置圆角 - shadow优化
通过设置shadowPath来优化性能
其他优化方案:
- 尽量使用不包含透明(alpha)通道的图片资源
- 尽量设置layer的大小值为整形值
- 使用一张中间透明图片蒙上去
- 如果是本地图:直接让美工把图片切成圆角进行显示
- 上传图片进行显示,可以让服务端处理圆角
- 利用UIBezierPath(CoreGraphics框架)画出来圆角图片
Core Animation工具检测离屏渲染
对于离屏渲染的检测,苹果为我们提供了一个测试工具Core Animation。可以在Xcode->Open Develeper Tools->Instruments中找到
UIView的绘制原理
离屏渲染��
离屏渲染
- 在屏渲染 On-screen,Rendering 当前屏幕渲染
GPU的渲染操作在当前用于显示的屏幕缓冲区中进行 - 离屏渲染 Off-Screen,GPU当前屏幕缓冲区之外新开辟一个缓冲区来进行渲染操作
什么是离屏渲染:
当指定了视图的某些图层属性标记了不能在当前 的屏幕缓冲区中直接显示时,则需要开辟一块新的缓冲区进行渲染操作,即离屏渲染,需要多次切换上下文
何时会触发离屏渲染?
- 圆角 layer.masksToBounds = YES 和layer.cornerRadius 同时使用
- 蒙版 layer.mask
- 透明度 layer.allowsGroupOpacity = YES 和 layer.opacity < 1.0
- 阴影 layer.shadow
- 光栅化 layer.shouldRasterize=true
为什么要避免离屏渲染?
触发离屏渲染会增加GPU的工作量,就会进一步增加CPU和GPU的工作耗时超出16.7ms,可能就会导致UI的卡顿和掉帧,所以要尽量避免
离屏渲染会创建新的渲染缓冲区,以及多次的上下文切换,将多通道的渲染结果做最终的合成,会造成额外的内存开销
2019-11-12