记单词
-
FPS：Frames Per Second每秒传输帧数。60满帧。每16ms刷新一次屏幕。
-
VSync：vertical synchronization垂直同步信号，当一帧画面绘制完成后，电子枪回复到原位，准备画下一帧前，显示器会发出一个垂直同步信号
-
CPU：操作对象
（分内存、调属性、读数据、layer层属性巨耗性能）;计算布局（本质调整frame/bounds/center属性）;文本计算（NSAttributedString、CoreText）;文本渲染(创建CoreText对象、内容异步绘制成Bitmap、默认都是主线程);解码图片(UIImage-> Bitmap->显示。变主线程为异步);绘制图像(异步将内容填充到上下文)。经常的CPU计算量过大就例如当你正在执行一个for循环的时候去滚动TableView这样必须卡顿呀！ -
GPU：CPU将计算好的内容移交给GPU --> 图片纹理+矢量图形 -> 变换+合成+渲染 --> 渲染结果提交到帧缓冲区 --> 显示器发出VSync信号 --> 逐行读取帧缓存区数据 --> 数模传输给显示器显示
离屏渲染负担过重
- Cell视图大量使用view.layer.cornerRadius + masksToBounds的设置，造成卡顿
-
View圆角遮罩->GPU离屏渲染->拖慢了满帧60fp/s绘制->CPU圆角路径贝塞尔曲线UIBezierPath->UIImage天然圆角->直接填充到方的View
-
性能 = GPU效率+CPU效率。
-
离屏渲染真正的消耗 ≠ GPU的图形计算 = 屏幕内外缓冲区来回切换
-
渲染本质 = 每1/60秒从屏幕缓冲区获取一次渲染结果 = CPU计算和GPU渲染之间及时交换数据 = 顺畅绘制(否则掉帧卡顿)
-
CPU圆角路径 -> 主线程计算耗时卡顿UI -> GPU图形遮罩切换缓冲区又耗内存 -> CPU异步计算UIImage圆角路径 -> 后台线程计算主线程统一绘制 -> 完善的线程管理机制+辅助Cache缓存机制->于是facebook开源的 AsyncDisplayKit诞生了
离屏渲染
-
原理：OPENGL单独创建内存->当前屏幕缓冲区以外新开辟一个缓冲区->GPU预合成图层混合体->CPU切换到当前屏幕缓冲区上下文->耗性能
-
触发：shouldRasterize（光栅化保存到bitmap）、masks（遮罩）、shadows（阴影）、edge antialiasing（抗锯齿）、group opacity（不透明）
-
特例：CPU渲染。使用Core Graphics技术对UIImage进行绘制操作。渲染得到的bitmap最后再交由GPU用于显示。
-
工具：Instruments的Core Animation工具
负载均衡
-
GPU天生图形处理，擅长浮点运算矩阵运算，但是屏幕渲染缓冲区切换相当耗性能
-
GPU离屏渲染负担过重，一部分运算交给CPU，减少卡顿
-
离屏渲染的数量比较少，CPU闲着，把运算交给不擅长图形计算的CPU处理弄巧成拙
/**
* 返回一个图片圆形裁剪
*/
+ (UIImage *)imageWithClipImage:(UIImage *)image borderWidth:(CGFloat)borderWidth borderColor:(UIColor *)color{
// 图片的宽度和高度
CGFloat imageWH = image.size.width;
// 设置圆环的宽度
CGFloat border = borderWidth;
// 圆形的宽度和高度
CGFloat ovalWH = imageWH + 2 * border;
// 1.开启上下文
UIGraphicsBeginImageContextWithOptions(CGSizeMake(ovalWH, ovalWH), NO, 0);
// 2.画大圆
UIBezierPath *path = [UIBezierPath bezierPathWithOvalInRect:CGRectMake(0, 0, ovalWH, ovalWH)];
[color set];
[path fill];
// 3.设置裁剪区域
UIBezierPath *clipPath = [UIBezierPath bezierPathWithOvalInRect:CGRectMake(border, border, imageWH, imageWH)];
[clipPath addClip];
// 4.绘制图片
[image drawAtPoint:CGPointMake(border, border)];
// 5.获取图片
UIImage *clipImage = UIGraphicsGetImageFromCurrentImageContext();
// 6.关闭上下文
UIGraphicsEndImageContext();
return clipImage;
}
图片过大过多
-
过大：tableView滚动 -> Cell子视图内容刷新 - > 网络请求图片 - > Image和View大小不一致 - > 设置.contentMode属性图片自由压缩 -> 图片开始transform计算乘以一个变换矩阵 - > CPU计算陡增 -> 解决方法是网络图片先异步处理后显示Or服务器返回预处理过的大小图
-
过多：图片网络库下载图片 -> 异步把图片绘制到CGBitmapContext -> 绑定Bitmap到GPU Texture -> GPU调整渲染Texture纹理 - > GPU将渲染好的Bitmap从内存移植到显存 - > 短时间显示大量图片 - > GPU压力陡增 - > 掉帧
动态高度计算
-
尽量避免临时根据Model数据计算cell高度
-
尽量不使用Cell高度返回函数，Cell高度委托里尽量从缓存里获取高度
-
当然Cell定高优先考虑使用tableView.rowHeight属性
-
缓存一切可缓存！空间换时间
我们获取动态高度的时候，常见逻辑获取Cell高度-->创建Cell-->显示，那么我们通常都需要在计算Cell高度回调方法里先把Cell创建出来，必须先要知道Cell的内容才能决定Cell的高度，通常的做法都是专门谓词创建一个工具Cell，不为别的，就为了把内容复制到Cell的子视图上，如此一来适配Cell的高度，问题在于，在计算Cell高度成功，又会进入创建Cell的回调方法里，正式创建Cell显示出来，那么问题来了，这样本质上我们其实创建了两次Cell，赋值也赋值了两次！我们就会想了，为什么必须先调用Cell高度后调创建Cell的方法呢，如果先创建Cell后获取Cell高度，直接就可以通过Cell的内容布局来显示Cell呀。于是苹果想到了一个方法就是预估Cell高度的方法，就可以实现先创建Cell后返回Cell的真实高度了，如此一来，直接通过创建完成的Cell去获取Cell高度，直接就可以避免多次创建Cell赋值Cell内容的性能消耗了，这对于数量巨大的Cell和内容巨大的性能节省尤其明显。增加Cell盖度估算方法之后的逻辑：获取Cell数量-->数量*估算高度=contentSize--->创建Cell --->布局Cell的内容视图存储真实高度---->直接在返回真实高度里面把数组里面存储的高度返回。原本就是有多少个Cell就调用多少次真实高度计算方法，而且每一次计算高度都相当于创建了一个Cell，多耗性能，现在估算高度，直接相乘，然后真实高度直接从数组里面取。后来想了一下，还是觉得把创建Cell会布局得到的Cell高度存进模型里面，灵活性更高。直接以Model属性的形式存进模型里面。
SubView过多
-
减少subviews的数量
-
UIView很重，创建和销毁都比CALayer要耗费资源，CALayer代替UIView，典型分割线
-
不需要响应事件的视图，优先考虑CALayer
Cell 样式变化控制
-
addSubview、addSublayer、viewWithTag、removeFromSuperview大量的UI绘制会对内存和CPU产生负荷
-
样式变化不大，使用hidden属性进行样式控制
-
Cell 样式变化很大，直接创建新的自定义Cell
优化图片加载方式
1、开辟很多内存将使用过的图片存储在缓存之中
UIImageView *image = [UIImageView imageView:@"1.png"];
2、使用完图片会立即丢弃释放资源。（工程中的大图&&使用次数很少 = 优先考虑）
UIImageView *image = [UIImageView imageWithContentOfFile:@"1.png"];
3、图片的解码：后台线程先把图片绘制到 CGBitmapContext中，然后从Bitmap直接创建图片
一张png格式的图片赋值给UIImageView或CGImageSource之后，依然是png格式，只有在CPU将要把所有视图转变成bitmap位图的时候，才会解码图片，这一步实在主线程完成的，一张图片的数据量极大，如果是一张高清大图，CPU的压力可想而知，因此通常所用的三方库都会先把图片异步从png格式变成位图二进制模式并保存在图片的位图上下文之中，这样GPU在图层合成的时候直接就实现了数据的合成。
图片集中加载卡顿
- 拖拽滚动tableView -> NSRunLoopTrackingMode模式 - > 图片加载添加runLoop为NSDefaultRunLoopMode模式这个前提 -> 实现视图停止滚动才加载图片
// 只在NSDefaultRunLoopMode模式下显示图片
[self.imageView performSelector:@selector(setImage:) withObject:[UIImage imageNamed:@"placeholder"] afterDelay:3.0 inModes:@[NSDefaultRunLoopMode]];
所谓的图片异步绘制其实就是说，下载完图片之后异步将图片从png格式变成bitmap保存在图片位图上下文之中，然后获取imageView的上下文，把图片位图上下文中提取到的bitmap绘制在layer层上。即使异步渲染，图片掉帧依然严重，这就需要从CPU和GPU的配合来看了，GPU专门用来处理bitmap的textTure纹理的地方，通过纹理对输入的bitmap进行变换混合渲染等操作，无论是CPU把bitmap从内存提到显存进而绑定到GPU的纹理上，还是GPU正式处理bitmap的过程，CPU都是轻松的，GPU压力很大，所以一旦大量图片需要加载，GPU就会力不从心，必然就会出现在16ms内不能完成渲染任务的情况，于是掉帧不可避免的出现了，最好的解决办法就是按需加载，只是加载屏幕附近的Cell的图片。
为什么说减少视图的层次也能够提升性能，刚才说过GPU的textture纹理负责bitmap的混合，这个混合就相当于一个压缩的过程，把很多个图层的每一特性都要考虑到，然后决定最后的整体的样子，势必消耗性能巨大，假如说很多图层一开始就合成一张图片，就相当于原本10个图层，现在一个图层。alphe通道颜色的叠加通通不需要再考虑了。GPU 避免了多张 texture 合成和渲染的消耗，更少的 bitmap 也意味着更少的内存占用。
透明度卡顿
-
图层半透明Or背景色clearColor -> 图层blend操作即alpha合成操作 -> GPU渲染 -> 极耗性能
-
设置非透明视图的layer.opaque属性为YES，以避免无用的 Alpha 通道合成
-
尽量使所有的view opaque，包括Cell自身
多个图片异步请求集中到达UI线程
- 集中处理图片加载造成UI卡顿严重
- performSelectorAfterDelay堆积图片加载操作到UI线程空闲的时候执行，副作用：滑动过程中不会加载任何图片
- NSOperationQueue：队列中逐个执行
内容太多未缓存
主线程阻塞
同步变异步
-
布局计算
-
文本排版
-
图片/文本/图形渲染
-
图片解码
-
绘制
性能优化
-
UIKit操作
-
Core Animation操作
按需加载Cell
本质需要明白的的及方法，第一获取当前屏幕的第一个Cell的indexPath,第二获取tableView的content最大y偏移对应的cell的indexPath，然后比较按需加载的前提，是否屏幕当前cell与目标Cell的行差大于设定值，如果大于，则执行按需加载的逻辑，很简单，本质上就是拒绝所有数据的reloadData，只刷新特定行的内容，首要就是找到特定行的indexPath，所以很容易，想获取当前屏幕上所有显示的Cell的indexPath集合，然后判断firstObject第一个indexpath.row是否大于三，然后把屏幕上方的三个indexPath也加入到数组之中。同理依然，一旦判断即使lastObject的indexpath加上3个屏幕下方的indexPath依然不会数组越界，就相当于直接就实现了tableView的数据按需加载。
复用Cell
- 不仅仅节省内存，更可以节省创建Cell的时间
卡顿现象：
1、cell大量subview修改了layer的属性，例如mask、shadow、corRodius
2、cell视图中图片过大过多集中展示的时候，即使使用了三方库的图片异步加载
3、cell中大量的文本宽高结算boundingRectWithSize、CoreText排版绘制成bitmap显示
4、cell界面复杂，子视图巨多
优化性能的举措：
Cell创建：能用layer绝不用View、尽量避免layer属性的修改、少用clearView和alpha通道、drawRect异步绘制化繁为简、CoreText自定义文本控件
Cell使用：固定高预估高行高函数赋值和布局计算分离滚动条跳跃、cell复用内存开销、按需加载Cell本质reload指定的indexPath数组
Cell赋值：布局计算一步到位、图片解码加载、 避免UI绘制操作、图片过多的时候调整runloop
1、layer
2、Image（解码，加载）
3、cellHeight
4、绘制（）
5、渲染（Alpha、)
6、解码（过大、过多）
7、布局计算（Cell高度、Cell创建）
界面卡顿的原因：
CPU：内存、属性、CoreText、Bitmap
GPU：纹理（位图）合成、OpenGL、
FPS：
VSync：交换数据、
网友评论