UITableView中estimatedHeightForRowAtIndexPath与heightForRowAtIndexPath的区别？

嘿，这俩方法的差异主要体现在计算时机和性能影响上，我给你掰扯明白：

1. tableView:heightForRowAtIndexPath: #

这个方法返回的是精确的行高——UITableView在初始化列表或者数据源更新时，会提前调用这个方法计算所有行的高度，然后根据这些高度算出整个列表的总滚动范围。

• 优点：滚动时不会出现行高跳动，因为所有行高都是提前确定好的
• 缺点：如果你的列表有几百上千行，这个提前计算所有行高的操作会让列表加载变慢，甚至出现卡顿，因为每一行都要走一遍这个方法的计算逻辑

代码示例：

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { 
    return 100; 
}

2. tableView:estimatedHeightForRowAtIndexPath: #

这个方法返回的是预估的行高——UITableView不会提前计算所有行的真实高度，而是先用这个预估高度快速算出列表的大致滚动范围，当用户滚动到某一行附近时，再去计算这一行的真实高度（如果你同时实现了上面的精确行高方法，就用那个值；如果没实现，就靠自动布局来计算真实高度）。

• 优点：极大提升长列表的加载性能，因为不用一次性计算所有行高，只在需要的时候算
• 缺点：如果预估高度和真实高度差距太大，滚动时可能会出现轻微的滚动条跳动或者行高调整的视觉变化

代码示例：

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath { 
    return 100; 
}

小补充 #

如果两个方法你都实现了：estimatedHeightForRowAtIndexPath:负责给列表一个初始的滚动范围参考，heightForRowAtIndexPath:提供每一行的真实高度，这种搭配是长列表的最优解——既保证性能，又不会有行高跳动的问题。

内容的提问来源于stack exchange，提问作者Chirag Kothiya