有个疑问：当收发消息比较快时，reloadData能否满足？

[GitterYang]

假如我收到的消息非常快，就像网红直播的时候刷礼物时，收到的消息非常多，还比较快，单纯的用reloadData，这样不会造成主线程卡主么？一个reloadData还没完，或者还未滚动到底部，自己又去reloadData

[zhuozhuo]

不会的，你可以测试下，做个定时器，添加信息。Tableview 有重用机制，而且每次都刷新可见界面的Cell，这里如果要说耗时较多应该是计算Cell高度那里，不过肉眼也不会察觉明显卡顿的。

[GitterYang]

是不是要是高度计算比较慢的话，就会造成一次reload未完成，下次reload就开始了，从而造成卡顿？

[zhuozhuo]

有可能，可以测试下。

[GitterYang]

啥时候能出一篇文章讲一下您的设计就好了，简书已关注您

[zhuozhuo]

这个如果讲的很细致，就涉及很多篇幅内容了。后面如果有时间再把思路和细节分解下，你可以结合Demo和README再看整个架构，理解起来应该就快了。

[dongchong]

对啊，发现如果高度计算的慢，一次reload未完成下次就开始，导致页面卡住。但是如果将高度设为固定值就不会出现问题。那这种情况该如何解决呢？

[zhuozhuo]

我这边做了测试是不卡的，你说的是你推测还是已经遇到卡顿了呢？ 展示效果如下：

[zhuozhuo]

展示效果gif

[dongchong]

这边是因为高度是动态计算的，每个cell的高度是根据文字的多少来计算的高度， 所以在高度计算比较慢但是又没有设置估算高度，就会出现卡顿了。您可以试下

[zhuozhuo]

我做的测试就是动态计算的，高度计算速度虽然耗时相对较长，但是也是ms级别的差距，肉眼根本是难以发现，估算高度也只是对滑动时预定一个高度使滑动时流畅防止不必要的高度计算，和高度动态计算没有关联，给了也要计算，不给也要计算。框架中对高度进行了缓存，就算没给预定高度滑动也是不受影响的，当然你也可以添加一个预定高度，但是得取消新增消息时冒出的效果。 动态计算高度和性能可以看博客中的介绍：Cell动态高度计算,高度自适应加速

取消新增消息时冒出的效果Demo中改动：

[self finishSendingMessageAnimated:YES];

改为

[self finishSendingMessageAnimated:NO];

[GitterYang]

讨论下数据源变化的问题： 1.当在执行tableView:numberOfRowsInSection:这个方法的时候，self.messages.count = 10; 2.还未执行tableView:cellForRowAtIndexPath:的时候，收到的消息，导致self.messages.count > 10; 3.执行tableView:cellForRowAtIndexPath:时，数据源发生变化，其实所取到的indexPath是不会超过10的，这是由步骤1决定的，是吗？所以才不会出现数据源与indexPath不一致的那种异常

[zhuozhuo]

对于这个问题，你需要去单步调试下tableView datasource的加载流程会更清楚的了解。

tableview 是先去询问有多少section，然后多少rows，知道所有的section和row后再初始化cell。

你的数据源改变了，就需要通知tableview刷新或者手动插入row。