ios auto sizing cell遇到的坑(estimatedRowHeight的重要性)

我的原帖地址，这篇文章对原贴进行了修改与一些内容补充

点击打开链接

前段时间对我们原有的一个im应用进行了优化重构。

对于聊天会话界面，涉及到文本、图片、语音、通知等等不同消息(cell)的显示，且不同的消息内容，cell的高度都是不固定的，手动动态计算每个cell的高度感觉实在是太麻烦了，而且感觉效率也不高，一堆计算、分支摆在那里，代码看着也不好维护，于是决定借助ios8 新引入的auto sizing cell特性对该界面进行重写。

整个重写过程进行的很顺利，cell使用相对布局，然后设置estimatedRowHeight，剩下的高度计算就交给系统了，确实省下了相当多的计算与逻辑，代码看起来也简单清晰了很多，达到了我的优化目的。但是，这里出现了一个问题，在数据添加，reloadtable后，调用[_msgTable scrollToRowAtIndexPath:[NSIndexPath indexPathForRow:msgCount-1 inSection:0] atScrollPosition:UITableViewScrollPositionBottom animated:NO];时，在某些情况下，table总是无法滚动到正确的指定位置，对显示效果产生了很大影响。

这个问题困扰了我很久，反复的检查自己的代码逻辑(代码中涉及到了table的ContentInset的调整，我开始一直以为是我这个值设置的有问题造成的错误)，log各种table相关的坐标信息都找不到问题所在，但也摸到了一些规律，最后我开始怀疑是苹果这套机制的问题了，于是我在调用scrollToRowAtIndexPath时，把它放到dispatch_after中，让其在reloaddata后延迟0.1-0.2秒的时间再去滚动(给系统“足够”的时间去绘制table)，惊奇的发现，问题竟然解决了。。。。。。

但是这样解决方式终归不好 1.这个0.1-0.2秒的延时是我实验得出的，没有任何参考依据   2.在某些特定使用场景下，这个很短的延时还是会让用户觉察出轻微的卡顿  3.以后别人维护代码时肯定会对加这个逻辑迷惑不已。

于是我继续尝试搜索，最后发现了也有几个人遇到了和我相同的问题，帖子里面还有人说这是ios的bug(但最后我觉得算不上bug,只能说是这套机制有坑)

http://stackoverflow.com/questions/25686490/ios-8-auto-cell-height-cant-scroll-to-last-row
http://stackoverflow.com/questions/28613995/ios8-uitableview-scrolltorowatindexpath-inaccurate-with-auto-sizing-cells
http://technology.ezeenow.com/posts/5731/iOS_8_Auto_cell_height_Can_t_scroll_to_last_row

总结一下大家的解决方法：
1.用dispatch_after一个很短的时间再去scrollToRowAtIndexPath，竟然和我之前的解决方式一样。。。。。。

2.相对精确设定estimatedRowHeight(有个老外这么解决的)，也是我最终的解决方法

当时学习 auto sizing cells 时，看了网上很多文章教程，对estimatedRowHeight这个值的设置基本都十分草率，过分强调了其便捷性，基本上都只说了这个值必须要有，但随便设，预估一个平均值就好(还强调一下，十分方便......)，但实践证明，这个值的设置简直太重要了，千万不可草率设置。

最终，我重写了estimatedHeightForRowAtIndexPath方法，针对不同的消息类型（cell样式）， 分别去相对精确的去预设他们的高度，最终bug解决了，显示效果也十分理想

/*图片消息的显示是被控制在一定范围内的(cell中已做了样式控制)、语音、撤回消息的显示样式是固定的，这些类的消息高度直接预估一个固定值就够用了文本消息、群通知消息的高度主要依赖于文本内容的多少，要想效果好，还是要计算一下文本主体高度的（虽然还是有高度的计算工作，但在auto sizing机制下，仅需计算出对高度影响最大的文本的高度即可）*/- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {        JHMessageObject *msg = [_msgAry objectAtIndex:[indexPath row]];        switch (msg.msgType) {                    case IMTypePlain:            return [TextMsgCell calculateTextHeight:msg.msgContent];                    case IMTypeImage:            return 160;                    case IMTypeVoice:            return 65;                    case IMTypeRoomNof:            return [RoomNofCell calculateTextHeight:msg.msgContent];                    case IMTypeRevoke:            return 65;                    default:            return 80;    }    return 80;}

可以说estimatedRowHeight的正确设置，不仅影响了table的绘制效率，同时还能避免出现很多莫名其妙的诡异问题，希望后面的同学在使用中多加注意