一个友盟BUG的思考和分析：Invalid update

1.友盟错误信息

Invalid update: invalid number of rows in section .  The number of rows contained in an existing section after the update ()
 must be equal to the number of rows contained in that section before the update (), plus or minus the number of rows inserted or deleted
from that section ( inserted,  deleted) and plus or minus the number of rows moved into or out of that section ( moved in,  moved out).
(null)

2.错误信息解析

上面的错误信息，大意是：调用insertRowsAtIndexPaths或deleteRowsAtIndexPaths时，表格 的 行数 一定要与数据源的数量一致。

2.1原因分析1：异步线程更新数据源

下面使用一个Demo来复现这种情况：

- (void)p_addRow {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, ), ^{
        [NSThread sleepForTimeInterval:0.5];  //模拟网络数据加载
        [self.arrData addObject:@"cell number 1 --"];

        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView beginUpdates];
            [self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.arrData.count -  inSection:]] withRowAnimation:UITableViewRowAnimationFade];
            [self.tableView endUpdates];
        });
    });
}

- (void)p_deleteRow {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, ), ^{
        [NSThread sleepForTimeInterval:0.5];  //模拟网络数据加载
        [self.arrData removeObjectAtIndex:];

        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView beginUpdates];
            [self.tableView deleteRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.arrData.count -  inSection:]] withRowAnimation:UITableViewRowAnimationFade];
            [self.tableView endUpdates];
        });
    });
}

这两个方法调用的时候，我们先按照常规的操作调用，每点击一次，添加/删除一条数据，这种情况下，从实际效果可以看到不会出现崩溃的现象。

现在用一个定时器来模拟手点的效果，经过试验得知，当定时器执行的时间间隔过快，而网络数据反应太慢的情况，会出现崩溃的现象，代码如下：

- (void)leftButton {
    self.timer = [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(p_deleteRow) userInfo:nil repeats:YES];
}

- (void)rightButton {
    [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selector(p_addRow) userInfo:nil repeats:NO];
}

- (void)p_addRow {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, ), ^{
        [NSThread sleepForTimeInterval:0.5];  //模拟网络数据加载
        [self.arrData addObject:@"cell number 1 --"];

        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView beginUpdates];
            [self.tableView insertRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.arrData.count -  inSection:]] withRowAnimation:UITableViewRowAnimationFade];
            [self.tableView endUpdates];
        });
    });
}

- (void)p_deleteRow {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, ), ^{
        [NSThread sleepForTimeInterval:0.5];  //模拟网络数据加载
        [self.arrData removeObjectAtIndex:];

        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView beginUpdates];
            [self.tableView deleteRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.arrData.count -  inSection:]] withRowAnimation:UITableViewRowAnimationFade];
            [self.tableView endUpdates];
        });
    });
}

崩溃日志如下：

这样看还是有点抽象，我们加一个变量来保存当前表格的行数以及在执行insertRowsAtIndexPaths时数据源的表格行数：

从结果可以看到，由于获取数据是在异步线程里面进行的，导致在执行insertRowsAtIndexPaths时，实际上数据源已经进行了多次插入操作，这样，只执行一次insertRowsAtIndexPaths，便会出现崩溃现象了。

2.2原因分析2：主线程更新数据源

上面小节是在异步线程中更新数据源，这里我们把数据源的放在主线程，看看实际效果：

使用上面的代码，我们可以看到没有出现崩溃的问题，那么是不是表示在主线程更新数据源就没有问题呢？我们试一下这种情况：如果通过网络加载或其他方式加载数据的时候，数据源有多条数据呢？还是看代码演示：

从这里可以看到，如果数据源更新了多条数据，仍然在insertRowsAtIndexPaths方法里面只加了一条数据时，便会出现崩溃现象。

2.3其他情况

上两节的内容分析的崩溃原因，有一个共同点：下面这两个数字是不一样的(删除的话，前面那个数字应该小于后面那个数字，如果不是这个规则，应该是网络又更新了数据源)。

The number of rows contained in an existing section after the update () must be equal to the number of rows contained in that section before the update ()

但从UMeng的崩溃日志看，实际上还有一种情况，那就是这两个数字是一样的。这种情况是怎么发生的呢？我们修改一下代码：

从代码可以看到：更新数据源之后，先调用了一下[self.tableView reloadData]，这个时候因为表格数据源已经更新，并且表格也已经更新，这个时候再调用一次insertRowsAtIndexPaths方法，就会接着导致数据源和表格行不一致，从而导致崩溃。

3.解决方案

通过对我们工程代码的分析，数据源的操作是在主线程(对涉及到数据源的地方，都打印了线程的日志信息，显示当前线程为主线程)，因此初步判断出现崩溃的原因为2.2小节和2.3小节所描述的。这两种情况，我们先用Demo来演示一下解决方案看看是不是有效的：

逐步放开两个注释内容，可以看到，这三个条件下，都不会崩溃。

同样的，演示一下删除：

逐步放开两个注释内容，可以看到，这三个条件下，也不会崩溃。