问题

1. 低端机器下，如果多个消息列表，复用一个实例，会出现很多问题。比如，在会话1滚动没有停下的时候，切到会话2，会话2的数据不会立即刷新，同时继续滚动一段距离，最后切换到会话2的消息
2. 把高度计算，收到chat模块内部来，按需计算，渲染？而不是在外面一下子计算好

性能

渲染时机

1. state变更的时候，整个列表渲染
2. 滚动的时候，group以updateTimeInterval为最高刷新频率，局部渲染

快速滑动间的刷新

1. 控制渲染频率
2. 减少无效的渲染

• 渲染在视口内的group

FlatList/VirtualList

超长列表的优化 对于列表的优化，主要集中在两个方面，一个是内存消耗，一个用户响应，用户响应又可以分为：滚动是否流畅，对点击等操作响应速度是否迅速。我们先来看看新的列表组件VirtualizedList都给我们带了哪些改进：

PureComponent: 减少不必要的渲染，如果props属性不变，它就不会重绘。 这里需要我们确保在更新props后不是===，否则UI可能无法更新更新。

限定渲染窗口： 通过维护有效项目的有限渲染窗口并把渲染窗口之外的所有元素替换为空（Blank），大大提高了大型列表的内存消耗和性能。

低优先级渲染窗口以外的区域：窗口适应滚动行为，如果项目远离可见区域，则项目将以低优先级（在任何运行的交互之后）逐渐呈现，否则为了最小化查看空格的可能性。。

异步渲染：内容将异步地渲染在屏幕外。 这意味着可能滚动会比填充率更快，看到空白的内容。

可以看到，新的列表组件在内存消耗上做出了改进，滚动的流畅度得到了较大的提升，但是，对于用户点击等操作的响应的速度应该算是没有带来利好，反而在滚动中会出现白屏。

从截图中可以看到，FlatList在流畅度的提升还是很明显的，不过，在急速滚动的情况下，中间会出现白屏，这对于用户体验上来说很不友好。这里，我们可以参考VirtualizedList提供的属性来做优化。

windowSize： 限定绘制的最大数目，默认为21。

maxToRenderPerBatch：一次绘制的最大数目。

updateCellsBatchingPeriod：更新绘制的间隔时间。

removeClippedSubviews：移除看不见的subview，目前还有bug，可酌情使用。

initialNumToRender：首次绘制的数目。

getItemLayout：可以用来帮助我们跳过高度和位置的重新运算，当我们的每一个Item高度一致时，设置这个属性可以极大的提高渲染效率。

getItemLayout={(data, index) => ( {length: ITEM_HEIGHT, offset: (ITEM_HEIGHT+ SEPARATOR_HEIGHT) * index, index} )}