带分页控件的UITableView跑几万次偶现2、3次的数组越界crash的解决方法

这个问题在我做火柴盒用户crash分析的时候，曾经困扰我挺久的，需要较大的用户量，才能发现这个crash，解决之后，也不知道怎么叙述出来，恰好最近好几个人都遇到这个问题了，我在群里装完逼之后，素颜大大简单粗暴的给这篇博客起了这个名字，于是就有了这篇博客。

看我傲娇的表情.jpg

那么，先来个我画的示意图：

示意图.jpg

正文来啦：

一般我们的刷新控件，和网络请求数据源，刷新界面，是分开来封装的，而刷新控件往往都会有个动画，约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