最近项目在测试过程中总是莫名其妙的crash，但是测试同事并不能提供稳定的复现途径，实在是头疼。有必要记录下来供以后参考。
拿过测试机，xcode查看了一下release的log，最后定位到了是由于TableView的cellForRow方法返回了一个“nil”导致了crash，这样的crash还是比较常见的，因为业务代码的逻辑是根据model找到对应的cell然后返回cell，当找不到对应cell的时候会返回nil，所以推断应该是数据源在reload过程中被改变了。
我们都知道TableView的reload方法是一个异步的方法，numberOfSection、numberOfRow方法是同步调用而cellForRow方法是在tableVIew的layoutSubviews方法调用之后才会调用的，在真正布局渲染cell的时候很有可能数据源变更了。
沿着上面的思路一步步的调试着代码，由于业务代码比较简单，网络请求回来后然后组装数据，然后reload一下tableView，并没有特殊的逻辑会引起数据不一致的情况。。。找了好久也没有找到原因，好苦恼啊。。。
。。。。。。此处省略一万字。。。。。。
根本原因
业务页面是可以下拉刷新的，所以问题也就是处在了下拉刷新的时候，而且是5s的手机，首次进页面请求回来渲染好页面后，最后一个cell正好在屏幕的最下面，当下拉的时候cell被回收，这个时候下拉到了刷新的临界点出发了请求数据，此时正好也松开手，页面回弹，cell又立即会出现，此时cell会立即调用heightForCell方法，由于数据源还在所以高度是存在的，此时异步的网络请求回来后改了数据，在还没有调用reload之前先调用了cellForRow方法，然而此时的cellForRow对应的数据源依据没有了，从而导致了crash。
总结
上面的主要原因是页面的更新和数据源更新同时进行了，而且似乎时间点也掐的也很巧。
解决方案：
1. 推迟网络回调后数据源的更新，我们发现因为scroll还在收起的过程中，此时的runloop是运行在UITracking的mode下的，如果我们把数据源的更新放在NSDefault的mode下，就可以达到延迟执行数据源更新的操作了，经过测试也是没有问题的，但是这个改动有一个问题就是，所有的对于数据源的修改都要封装一下，万一后来维护这个代码的人不知道这个，就容易再次引起crash。
2. 无论数据源如何都返回一个0.01高度的空cell，因为由于回弹而调用的cellForRow很快也会被由于tableview的reload方法重新布局，所以这样比较稳妥，而且易于维护，可以更彻底的预防调这类的crash。
