关于对UITableViewCell的优化,行高的计算是一项很重要的优化项,处理不好就会让你的APP占用大量内存,界面卡出翔,下面介绍一下关于行高计算的优化
rowHeight
对于固定行高的cell,调用这个方法无意识最简单有效的
heightForRowAtIndexPath方法
这个方法适用于具有多种 cell 高度的 UITableView,但是有一个问题就是你的tableView有多少个cell他就会调用多少次方法来计算cell的高度,就是说你有一百行 cell，这个方法就要走100次来计算cell的高度来获取contentSize的值,这个无疑是占内存的大杀器,所以我们在计算cell的高度的时候,尽量不要调用这个代理方法,ios7之前,对于动态cell的高度计算,可以先给定一个高度(rowHeight方法放回高度让其计算contentSize),然后通过cell里面的空间的约束和抽取frame模型,在模型里计算,来返回cell最下面的控件的maxY,maxY的值直接赋值给heightForRowAtIndexPath,让其尽可能少的计算在这个方法中进行,减轻CPU的计算量
estimatedRowHeight
ios7之后,出现了这个属性,设置预估行高,设置估算高度后，contentSize.height 根据“cell估算值 x cell个数”计算，这就导致滚动条的大小处于不稳定的状态，contentSize 会随着滚动从估算高度慢慢替换成真实高度，肉眼可见滚动条突然变化甚至“跳跃”。
ios8之后,出现了 UITableViewAutomaticDimension自动计算行高的属性,结合预估行高和自动计算行高很好的解决了行高的性能问题,在平时的开发中足够可以解决cell的行高性能问题,现在iOS9了都,马上ios10发布,很多公司的APP只向下支持两个版本,所有这个自动计算行高基本能满足我们的开发需求
第三方框架
最近发现了一个第三方框架,优化关于行高计算的性能问题,在这里推荐给大家,这里就不做过多解释,感兴趣的可以克隆下来研究研究
github地址:https://github.com/forkingdog/UITableView-FDTemplateLayoutCell
