本文為作者原創(chuàng)，未經(jīng)作者允許不得轉(zhuǎn)載。該文同時發(fā)表在騰訊bugly公眾號：http://mp.weixin.qq.com/s/W1_0VrchCO50owhJNmJnuQ 歡迎閱讀
導語：本文主要是對iOS 11下APP中tableView內(nèi)容下移20pt或下移64pt的問題適配的一個總結(jié)。內(nèi)容包括五個部分：問題的原因分析堕绩、adjustContentInset屬性的計算方式擒悬、什么情況下的tableView會發(fā)生內(nèi)容下移窍帝、有哪些解決方法榕茧、解決這個問題時遇到的另外一個小問題。
一客给、iOS 11下APP中tableView內(nèi)容下移20pt或下移64pt的原因分析
問題如下圖所示：
1. 原因分析
原因是iOS 11中Controller的automaticallyAdjustsScrollViewInsets屬性被廢棄了用押，所以當tableView超出安全區(qū)域時系統(tǒng)自動調(diào)整了SafeAreaInsets值，進而影響adjustedContentInset值靶剑，在iOS 11中決定tableView的內(nèi)容與邊緣距離的是adjustedContentInset屬性蜻拨，而不是contentInset池充。adjustedContentInset的計算方式見本文第二部分內(nèi)容。因為系統(tǒng)對adjustedContentInset值進行了調(diào)整缎讼，所以導致tableView的內(nèi)容到邊緣的距離發(fā)生了變化收夸，導致tableView下移了20pt（statusbar高度）或64pt（navigationbar高度）。
如果你的APP中使用的是自定義的navigationbar血崭，隱藏掉系統(tǒng)的navigationbar卧惜，并且tableView的frame為(0,0,SCREEN_WIDTH, SCREEN_HEIGHT)開始，那么系統(tǒng)會自動調(diào)整SafeAreaInsets值為(20,0,0,0)夹纫，如果使用了系統(tǒng)的navigationbar咽瓷，那么SafeAreaInsets值為(64,0,0,0)，如果也使用了系統(tǒng)的tabbar舰讹，那么SafeAreaInsets值為(64,0,49,0)茅姜。關于什么情況下會發(fā)生內(nèi)容下移的問題，本文第三部分有介紹月匣。
2. 安全區(qū)域的概念
系統(tǒng)自動調(diào)整tableView內(nèi)容偏移量钻洒，是根據(jù)安全區(qū)域來調(diào)整的。安全區(qū)域是iOS 11新提出的锄开，如下圖所示：
安全區(qū)域幫助我們將view放置在整個屏幕的可視的部分素标。即使把navigationbar設置為透明的，系統(tǒng)也認為安全區(qū)域是從navigationbar的bottom開始的院刁。
安全區(qū)域定義了view中可視區(qū)域的部分糯钙，保證不被系統(tǒng)的狀態(tài)欄、或父視圖提供的view如導航欄覆蓋退腥∪伟叮可以使用additionalSafeAreaInsets去擴展安全區(qū)域去包括自定義的content在你的界面。每個view都可以改變安全區(qū)域嵌入的大小狡刘，Controller也可以享潜。
safeAreaInsets屬性反映了一個view距離該view的安全區(qū)域的邊距。對于一個Controller的根視圖而言嗅蔬，SafeAreaInsets值包括了被statusbar和其他可視的bars覆蓋的區(qū)域和其他通過additionalSafeAreaInsets自定義的insets值剑按。對于view層次中得其他view，SafeAreaInsets值反映了view被覆蓋的部分澜术。如果一個view全部在它父視圖的安全區(qū)域內(nèi)艺蝴，則SafeAreaInsets值為(0,0,0,0)。
二鸟废、 adjustContentInset屬性的計算方式
首先看scrollView在iOS11新增的兩個屬性：adjustContentInset 和 contentInsetAdjustmentBehavior猜敢。
/* Configure the behavior of adjustedContentInset.
Default is UIScrollViewContentInsetAdjustmentAutomatic.
*/
@property(nonatomic) UIScrollViewContentInsetAdjustmentBehavior contentInsetAdjustmentBehavior
adjustContentInset表示contentView.frame.origin偏移了scrollview.frame.origin多少；是系統(tǒng)計算得來的，計算方式由contentInsetAdjustmentBehavior決定缩擂。有以下幾種計算方式：
UIScrollViewContentInsetAdjustmentAutomatic：如果scrollview在一個automaticallyAdjustsScrollViewInsets = YES的controller上鼠冕，并且這個Controller包含在一個navigation controller中，這種情況下會設置在top & bottom上 adjustedContentInset = safeAreaInset + contentInset不管是否滾動胯盯。其他情況下與UIScrollViewContentInsetAdjustmentScrollableAxes相同UIScrollViewContentInsetAdjustmentScrollableAxes: 在可滾動方向上adjustedContentInset = safeAreaInset + contentInset懈费，在不可滾動方向上adjustedContentInset = contentInset；依賴于scrollEnabled和alwaysBounceHorizontal / vertical = YES博脑，scrollEnabled默認為yes憎乙，所以大多數(shù)情況下，計算方式還是adjustedContentInset = safeAreaInset + contentInsetUIScrollViewContentInsetAdjustmentNever: adjustedContentInset = contentInsetUIScrollViewContentInsetAdjustmentAlways: adjustedContentInset = safeAreaInset + contentInset
當contentInsetAdjustmentBehavior設置為UIScrollViewContentInsetAdjustmentNever的時候趋厉，adjustContentInset值不受SafeAreaInset值的影響寨闹。
三、什么情況下的tableView會發(fā)生上述問題
如果設置了automaticallyAdjustsScrollViewInsets = YES君账，那么不會發(fā)生問題繁堡，一直都是由系統(tǒng)來調(diào)整內(nèi)容的偏移量。
接下來排查下自己的項目中哪些頁面會發(fā)生以上問題乡数。
當tableView的frame超出安全區(qū)域范圍時椭蹄，系統(tǒng)會自動調(diào)整內(nèi)容的位置，SafeAreaInsets值會不為0净赴，于是影響tableView的adjustContentInset值绳矩，于是影響tableView的內(nèi)容展示，導致tableView的content下移了SafeAreaInsets的距離玖翅。SafeAreaInsets值為0時翼馆，是正常的情況。
需要了解每個頁面的結(jié)構金度，看tableView是否被系統(tǒng)的statusbar或navigationbar覆蓋应媚，如果被覆蓋的話，則會發(fā)生下移猜极。也可以通過tableview.safeAreaInsets的值來確認是因為安全區(qū)域的問題導致的內(nèi)容下移中姜。
如下代碼片段，可以看出系統(tǒng)對tableView向下調(diào)整了20pt的距離跟伏，因為tableView超出了安全區(qū)域范圍丢胚，被statusbar覆蓋。
tableview.contentInset: {64, 0, 60, 0}
tableview.safeAreaInsets: {20, 0, 0, 0}
tableview.adjustedContentInset: {84, 0, 60, 0}
四受扳、這個問題的解決方法有哪些携龟？
1. 重新設置tableView的contentInset值，來抵消掉SafeAreaInset值勘高，因為內(nèi)容下移偏移量 = contentInset + SafeAreaInset骨宠；
如果之前自己設置了contentInset值為(64,0,0,0),現(xiàn)在系統(tǒng)又設置了SafeAreaInsets值為(64,0,0,0)浮定，那么tableView內(nèi)容下移了64pt相满，這種情況下层亿，可以設置contentInset值為(0,0,0,0)，也就是遵從系統(tǒng)的設置了立美。
2. 設置tableView的contentInsetAdjustmentBehavior屬性
如果不需要系統(tǒng)為你設置邊緣距離匿又，可以做以下設置：
//如果iOS的系統(tǒng)是11.0，會有這樣一個宏定義“#define __IPHONE_11_0 110000”建蹄；如果系統(tǒng)版本低于11.0則沒有這個宏定義
#ifdef __IPHONE_11_0
if ([tableView respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]) {
tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
}
#endif
contentInsetAdjustmentBehavior屬性也是用來取代automaticallyAdjustsScrollViewInsets屬性的碌更，推薦使用這種方式。
3. 通過設置iOS 11新增的屬性addtionalSafeAreaInset洞慎；
iOS 11之前痛单，大家是通過將Controller的automaticallyAdjustsScrollViewInsets屬性設置為NO，來禁止系統(tǒng)對tableView調(diào)整contentInsets的劲腿。如果還是想從Controller級別解決問題旭绒，那么可以通過設置Controller的additionalSafeAreaInsets屬性，如果SafeAreaInset值為(20,0,0,0)焦人，那么設置additionalSafeAreaInsets屬性值為(-20,0,0,0)挥吵，則SafeAreaInsets不會對adjustedContentInset值產(chǎn)生影響，tableView內(nèi)容不會顯示異常花椭。這里需要注意的是addtionalSafeAreaInset是Controller的屬性忽匈，要知道SafeAreaInset的值是由哪個Controller引起的，可能是由自己的Controller調(diào)整的矿辽，可能是navigationController調(diào)整的丹允。是由哪個Controller調(diào)整的，則設置哪個Controller的addtionalSafeAreaInset值來抵消掉SafeAreaInset值袋倔。
五雕蔽、遇到的另外一個與安全區(qū)域無關的tableView內(nèi)容下移的問題
我的作品頁面的tableView下移了約40pt，這里是否跟安全區(qū)域有關呢奕污？
查了下頁面結(jié)構萎羔，tableView的父視圖的frame在navigationbar的bottom之下，tableView在父視圖的安全區(qū)域內(nèi)碳默，打印出來tableView的SafeAreaInset值也是(0贾陷，0，0嘱根，0);所以不是安全區(qū)域?qū)е碌膬?nèi)容下移髓废。
經(jīng)過查看代碼，發(fā)現(xiàn)tableView的style:UITableViewStyleGrouped類型该抒，默認tableView開頭和結(jié)尾是有間距的慌洪，不需要這個間距的話，可以通過實現(xiàn)heightForHeaderInSection方法（返回一個較小值：0.1）和viewForHeaderInSection（返回一個view）來去除頭部的留白，底部同理冈爹。
iOS 11上發(fā)生tableView頂部有留白涌攻，原因是代碼中只實現(xiàn)了heightForHeaderInSection方法，而沒有實現(xiàn)viewForHeaderInSection方法频伤。那樣寫是不規(guī)范的恳谎，只實現(xiàn)高度，而沒有實現(xiàn)view憋肖，但代碼這樣寫在iOS 11之前是沒有問題的因痛，iOS 11之后應該是由于開啟了估算行高機制引起了bug。添加上viewForHeaderInSection方法后岸更，問題就解決了鸵膏。或者添加以下代碼關閉估算行高怎炊，問題也得到解決谭企。
self.tableView.estimatedRowHeight = 0;
self.tableView.estimatedSectionHeaderHeight = 0;
self.tableView.estimatedSectionFooterHeight = 0;