Intro
UITableView 是个UIScrollView,而UIScrollView需要知道contenSize才能根据bounds,contentInset,contentOffset共同决定是否可以滑动以及滚动条的长度和位置.因此,UITableView需要知道自己需要创建的cell的个数和每个cell的高度,才能得到最终的contentSize.
iOS7
估算机制
在iOS7及iOS7以下的系统中,当tableView要展示时,会调用代理的数据源方法- tableView: heightForRowAtIndexPath:(tableView获取高度默认访问rowHeight属性,实现了这个方法后,rowHeight属性就会失效,所以对于等高的cell来说, rowHeight能够减少许多不必要的计算和方法调用的开销)获得所有row的高度以确定scrollView的contentSize.
- tableView: heightForRowAtIndexPath:适用于不等高cell(没实现该数据源方法就使用rowHeight属性值)
rowHeight适用于等高cell (rowHeight在iOS7中默认为44.f,iOS8为-1.f,即UITableViewAutomaticDimension)
以上两种用于计算cell的高度的方法,都是在tableView将要显示的时候,一次性计算出所有cell.这个时候,如果所展示的cell很多,并且每个cell的高度也很高,那么耗费在计算高度的初始时间将会多很多,所以苹果在iOS7的时候推出了estimatedRowHeight这个属性(与之类似的还有estimatedSectionHeaderHeight,estimatedSectionFooterHeight).
顾名思义,这个属性的意义在于估算.有了这个估算高度,就能确定contenSize啦,但是这个contenSize是个估算值,是通过estimatedRowHeightxcell的个数得到初始的contenSize中的高度,并不是最终的contenSize.实现了这个属性后,tableView就不会一次性计算所有的cell的高度了,只会计算当前屏幕能够显示的cell个数加上几个.滑动时,tableView不停地得到新的cell,调用数据源方法得到高度,更新自己的contenSize,在滑到最后的时候,会得到正确的contenSize,在这过程中,旁边的滚动条会不可避免地"抖动",因为contenSize在不停地更新.因此,在设置estimatedRowHeight时要给出尽量接近cell高度平均值的数值,让"抖动"更小.
// 从打印能看出,contentSize会按照一定的算法进行更新
self.tableView.estimatedRowHeight = 100;
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
NSLog(@"%@",NSStringFromCGSize(tableView.contentSize));
return 300;
}
此外,iOS7中每个cell的高度会被系统自动缓存起来,不会再重复计算了.
高度计算
在iOS7上,设置一个cell的尺寸有两种方式:
- AutoLayout
- Manual-sizing code (即人工手算)
第二种方式比较常见,通常我们通过在- tableView:cellForRowAtIndexPath代理方法中将模型赋值给cell,cell通过模型计算高度,并将高度的计算结果存储在模型身上,然后在tableView: heightForRowAtIndexPath:方法中用cell模型中的高度属性获得高度.
其实第一种方式也很方便,最需要注意的是要设置好完整的约束.系统提供给了我们一个API叫- systemLayoutSizeFittingSize:,可以通过约束计算到cell的高度.
// 设置一个属性,或者是静态的全局变量的cell.因为这个cell是为了计算高度而生,不必每次调用方法都创建.
@property (nonatomic, strong) XXXTableViewCell *prototypeCell;
// 初始化时
self.prototypeCell = (XXXTableViewCell *)[self.tableView dequeueReusableCellWithIdentifier:@"XXXTableViewCell"];
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
// 你或许会想到调用- tableView:cellForRowAtIndexPath方法拿到当前indexPath的cell,然后通过systemLayoutSizeFittingSize方法来计算高度.可是显示tableView之前只有拿到高度才能创建cell实例.如果在这里面调用该方法,会死循环.
XXXTableViewCell *cell = self.prototypeCell;
cell.model = [self.modelArray objectAtIndex:indexPath.row];
CGSize size = [cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
// 为什么要加上一个奇怪的数呢? 因为这里计算的只是cell的contentView的高度,分割线还占1个像素的高度.
return 1.0 / [UIScreen mainScreen].scale + size.height;
}
至于1个像素为什么是这样子计算,请看我的另一篇文章:<iOS中线宽与像素的关系>. 不那么严谨的话,给个1也没什么大问题.
另外需要注意的是,在iOS7下(iOS8没有这个问题),如果布局中有UILabel,并且行数大于0时,需要指定preferredMaxLayoutWidth,这样Label才能知道自己什么时候该换行,然后- systemLayoutSizeFittingSize才能得到正确的高度.另一种方案就是,给cell的contentView添加一个和tableView宽度相同的宽度约束,这样就能在UILabel约束完备的情况下算出UILabel的宽度.(因为contentView宽度的计算需要知道子控件宽度的累加,而UILabel的换行却依赖着contentView的宽度,不换行就不知道UILabel的高度!)
iOS8
高度计算与iOS7不同的地方
iOS8的变化不小,提出了self-sizing cell的概念,认为cell是可以随时被改变高度的.self-sizing cell对于支持Dynamic Type非常有用。你可能没听说过Dynamic Type，但你可能见过系统的“Settings”屏幕：
"Dynamic Type最初由iOS 7引入，允许用户自定义文本大小从而满足app的需要。不过仅有采用Dynamic Type的app才能响应文本的改变，可能只有一小部分第三方应用使用了该功能。
从iOS 8开始，苹果想要鼓励开发者使用Dynamic Type。正如在WWDC session中提到的那样，所有苹果系统级应用都使用了Dynamic Type，并且内置的标签已经有了动态字体。当用户改变文本大小时，这些标签也会改变其大小。
更进一步说，Self Sizing Cell的引入是促进Dynamic Type使用的办法，它可以节省大量写代码调整行高的时间。如果单元格可以自动调整了，那么使用Dynamic Type就很显而易见了。
你只需要从尺寸固定的自定义字体中将字体更改为文本类型（比如标题和内容主体）首选的字体。也就是说当你运行app时，它会适应文本大小的改变。"
对于tableView来说,self-sizing cell带来的变化就是cell的高度不再被缓存起来了.在iOS7中,当tableView滑到最底下时,所有的cell的高度都被经过计算,之后不管怎么滑,都不会进行额外的计算了.而iOS8,不管怎样都会重新计算cell的高度,因此对于性能的影响较大.如果对程序性能要求较高,就需要设计一套缓存机制,将每个cell的高度缓存起来.
自动算高
另外,self-sizing cell的另外一个重要功能就是实现了自动算高,不过需要满足2个条件:
- 使用Autolayout进行布局
- 设置
estimatedRowHeight的值
然后就OK了.
参考文章
http://blog.sunnyxx.com/2015/05/17/cell-height-calculation/
https://github.com/xhzengAIB/iOS8SelfSizingCells
