熟悉新公司项目的同时，分配了一些Crash问题，其中一个Crash率很高，但是复现几率很低，我就没有复现过（WTF..~~~(>_<)~~~），好在Fabric收集到的调用栈信息真的很友好，从此走上了一条不归路...
一、寻找问题
根据Fabric收集到的调用栈分析定位到，这是一个私信功能模块的Crash。之前的同事写的代码，涉及了不同业务逻辑，总结下来：
1.发送文本消息
2.重发文本消息
3.发送媒体消息（图片、语音、etc.）
以上情况都会触发Crash。
Crash的信息大致是这样的：
nvalid update: invalid number of rows in section 0. The number of rows
contained in an existing section after the update (28) must be equal to the
number of rows contained in that section before the update (28), plus or
minus the number of rows inserted or deleted from that section (1 inserted, 0
deleted) and plus or minus the number of rows moved into or out of that
section (0 moved in, 0 moved out).
而且调用栈信息显示，Crash之前基本都是调用了
[_tableView endUpdates];
好了到了这里问题点找到了，因为是私信模块，发送消息的时候，需要调用
insertRowsAtIndexPaths:withRowAnimation:，当然还有删除消息时调用
deleteRowsAtIndexPaths: withRowAnimation:等。之前的同事将这些调用操作放在了
[_tableView beginUpdates];
[_tableView endUpdates];
代码之间。
二、分析问题
之前的代码就是这样做，Why？：
1、
[_tableView beginUpdates];
[_tableView endUpdates];
此段代码的作用是什么？为什么要放在此段代码中间？
参考Apple官方文档，当需要批量操作TableView的时候（Batch Insertion, Deletion, and Reloading of Rows and Sections）就需要将Insertion、Deletion、Reloading等操作的代码放在上述代码之间，并且操作的动画是同步的。项目中确实有批量操作的需求，也就是说正常这样操作并不会有任何问题。
2、仔细看上述的Crash信息，大致的意思是，在beginUpdates之前和endUpdates之后数据源必须相同。
三、解决问题
1、一般TableView的增加、删除、插入的操作时，处理完数据源后，我们直接调用相应的方法，例如
1）.最常见的，网络请求回来的数据，我们处理完数据源之后，会调用reloadData。
2）.删除数据源某一项，对应调用deleteRowsAtIndexPaths: withRowAnimation:。
切记不能调用处理数据源后，未调用相应更新列表的方法。
2、[_tableView beginUpdates/endUpdates];调用时不能同时改变数据源，我们项目因某些逻辑需求，确实造成了同时修改数据源的风险，后续解决办法是，将数据源加锁，并在[_tableView beginUpdates/endUpdates];调用时也加锁，以保证数据源的安全性。
