今天回顾了下这个直播 优化TableView滑动体验，其中前面讲的影响性能的点的印象比较深刻，特此记录。
- 一、较多出现影响性能的点
- 二、额外想到之前看到的点
- 三、对某些的扩展
一、影响性能的点
主线程干了与绘制无关的事情，凡是耗时的都有影响。当然把复杂的事情放到异步线程中去，假如计算时间比较久时，滑动时也可能出现空白的情况，也是很不爽的。
- 1、大量的对象的创建和销毁，过多的时候肯定是有影响，这个无须多说。
- 2、文本的计算多的话，放在主线程肯定就有影响。很多时候我们可以都把那个计算提前算出来。
- 3、服务器下发的图片和实际的尺寸不一致，不得不去手动改尺寸，而重新计算尺寸就是有影响性能的。
- 4、重复去读图片，可以采取缓存的方法去避免重复。
- 5、设置圆角。其实单纯的设置圆角很简单，它不会带来任何性能损耗。
view.layer.cornerRadius = 10.0f;
因为在默认情况下，这个属性只会影响视图的背景颜色和 border。而是我们加上
label.layer.cornerRadius = 10.0f;
label.layer.masksToBounds = true；
也就是说设置 masksToBounds才会导致离屏渲染，从而影响性能的。具体可以看看iOS 高效添加圆角效果实战讲解。
- 6、cell 不复用，这个基本不会用到，我们现在一般都会用的吧。
- 7、图片的透明，尽量不要用，渲染过程相对比会多好几倍
- 8、用AutoLayout 某种程度是会重新计算的，自然是耗时的。
话说，其中有些点上现在是无不可避免的，例如自动布局这块，现在的项目基本都是用的，而且随着硬件的性能越来越好，小性能的缺失是可以忽略的，整体来说掌握一个度吧。
二、额外想到之前看到的点
- iOS 保持界面流畅的技巧 : YY 作者所写，绝对要看。
- UIKit性能调优实战讲解.
- iOS 程序性能优化.
以下是 UIKit性能调优实战讲解-- bestswifter 文章中提到的，在此直接摘抄下。
- 避免图层混合
- 确保控件的opaque属性设置为true，确保backgroundColor和父视图颜色一致且不透明（就是不要设置View 的颜色 为Clear）
- 如无特殊需要，不要设置低于1的alpha值 （alpha = 1.0）
- 确保UIImage没有alpha通道
- 避免临时转换
- 确保图片大小和frame一致，不要在滑动时缩放图片( 和重新计算尺寸有关)
- 确保图片颜色格式被GPU支持，避免劳烦CPU转换 （CPU 要做的事太多了）
- 慎用离屏渲染
绝大多数时候离屏渲染会影响性能 （shouldRasterize（光栅化、masks（遮罩）、shadows（阴影）、edge antialiasing（抗锯齿）、group opacity（不透明）、复杂形状设置圆角等、渐变...）- 重写drawRect方法，设置圆角、阴影、模糊效果，光栅化都会导致离屏渲染
- 设置阴影效果是加上阴影路径
- 滑动时若需要圆角效果，开启光栅化
特别是那个 View 设置成 [UIColor clearColor] 是我常犯的错。
三、单独想想高度相关的优化
对上述其中的一些点还没有切身的感受体验，另外有些是没法避免的，但最近老用都爱文字计算高度这块，就想着如何让涉及到文字计算高度这块的影响降低呢？
- 异步处理？
- 提前处理？
- 缓存 ？
例如像 Cell 和 UILabel 中的计算：
- UITableView 中 Cell 的高度处理
固定高度时，尽量直接用下面这个，而不用那个代理中的高度返回
self.tableView.rowHeight = 44;
另外，高度不固定时可以用到缓存，就是那个UITableView-FDTemplateLayoutCel
#import "UITableView+FDTemplateLayoutCell.h"
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
return [tableView fd_heightForCellWithIdentifier:@"reuse identifer" configuration:^(id cell) {
// Configure this cell with data, same as what you've done in "-tableView:cellForRowAtIndexPath:"
// Like:
// cell.entity = self.feedEntities[indexPath.row];
}];
}
- UILabel 中文字高度的计算
- (CGSize)sizeThatFits:(CGSize)size;
- (CGRect)boundingRectWithSize:(CGSize)size options:(NSStringDrawingOptions)options attributes:(nullable NSDictionary<NSString *, id> *)attributes context:(nullable NSStringDrawingContext *)context
上面相对来说，是我们平常计算高度最常用的方法，前者是 View 本身的，后者是 String 的，但是他们放在什么位置呢，此时我的想法是提前计算好，不要等到真正滑动时再来算，这样相对来说，对性能的影响就减少啦。例如数据返回的时候，顺便立马就将其需要计算的高度，然后等到需要数据更新时，高度也一并返回把高度给计算好。
其实这个地方有个问题，当我们用自动布局的时候，数据更新的时候一般还是会重新计算一下约束的，还是有影响的。不过这也不是计算高度所涉及到的话题咯。
四、另外注意下：性能测试方法
- TimeProfile (最直观的)
- CADisplayLink (fps 值的记录)
目前个人还是只看看 TimeProfile 的，实际的不多，另外之前试用了下JPFPSStatus感觉还是很清晰，但是木有自己公司的项目中试过。
总的说来还是要多实际操作对比的，不断总结，注意一些常用的性能影响原因，反正iOS 保持界面流畅的技巧 绝对要多看看。
