前段时间对我们原有的一个im应用进行了优化重构。
对于聊天会话界面，涉及到文本、图片、语音、通知等等不同消息(cell)的显示，且不同的消息内容，cell的高度都是不固定的，手动动态计算每个cell的高度感觉实在是太麻烦了，而且感觉效率也不高，一堆计算、分支摆在那里，代码看着也不好维护，于是决定借助ios8 新引入的auto sizing cell特性对该界面进行重写。
整个重写过程进行的很顺利，cell使用相对布局，然后设置estimatedRowHeight，剩下的高度计算就交给系统了，确实省下了相当多的计算与逻辑，代码看起来也简单清晰了很多，达到了我的优化目的。但是，这里出现了一个问题，在数据添加，reloadtable后，调用[Table scrollToRowAtIndexPath:[NSIndexPath indexPathForRow:row 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,只能说是这套机制有坑)
stackoverflow.com/questions/25686490/ios-8-auto-cell-height-cant-scroll-to-last-row
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的设置基本都十分草率，过分强调了其便捷性，基本上都只说了这个值必须要有，而且基本都是告诉你针对不同cell，统一预估个大概的平均值就行(还强调一下，十分方便......)，但实践证明，这个值的设置简直太重要了，千万不可草率设置。
最终
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
JHMessageObject *msg = [_msgAry objectAtIndex:[indexPath row]];
switch (msg.msgType) {
case IMTypePlain:
return 80;
case IMTypeImage:
return 160;
case IMTypeVoice:
return 65;
case IMTypeRoomNof:
return 65;
case IMTypeRevoke:
return 65;
default:
return 80;
}
return 80;
}
我重写了estimatedHeightForRowAtIndexPath方法，针对不同的消息类型（cell样式）， 分别去相对精确的去预设他们的高度，最终bug解决了，显示效果也十分理想
可以说estimatedRowHeight的正确设置，不仅影响了table的绘制效率，同时还能避免出现很多莫名其妙的诡异问题，希望后面的同学在使用中多加注意
