最近项目在升级RN版本，我们准备优化一下ListView，在优化过程中，发现了rowHasChanged一个大坑，在此记录一下。
以下结果都是在RN 0.47.2版本上跑出来的。
这里以一个100行列表为例，之前的小伙伴是这么做的：
在官方的文档中，有提到这样一段话：
我们在用ListView的时候，需要特别注意rowHasChanged配置。
上面的代码，ListView是这么干的：
1、首次渲染initialListSize行
2、判断是否满足scrollRenderAheadDistance，如果不满足下一帧渲染initialListSize+pageSize行，同时上一次渲染过的行，shouldUpdate为false，而本次新渲染的cell则需要判断是否dirty
在iphone 5模拟器上，实际结果如下：
考虑极端场景，假设我们现在处于列表底部（第100行位置），然后收到了一条新订单，数据prepend到datasource头部，此时ListView会这么干：
1、设置_prevRenderedRowsCount为0，curRenderedRowsCount为100
2、根据rowHasChanged判断是否dirty，在以上代码的情况下，它会一直返回true，标记为dirty
3、先渲染了前100行，shouldUpdate都为true（渲染数量由curRenderedRowsCount决定）
4、然后再渲染全部101行，此时前100行shouldUpdate都为false，最后一行shouldUpdate为true（再次渲染由scrollRenderAheadDistance决定）
最终结果如下：
现在大家可以看出问题所在了吗？
第3步，渲染前100行时，因为shouldUpdate为true，每一行都要进行递归dom diff，然后更新，而实际上，我们仅仅是收到一条新订单，问题似乎比较严重。。。
以下是有新订单推送过来时，xcode Memory的走势图：
可以看到，内存一下子飙涨了，这一瞬间显然是发生了大量计算。。。
同理，当我们删除列表中的订单时，也存在同样的问题。。。
问题的根源其实主要有两个：
首先，rowHashChanged用得不太对，数组已经重排了，再去对比它们，显然结果是不一样的，一直返回true。
其次，我们的key设置得不太科学，我们使用了默认的key（sectionId ＋ rowId），因为订单是按时间倒序的，新订单是prepend到datasource前面的，而由于key是index，dom diff算法通过key找到了交错的对象，再加上shouldUpdate都为true，所以基本列表中每一行都需要进行递归dom diff。。。
我们需要改造一下代码：
1、修改一下ListViewDataSource，传入getRowData方法：
2、dataSource需要保持与cloneWithRows返回值同步，内部计算dirtyRows时，才能使用上一份数据进行对比：
3、修改一下cloneWithRows的用法，传入自定义的rowIdentities：
做了上面三件事之后，新订单推送过来时，ListView会有什么不同呢？
可以看到现在key是以我们传入的identities为主了，然后shouldUpdate除了新订单是true之外，其他全是false。
现在react dom diff时，可以通过key找到了正确的对象：
然后再加上只有新订单shouldUpdate是true，而旧订单shouldUpdate全部是false，react dom diff过程就大大减少了。。。
现在看看新订单来临时，内存有什么变化：
可以看到，内存基本不会有什么变化了，只是翻起了一点小浪花，这才是合理的状态。。。
这个问题其实在React官网上也有提及：
ListView的datasource如果发生了重排，要特别注意不能用index作为key，特别是这种数据prepend到datasource中的情况。。。
ListView在RN新版中已经废弃了，但是还处于可用状态，还在用ListView的童鞋们注意别踩坑了，当然用FlatList的童鞋们也同样要注意该问题。。。
