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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhaochen_009/article/details/53395598

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

点击打开链接


前段时间对我们原有的一个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的绘制效率,同时还能避免出现很多莫名其妙的诡异问题,希望后面的同学在使用中多加注意 


阅读更多
换一批

没有更多推荐了,返回首页