来自 电脑系统 2019-09-14 02:58 的文章
当前位置: 金沙澳门官网网址 > 电脑系统 > 正文

UITableViewCell的估算机制与高度计算

估算机制

在iOS7及iOS7以下的系统中,当tableView要展示时,会调用代理的数据源方法- tableView: heightForRowAtIndexPath:(tableView获取高度默认访问rowHeight属性,实现了这个方法后,rowHeight属性就会失效,所以对于等高的cell来说, rowHeight能够减少许多不必要的计算和方法调用的开销)金沙澳门官网网址 ,获得所有row的高度以确定scrollViewcontentSize.

  • - 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;- tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{ NSLog(@"%@",NSStringFromCGSize(tableView.contentSize)); return 300;}

此外,iOS7中每个cell的高度会被系统自动缓存起来,不会再重复计算了.

1、设置好布局约束条件

UITableView 是个UIScrollView,而UIScrollView需要知道contenSize才能根据bounds,contentInset,contentOffset共同决定是否可以滑动以及滚动条的长度和位置.因此,UITableView需要知道自己需要创建的cell的个数和每个cell的高度,才能得到最终的contentSize.

在UITableViewCell子类中,添加布局约束,使得cell子视图的边缘固定(pin)到cell的contentView的边缘(最重要的是要有顶部和底部的边距约束条件)。注意:不要将子视图的边距约束固定到cell本身上了,只能固定到cell的contentView上! 确保每个子视图垂直方向上的内容压缩阻力(compression resistance)和吸附性约束(hugging constraints)没有被你添加的更高优先级的约束条件覆盖,让这些子视图的固有内容尺寸(intrinsic content size)来驱动contentView的高度。(没看懂?点这里。)

高度计算与iOS7不同的地方

iOS8的变化不小,提出了self-sizing cell的概念,认为cell是可以随时被改变高度的.self-sizing cell对于支持Dynamic Type非常有用。你可能没听说过Dynamic Type,但你可能见过系统的“Settings”屏幕:

金沙澳门官网网址 1

"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个条件:

  1. 使用Autolayout进行布局
  2. 设置estimatedRowHeight的值

然后就OK了.

例如,要在一个cell中显示一条email消息,可能会有4种独特的布局:第一种,只有主题的消息;第二种,带主题和正文的消息;第三种,带主题和图片附件的消息;第四种,带主题、正文和图片附件的消息。每一种布局都需要完全不同的布局约束才能实现。因此,一旦cell被初始化并且布局约束被加到其中任意一种类型的cell上后,cell应当得到一个唯一的重用标示符来指定该cell类型。这就意味着,当你dequeue重用一个cell的时候,该类型cell的布局约束已经添加好了,可以直接使用。

高度计算

在iOS7上,设置一个cell的尺寸有两种方式:

  1. AutoLayout
  2. 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"];- 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的高度!)

  1. 启用估算行高
  1. 缓存行高(如果需要)

然后,强制cell立即更新子视图的布局,再用cell的contentView调用systemLayoutSizeFittingSize:方法计算出cell所需的高度是多少。使用UILayoutFittingCompressedSize参数可以得到适合cell中所有内容所需的最小尺寸。然后其高度就可以作为tableView:heightForRowAtIndexPath:方法的返回值

  1. 完成一个完整的布局过程 & 计算cell的高度

如果上面提到的你都做了,但是tableView:heightForRowAtIndexPath:的性能仍然慢的不可接受。非常不幸,你需要给行高做一些缓存(这是苹果的工程师们给出的改进建议)。大体的思路是,第一次计算时让自动布局引擎解析约束条件,然后将计算出的行高缓存起来,以后所有对该cell的高度的请求都返回缓存值。当然,关键还要确保任何会导致cell高度变化的情况发生时你都清除了缓存的行高——这通常发生在cell的内容变化时或其他重大事件发生时(比如用户调节了动态类型文本大小(Dynamic Type text size)的滑动条)。

核心概念

这样做就为tableView上还没有显示在屏幕上的cell提供了一个临时的估算的行高。然后,当cell即将滚入屏幕范围内的时候,会计算出实际的高度。为了确定每一行的实际高度,tableView会自动让每个cell基于其contentView的已知固定宽度(tableView的宽度,减去其他额外的,像section index或accessoryView这些宽度)和被加到contentView及其子视图上的自动布局约束规则来计算contentView的高度。一旦真正的行高被计算出来后,旧的估算的行高会被更新为这个真实的行高(并且其他任何需要对tableView的contentSize或contentOffset的更改都自动替你完成了)。

本文由金沙澳门官网网址发布于电脑系统,转载请注明出处:UITableViewCell的估算机制与高度计算

关键词: