UITableView相关的坑

前言

在写这篇文章之前，我将本文集（iOS开发中的坑）里的一些文章进行了调整，移至iOS开发文集当中。目的，就是为了进行一种区分，让本文集从今往后，成为一种专门记录一些不常见的iOS开发中的坑，的存在。
本文集中的文章中记录下来的坑都属于不常见的那种，很多人可能永远都不会遇到，但是当你遇到时，往往很难在网上找到相关记录。

正文

UITableView可以说是iOS开发中最常用到的几种UI控件之一，相信很多人都用过不知道多少次。今天就来说一说UITableView中那些不常见的大坑。

1.UITableView在RegisterUITableViewCell之前崩溃的坑。
光看标题可能很多人不是很明白，所以我就直接上代码。

这是初始代码，为了尽量简单的模拟出我想要的效果，代码就不写的那么规范啦，希望大家在真正项目不要学我

看完上图代码，我们的第一个问题就来啦,请问上图代码运行之后，控制台的输出顺序是什么？

这个问题很简单，相信大家都回答正确啦。

虽然答对了上面的问题，但是还请不要骄傲，因为我们的重头戏来了。

认真观看新的代码，再说说这次的打印顺序，你还能说对吗？

下面宣布答案，可能和你的猜测有些出入。

这次你又答对了吗？

**结论：在为tableView设置了tableFooterView和tableHeaderView之后，如果调用tableView.separatorStyle方法，系统就会自动调用UITableViewDataSource代理的代理方法。如果对这个不了解，可能就会造成各种问题。不过这个问题在iOS10已经解决，不再出现。我想应该是个官方BUG。

最后，本次实验的运行环境为iOS8.4的虚拟机，由于条件简陋，我没有测试其他的iOS版本。**

2.UITableView第0个sectionHeaderView不显示的问题

运行如图代码

得到如下结果：

得到如下结果

可以清楚的看出，第一个section的headerView没有显现。如果在代理里进行打印，会发现根本没有走sectionHeaderView的第0个section的代理。
这个情况很奇怪。我们稍微修改一下代码，再运行一下试试。

修改后的代码如图，添加了一个返回sectionHeaderView高度的代理实现

运行结果如下：

可以清楚的看到，消失的0section的sectionHeaderView又出现啦

真是神奇啊！！！
由上图的代码对比可知，造成这种结果的原因便是sectionHeaderView的高度实现的方式不同。用self.tableView.sectionHeaderHeight设置高度就会丢失第0gesection的headerView，而通过代理就不会。

这是sectionHeaderHeight的介绍

我们看一下sectionHeaderHeight的介绍，发现只有代理不实现的时候，才会用sectionHeaderHeight，按照常理来说这两者在设置统一高度时，应该没有差别。所以这种情况的出现实在让人费解。

结论：这个实验还有一部分我没有放出，所以我就直接给出结论。只有当tableView是Grouped，并且section的高度是通过sectionHeaderHeight设置的时候，第0个section的headerView才会丢失。如果tableView是Plain就不会有任何问题。

3.UITableViewHeaderFooterView不能当作普通的UIView来用，因为UITableViewHeaderFooterView中有很多约束条件，所以不能用来当作普通的UIView。