今天遇到了個(gè)比較奇葩的問(wèn)題
一個(gè)tableView, 在數(shù)據(jù)源添加一條數(shù)據(jù)后reloadData障涯，tableView的contentOffset值變了喘漏，
這就導(dǎo)致顯示的cell的位置的錯(cuò)亂或者偏移狡赐；
比如數(shù)據(jù)是【1稚虎，2乡范，3奸柬，4生年，5，6廓奕，7抱婉，8】，當(dāng)前顯示的是【6桌粉，7蒸绩，8】
這時(shí)候在數(shù)據(jù)源最后新加了一個(gè)9，
本來(lái)想要的結(jié)果是番甩，當(dāng)前還是顯示【6侵贵，7，8】缘薛，向下滑動(dòng)后顯示【7窍育，8，9】宴胧，
但出來(lái)的結(jié)果卻是【5漱抓，6，7】恕齐。乞娄。。
經(jīng)過(guò)打斷點(diǎn)測(cè)試显歧，發(fā)現(xiàn)就是reloadData前后contentOffset值變化了仪或，而且變化的還沒(méi)什么規(guī)律，
然后跟iOS 10及以下的系統(tǒng)對(duì)比士骤，發(fā)現(xiàn)只有iOS 11上會(huì)這樣
所以基本可以確定是iOS 11的問(wèn)題了
然后去看iOS 11有什么新變化范删，
原來(lái)iOS 11中，tableView默認(rèn)啟用Self-Sizing
@available(iOS 7.0, *)
open var estimatedRowHeight: CGFloat // default is UITableViewAutomaticDimension, set to 0 to disable
@available(iOS 7.0, *)
open var estimatedSectionHeaderHeight: CGFloat // default is UITableViewAutomaticDimension, set to 0 to disable
@available(iOS 7.0, *)
open var estimatedSectionFooterHeight: CGFloat // default is UITableViewAutomaticDimension, set to 0 to disable
所以拷肌，tableView的contentSize大小一開(kāi)始也是不準(zhǔn)確的到旦，會(huì)隨著滑動(dòng)逐漸變化
知道了原因，就好解決了巨缘，只需要關(guān)閉這個(gè)功能就可以了
解決方案：
tableView.estimatedRowHeight = 0
tableView.estimatedSectionHeaderHeight = 0
tableView.estimatedSectionFooterHeight = 0
注意三個(gè)屬性都需要設(shè)置添忘，即使你沒(méi)用到sectionHeader或者sectionFooter也要設(shè)置！Ｈ羲搁骑！
注意三個(gè)屬性都需要設(shè)置，即使你沒(méi)用到sectionHeader或者sectionFooter也要設(shè)置！０胁 会通！
注意三個(gè)屬性都需要設(shè)置，即使你沒(méi)用到sectionHeader或者sectionFooter也要設(shè)置Ｂχ堋Ｌ槌蕖！
另外：
因?yàn)橥瑯拥脑颍河?code>scrollRectToVisible來(lái)實(shí)現(xiàn)滑動(dòng)到tableView底部的方法也行不通了煤辨，只能用
open func scrollToRow(at indexPath: IndexPath, at scrollPosition: UITableViewScrollPosition, animated: Bool)
注意判斷section和row沒(méi)有越界或者為負(fù)數(shù)裳涛，否則會(huì)crash。众辨。端三。
