iOS11正式版已經(jīng)發(fā)布，相信大部分人已經(jīng)升級了最新的iOS11和Xcode9.0，那么老的版本也就帶來了新的問題，我們的任務--“填坑”！
一、安全區(qū)域問題
上圖：
這個頁面布局其實是tableView覆蓋整個屏幕的，設置的tableView的背景色為blueColor，但是很明顯整個tableview內(nèi)容下滑了20pt。
原因：iOS 11中automaticallyAdjustsScrollViewInsets屬性被廢棄了，self.automaticallyAdjustsScrollViewInsets = NO 就等于沒有設置（默認是YES），于是頂部就多了一定的contentInset。
如果你的APP中使用的是自定義的navigationbar，隱藏掉系統(tǒng)的navigationbar，并且tableView的frame為(0,0,SCREENWIDTH, SCREENHEIGHT)開始，那么系統(tǒng)會自動調(diào)整SafeAreaInsets值為(20,0,0,0)。
解決方法：
if (@available(iOS 11.0, *)) {
self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
} else {
self.automaticallyAdjustsScrollViewInsets = NO;
}
補充：體統(tǒng)了新的API@available(iOS 11.0, *) 系統(tǒng)版本判斷，再也不用手動調(diào)取系統(tǒng)版本進行對比了??！
關于安全區(qū)域適配，簡書上的這篇文章iOS 11 安全區(qū)域適配總結(jié)總結(jié)介紹得非常詳細，請參考這篇文章。
二、tableView分區(qū)頭和尾問題（代碼不嚴謹）
如圖，我想要的結(jié)果是不現(xiàn)實分區(qū)頭和尾，代碼中我也把tableView的
heightForFooterInSection和heightForHeaderInSection設置成0.1了
但是為什么不起作用？iOS11以前這樣寫一點問題也沒有，iOS 11上發(fā)生tableView頂部有留白，原因是代碼中只實現(xiàn)了heightForHeaderInSection方法，而沒有實現(xiàn)viewForHeaderInSection方法。那樣寫是不規(guī)范的，只實現(xiàn)高度，而沒有實現(xiàn)view，但代碼這樣寫在iOS 11之前是沒有問題的，iOS 11之后應該是由于開啟了估算行高機制引起了bug。添加上viewForHeaderInSection方法后，問題就解決了?；蛘咛砑右韵麓a關閉估算行高，問題也得到解決。
_tableView.estimatedRowHeight = 0;
_tableView.estimatedSectionHeaderHeight = 0;
_tableView.estimatedSectionFooterHeight = 0;
目前發(fā)現(xiàn)的iOS11在非iPhone X上的問題，會持續(xù)更新，稍后整理下iPhoneX顯示適配，歡迎大家討論。
