这个问题在我做火柴盒用户crash分析的时候，曾经困扰我挺久的，需要较大的用户量，才能发现这个crash，解决之后，也不知道怎么叙述出来，恰好最近好几个人都遇到这个问题了，我在群里装完逼之后，素颜大大简单粗暴的给这篇博客起了这个名字，于是就有了这篇博客。
那么，先来个我画的示意图：
正文来啦：
一般我们的刷新控件，和网络请求数据源，刷新界面，是分开来封装的，而刷新控件往往都会有个动画，约0.3-0.5s位移向上消失。看着上图，如果刷新控件向上运动过程中，紫色cell的数据源已经被更新，木有了，紫色cell绘制的时候，就会出现数组越界的问题。
出现问题的代码大概长这样：
//网络请求结束后，dataArrary已经改变后：
[self.tableView.header endRefreshing];//刷新控件恢复
[self.tableView reloadData];//重绘tableView
最初我的解决方法是:
[self.tableView reloadData];//重绘tableView
// 主线程延迟执行：
double delayInSeconds = 0.1f;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);
dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
[self.tableView.header endRefreshing];//刷新控件恢复
});
而在昨天和素颜大大讨论之后，我今天测试的时候发现，reloadData这个方法，调用dataSource的时候是同步的，而delegate是异步的。
所以最终解决方法其实很简单了，先reloadData，再取消刷新控件：
[self.tableView reloadData];//重绘tableView
[self.tableView.header endRefreshing];//刷新控件恢复
引申一下：
其实在看sunny的UITableView-FDTemplateLayoutCell这个的时候，应该就能发现reloadData调用dataSource的时候是同步的，为此这个库做了cell高度的缓存，保证了tableview reloadData时的流畅。
引申第二下：
经过素颜大大提醒，MJRefresh对endRefreshing方法采用了0.1秒延时：
#pragma mark - 公共方法
- (void)endRefreshing
{
if ([self.scrollView isKindOfClass:[UICollectionView class]]) {
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[super endRefreshing];
});
} else {
[super endRefreshing];
}
}
这样处理面对固定高度的cell，不会产生问题，但是，如果高度需要非常复杂的计算，或者是xib的高度获取，线程block时间要长于0.1s，仍然会出现问题。
写在最后：
技术这种东西，真是越研究，越发现自己懂得太少，很多东西看过，就忘了，最简单的东西，也需要融会贯通。现在看看我之前解决本文问题的延时办法，真是蠢哭了。。
写代码的时候，实现效果是最低级的，更多时间要在想，为什么这么做，有没有更好的方法，还有其他的优化空间么？与大家共勉。
简书已经弃用，欢迎移步我的小专栏：
https://xiaozhuanlan.com/dahuihuiiOS
