iOS开发-简单科普下UITableView和UICollect
2016-11-08 本文已影响1523人
向钱冲啊
学iOS也有段时间了，作为iOS开发中常用的控件
UITableView和UICollectionView，它们的delegate和dataSource执行顺序你真的知道么？接下来本文将简单科普下它们的执行顺序，以便大家在开发中可以更加得心应手的使用这两种控件！
UITableView
首先来张图：
UITableView代理方法执行顺序。执行顺序是从上到下，依次执行。.png
第一次作图，比较丑，不要介意哈。。。
我们从图中可以清楚的看到一个UITableView加载的过程有以下几个步骤：
1：询问分区个数
2：询问每个分区的页眉和页脚的预估高度
3：询问每个分区cell的个数
4：询问每个分区cell的预估高度
5：询问每个分区cell的真实高度
6：询问每个分区cell的边距、样式、编辑状态
7：询问每个分区页脚的真实高度
8：询问每个分区的cell（自定义cell）
9：调用cell即将显示的方法
10：询问每个分区页眉的真实高度
11：询问每个分区页眉（自定义UIView）
12：调用每个分区页眉即将出现的方法
13：询问每个分区页脚（自定义UIView）
14：调用每个分区页脚即将出现的方法
下面对UITableView执行顺序进行总结：
在iOS7之前
delegate中没有预估高度API的时候，执行顺序总是先去询问cell的高度，然后再返回cell，可是在平时开发中，大多数时候我们需要根据服务器返回的数据返回cell对应的高度。从上面执行顺序中我们可以看到，如果实现了预估高度的方法，就会先去执行预估高度API，预估高度拿到之后会对界面上的UITableView进行渲染，当cell的各种样式、边距等拿到之后，最终会继续再调用一次返回cell高度的方法。
详情参照我测试的结果如下图:
渲染1个cell执行顺序
可以看到：
UITableView的加载需要走4轮才能渲染完毕。而获得
cell后，会在第四轮最后一次获得cell的真实高度。
如果实现了预估高度的方法，前三轮都不会执行tableView:heightForRowAtIndexPath:,其一共执行3次。
如果没有实现预估高度的方法，前三轮都会分别执行一次tableView:heightForRowAtIndexPath:其一共会执行6次。
对了，还有一个注意的点：datasource中
- (nullable NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section;
- (nullable NSString *)tableView:(UITableView *)tableView titleForFooterInSection:(NSInteger)section;```
这俩方法 和 ```delegate```中的
- (nullable UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section;
- (nullable UIView *)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section;
这俩方法 , 实现任意两个不会执行另外两个,因为返回UIView的优先级比NSString高，所以如果全部实现只会执行返回UIView```；
UICollectionView
由于UICollectionView执行顺序比较简单，下面直接看测试截图:
UICollectionView代理执行顺序
由图中可以发现一个UICollectionView的加载，走一轮就可以渲染完毕。
执行顺序就如图所示，比较浅显易懂，这里就不做阐述了。
