《iOS UITableView 优化》直播笔记

今天回顾了下这个直播优化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 某种程度是会重新计算的，自然是耗时的。

话说，其中有些点上现在是无不可避免的，例如自动布局这块，现在的项目基本都是用的，而且随着硬件的性能越来越好，小性能的缺失是可以忽略的，整体来说掌握一个度吧。

二、额外想到之前看到的点

以下是 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]; 
      }];
}

源自：优化UITableViewCell高度计算的那些事

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 保持界面流畅的技巧绝对要多看看。

《iOS UITableView 优化》 直播笔记

一、影响性能的点

二、额外想到之前看到的点

三、单独想想高度相关的优化

四、另外注意下：性能测试方法

推荐阅读更多精彩内容

《iOS UITableView 优化》直播笔记