前言
在写这篇文章之前,我将本文集(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的代理。
这个情况很奇怪。我们稍微修改一下代码,再运行一下试试。
运行结果如下:
可以清楚的看到,消失的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。
网友评论