一、 关于sectionHeader， Footer
tableView 是plain时。 section的title会吸附在tableView的最上面(如果tableView有header的话，header先滑动到最上面，然后section title吸附)
tableView 是group时。 section的title会不会吸附在tableView的最上面（无论有没有header都不会吸附）
group情况下：设置了heightForHeaderInSection = 50。结果发现第一个section的height是对的，但是后面的section header的高度大于50. 需要设置heightForFooterInSection。
group情况下： heightForFooterInSection 不能设置成0，如果是0的话就会设置成默认的，即设置了间隙还是很大。heightForFooterInSection = 0.1 则每一个section的后面都不会有额外的间隙
二、 关于排版
tableView的最下面cell和最底部有一定的间隙，可以设置
tableView.contentInset = UIEdgeInsets(top: 0, left: 0, bottom: 10, right: 0)
三、 tableView 的调用顺序(亲测)
iOS12.01
- 自己计算高度。 先cellForRow 再HeightForRow
- textView.isEditable = false 的时候长按光标又在闪。加上textView.isUserInteractionEnabled = false。可以避免
iOS10.4
- 自己计算高度，先heightForRow 再cellforRow
总结原因：
tableView继承自scrollView，必须要确定其contentSize。 ios11之前estimatedRowHeight=0， 所以先调用heightForRow。 而ios11 自动开启预估行高，返回的是UITableViewAutomaticDimension。 已经有一个预估的contentSize。所以不用再先调用HeightForRow 方法。也可以解释使用estimatedRowHeight时刷新tableView会有跳动的问题。（https://blog.csdn.net/howl_MK/article/details/79597056）
- 设置以下三个属性，让iOS11不自动预估行高。可以解决tableView刷新时跳动问题
tableView.estimatedRowHeight = 0
tableView.estimatedSectionFooterHeight = 0
tableView.estimatedSectionHeaderHeight = 0
四、tableView的复用机制
超过自己frame大小，之后会复用，而不是超出屏幕。 如果collectionView大小很大，能容纳所有的cell，则不会复用。
tableView问题总结
-
关于TableView
- 在tableVIew中动态添加row时，reloadRows有可能崩溃,方法之一，可用reloadData来解决。
2018-11-26 20:59:09.092377+0800 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of rows in section 7. The number of rows contained in an existing section after the update (3) must be equal to the number of rows contained in that section before the update (0), plus or minus the number of rows inserted or deleted from that section (0 inserted, 0 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out).'
（https://blog.csdn.net/iosswift/article/details/50001145, https://blog.csdn.net/sinat_27310637/article/details/62225658）
- tableView的memory leak。 控制器虽然释放了，但View有可能没有释放。多半是由cell中block中循环引用引起的。
- tableView的代码，复杂情况下以cell的类型来设置，不要根据section和row来判断。 cellForRow中cell类型较多，并且cell的回调很多时，讲相应的回调抽出成方法，避免cellForRow方法冗长杂乱。
- UITableView/UIScrollView 不能响应TouchBegin 的处理及窥见 hitTest:withEvent：
-
关于TableViewCell
- sb 中的cell不用注册，如果注册了，反而会崩溃
- Cell 中如果有手势容易与cell自身的选中态冲突。（若将手势改为button则不会冲突）
- 通过tableView.register方式注册过的cell，在cellForRow中用dequeue indexPath方式创建的cell可以用as! 因为cell不可能为空。而dequeue 不带indexPath方式创建的cell可能为空，要判空。
let commentCell = tableView.dequeueReusableCell(withIdentifier: TPPNormalPostCommentCell.uniqueIdentifier, for: indexPath) as! TPPNormalPostCommentCell
- Push控制器时如果报sb中的控件为nil，首先检查初始化控制器是否正确（例如，本来从sb中加载控制器的， 结果只用代码（）初始化肯定不对。）；再检查控件是否在viewDidLoad之后调用。（在viewDidLoad方法加载之前，这些xib的控件是可能为空的，所以在变量的属性观察器中使用xib控件时要注意）如：
var naviTitle :String? {
didSet {
naviView.title = naviTitle
}
}
// 应当在viewDidLoad之后使用这些控件。 这样很容易崩溃
-
关于CollectionViewCell
- collectionView 如果只能横向滑动时，minimumLineSpacing 和 minimumInteritemSpacing 是有差别的。特别在相册demo中collectionView的大小大于屏幕时，设置cell之间的间隔。用minimumLineSpacing不会影响分页效果。minimumInteritemSpacing却会产生影响。
