写在最前面
UITableView是iOS开发最常用的类，用起来很方便，但使用不当也很容易引起Crash，UICollectionView和UITableView很类似，本文重点讲UITableView。UITableView很大一部分Crash是由于dataSource同步问题导致的，但在不同的场景会有不同的Crash栈，本文会结合线上真实的案例讲解UITableView常见的Crash和分析过程。
UITableView常见Crash主要有下面几类:
- dataSource更新后没同步刷新UITableView
- UITableView dataSource is not set
- Invalid update
- failed to obtain a cell from its dataSource
dataSource更新后没同步刷新UITableView
这是最常见也是最低级的错误，我们APP在刚上线的时候有几粒这样的错误，后面大家注意后就很少见这类错误了。
这类错误主要是由于dataSource个数比tableview cell个数少，导致访问dataSource时数组越界，Crash栈上有NSRangeException异常，要避免这类错误主要注意下面几个点：
- 更新完dataSource后在主线程立即调reloadData或其他api更新tableview
- 子线程操作dataSource时需要线程安全，这其实是任何多线程都要注意的问题～
- block dispatch到主线程执行并不等于一定没问题，由于dispatch到主线程block是一个一个执行的，并不能确保两个block连续执行，中间可能还会执行其他block，写代码时一定要注意这点。
UITableView dataSource is not set
这个是很少见但Crash率又很高的一个案例，分析这个Crash前前后后也化了很多时间。
Crash栈如下：
第一次分析
这个Crash是在中间某个版本突然冒出来的，并且Crash量很多，Crash栈没有任何我们自己的代码，没法直接定位到问题源，所以首先要找出问题源在哪，在分析几个栈后发现Crash都在直播间附近，所以锁定问题出在直播间的聊天室。
之前没见过类似的Crash，Exception Codes是UITableView dataSource is not set，但肯定可以排除初始化tableview时没有设置dataSource，因为这样tableview并不会显示，所以怀疑是tableView:cellForRowAtIndexPath:返回了nil，分析代码逻辑发现tableView:cellForRowAtIndexPath:的确会返回nil，所以很开心的以为解决了这个问题。
然而新版上线后发现并没有解决～～
再次分析
新版上线后还是有很多这个Crash，所以又硬着头皮分析了一下Crash log，仔细分析了Crash log后，发现Crash上都有[UITableView _updateAnimationDidStop:finished:context:]，根据名字可以知道这个方法是在UITableView某些动画结束时调用的，我们的代码是通过insertRowsAtIndexPaths:withRowAnimation:更新tableview的，所以怀疑是这个方法触发的动画，通过断点分析后的确时这个方法触发的。
----------------------------我是华丽的分割线----------------------------
一开始的思路是能不能禁止这个方法调用，其实我们的代码在调用这个方法之前已经通过setAnimationsEnabled:来禁止动画了，在尝试了其他方案后都无法禁止这个方法调用。
----------------------------我是华丽的分割线----------------------------
没法禁止这个方法调用后，就分析什么为什么dataSource会是nil，分析了整个代码逻辑发现只有vc dealloc的时候才可能导致dataSource是nil，我们也没有在dealloc里显式设置dataSource，而是weak属性自动设的。正常的vc也都是这样写的，唯一需要在dealloc里设置tableview的delegate和dataSource也是兼容iOS9以下系统delegate是assign的问题。
----------------------------我是华丽的分割线----------------------------
现在大概可以确定是在调insertRowsAtIndexPaths:withRowAnimation:后操作还没结束vc被pop出去了，导致dataSource变为了nil。一开始的想法是能不能在dealloc的时候取消掉tableview所有动画，发现系统也没提供接口。
最终解决方案
分析过程很冗长，但其实解决方法非常简单，简单到你都无法想象，只需要两行代码就可以解决～～
在dealloc里把dataSource设成nil，并且调用reloadData。
思考
为什么我们平时用tableview的时候都没有在dealloc里把dataSource设成nil和reloadData也不会有问题？
原因是因为正常的场景在pop的时候tableview都没有动画，而我们的直播间里聊天室tableview不停的有新的cell插进来，所以在pop的时候有动画的概率很高。
这个crash主要原因是tableview更新的时候section和row不为0，所以调用cellForRowAtIndexPath创建cell，但创建的时候发现dataSource为nil，在numberOfRowsInSection方法里面返回非0,同时把dataSource设为nil可以复现这个crash
关于reloadData的一些分析
通过断点分析reloadData方法发现下面几点：
- 调用reloadData后会立即触发numberOfSectionsInTableView和numberOfRowsInSection调用，里面会更新tableview的section和row信息，但并一定会立即调cellForRowAtIndexPath
- cellForRowAtIndexPath方法和numberOfRowsInSection并不是严格顺序执行的，这两个方法虽然都是在主线程runloop里执行，但两个方法中间可能执行很多其他操作
- 就算section和row都为0，还是会调用[UITableView _updateVisibleCellsNow:isRecursive:]更新tableview，但不会调cellForRowAtIndexPath，这就是为什么调reloadData不会有这个crash了。
Invalid update
这类crash一般时调用insertRowsAtIndexPaths:withRowAnimation:系列方法更新tableview时dataSource和tableview更新不匹配导致的。
crash栈：
crash栈的Exception Codes信息已经说的很清楚了，是因为tableview更新后cell个数跟numberOfRowsInSection返回的不一致，这类问题也出现了很多次，大多是我们使用不当导致的。
主要需要主要下面几点：
- 在同一个 beginUpdates and endUpdates中，不管insertion and deletion的顺序如何，都会先执行deletion。
- indexPaths里的index不能重复，上面这个crash就是因为insertRowsAtIndexPaths的时候逻辑错误导致indexPaths里的index重复了。
failed to obtain a cell from its dataSource
这类问题比较少见，如果cellForRowAtIndexPath方法返回nil就会导致这种crash，crash栈如下：
写在最后面
用系统组件的时候很多问题都是我们不了解组件的底层实现或者没按照api文档使用导致的，所以在使用一个组件的时候还是要多思考组件的底层机制。
