iOS 11 安全區(qū)域適配總結(jié)

語(yǔ):本文主要是對(duì)iOS 11下APP中tableView內(nèi)容下移20pt或下移64pt的問(wèn)題適配的一個(gè)總結(jié)。內(nèi)容包括五個(gè)部分:?jiǎn)栴}的原因分析、adjustContentInset屬性的計(jì)算方式、什么情況下的tableView會(huì)發(fā)生內(nèi)容下移、有哪些解決方法、解決這個(gè)問(wèn)題時(shí)遇到的另外一個(gè)小問(wèn)題。

一、iOS 11下APP中tableView內(nèi)容下移20pt或下移64pt的原因分析

問(wèn)題如下圖所示:

問(wèn)題.png

1. 原因分析

原因是iOS 11中Controller的automaticallyAdjustsScrollViewInsets屬性被廢棄了,所以當(dāng)tableView超出安全區(qū)域時(shí)系統(tǒng)自動(dòng)調(diào)整了SafeAreaInsets值,進(jìn)而影響adjustedContentInset值,在iOS 11中決定tableView的內(nèi)容與邊緣距離的是adjustedContentInset屬性,而不是contentInset。adjustedContentInset的計(jì)算方式見(jiàn)本文第二部分內(nèi)容。因?yàn)橄到y(tǒng)對(duì)adjustedContentInset值進(jìn)行了調(diào)整,所以導(dǎo)致tableView的內(nèi)容到邊緣的距離發(fā)生了變化,導(dǎo)致tableView下移了20pt(statusbar高度)或64pt(navigationbar高度)。

如果你的APP中使用的是自定義的navigationbar,隱藏掉系統(tǒng)的navigationbar,并且tableView的frame為(0,0,SCREEN_WIDTH, SCREEN_HEIGHT)開(kāi)始,那么系統(tǒng)會(huì)自動(dòng)調(diào)整SafeAreaInsets值為(20,0,0,0),如果使用了系統(tǒng)的navigationbar,那么SafeAreaInsets值為(64,0,0,0),如果也使用了系統(tǒng)的tabbar,那么SafeAreaInsets值為(64,0,49,0)。關(guān)于什么情況下會(huì)發(fā)生內(nèi)容下移的問(wèn)題,本文第三部分有介紹。

2. 安全區(qū)域的概念

系統(tǒng)自動(dòng)調(diào)整tableView內(nèi)容偏移量,是根據(jù)安全區(qū)域來(lái)調(diào)整的。安全區(qū)域是iOS 11新提出的,如下圖所示:

SafeArea of an interface.png

安全區(qū)域幫助我們將view放置在整個(gè)屏幕的可視的部分。即使把navigationbar設(shè)置為透明的,系統(tǒng)也認(rèn)為安全區(qū)域是從navigationbar的bottom開(kāi)始的。

安全區(qū)域定義了view中可視區(qū)域的部分,保證不被系統(tǒng)的狀態(tài)欄、或父視圖提供的view如導(dǎo)航欄覆蓋??梢允褂胊dditionalSafeAreaInsets去擴(kuò)展安全區(qū)域去包括自定義的content在你的界面。每個(gè)view都可以改變安全區(qū)域嵌入的大小,Controller也可以。

safeAreaInsets屬性反映了一個(gè)view距離該view的安全區(qū)域的邊距。對(duì)于一個(gè)Controller的根視圖而言,SafeAreaInsets值包括了被statusbar和其他可視的bars覆蓋的區(qū)域和其他通過(guò)additionalSafeAreaInsets自定義的insets值。對(duì)于view層次中得其他view,SafeAreaInsets值反映了view被覆蓋的部分。如果一個(gè)view全部在它父視圖的安全區(qū)域內(nèi),則SafeAreaInsets值為(0,0,0,0)。

二、 adjustContentInset屬性的計(jì)算方式

首先看scrollView在iOS11新增的兩個(gè)屬性:adjustContentInset和contentInsetAdjustmentBehavior。

/* Configure the behavior of adjustedContentInset.

Default is UIScrollViewContentInsetAdjustmentAutomatic.

*/

@property(nonatomic) UIScrollViewContentInsetAdjustmentBehavior contentInsetAdjustmentBehavior

adjustContentInset表示contentView.frame.origin偏移了scrollview.frame.origin多少;是系統(tǒng)計(jì)算得來(lái)的,計(jì)算方式由contentInsetAdjustmentBehavior決定。有以下幾種計(jì)算方式:

UIScrollViewContentInsetAdjustmentAutomatic:如果scrollview在一個(gè)automaticallyAdjustsScrollViewInsets = YES的controller上,并且這個(gè)Controller包含在一個(gè)navigation controller中,這種情況下會(huì)設(shè)置在top & bottom上 adjustedContentInset = safeAreaInset + contentInset不管是否滾動(dòng)。其他情況下與UIScrollViewContentInsetAdjustmentScrollableAxes相同

UIScrollViewContentInsetAdjustmentScrollableAxes: 在可滾動(dòng)方向上adjustedContentInset = safeAreaInset + contentInset,在不可滾動(dòng)方向上adjustedContentInset = contentInset;依賴(lài)于scrollEnabled和alwaysBounceHorizontal / vertical = YES,scrollEnabled默認(rèn)為yes,所以大多數(shù)情況下,計(jì)算方式還是adjustedContentInset = safeAreaInset + contentInset

UIScrollViewContentInsetAdjustmentNever: adjustedContentInset = contentInset

UIScrollViewContentInsetAdjustmentAlways: adjustedContentInset = safeAreaInset + contentInset

當(dāng)contentInsetAdjustmentBehavior設(shè)置為UIScrollViewContentInsetAdjustmentNever的時(shí)候,adjustContentInset值不受SafeAreaInset值的影響。

三、什么情況下的tableView會(huì)發(fā)生上述問(wèn)題

如果設(shè)置了automaticallyAdjustsScrollViewInsets = YES,那么不會(huì)發(fā)生問(wèn)題,一直都是由系統(tǒng)來(lái)調(diào)整內(nèi)容的偏移量。

接下來(lái)排查下自己的項(xiàng)目中哪些頁(yè)面會(huì)發(fā)生以上問(wèn)題。

當(dāng)tableView的frame超出安全區(qū)域范圍時(shí),系統(tǒng)會(huì)自動(dòng)調(diào)整內(nèi)容的位置,SafeAreaInsets值會(huì)不為0,于是影響tableView的adjustContentInset值,于是影響tableView的內(nèi)容展示,導(dǎo)致tableView的content下移了SafeAreaInsets的距離。SafeAreaInsets值為0時(shí),是正常的情況。

需要了解每個(gè)頁(yè)面的結(jié)構(gòu),看tableView是否被系統(tǒng)的statusbar或navigationbar覆蓋,如果被覆蓋的話,則會(huì)發(fā)生下移。也可以通過(guò)tableview.safeAreaInsets的值來(lái)確認(rèn)是因?yàn)榘踩珔^(qū)域的問(wèn)題導(dǎo)致的內(nèi)容下移。

如下代碼片段,可以看出系統(tǒng)對(duì)tableView向下調(diào)整了20pt的距離,因?yàn)閠ableView超出了安全區(qū)域范圍,被statusbar覆蓋。

tableview.contentInset: {64, 0, 60, 0}

tableview.safeAreaInsets: {20, 0, 0, 0}

tableview.adjustedContentInset: {84, 0, 60, 0}

四、這個(gè)問(wèn)題的解決方法有哪些?

1. 重新設(shè)置tableView的contentInset值,來(lái)抵消掉SafeAreaInset值,因?yàn)閮?nèi)容下移偏移量 = contentInset + SafeAreaInset;

如果之前自己設(shè)置了contentInset值為(64,0,0,0),現(xiàn)在系統(tǒng)又設(shè)置了SafeAreaInsets值為(64,0,0,0),那么tableView內(nèi)容下移了64pt,這種情況下,可以設(shè)置contentInset值為(0,0,0,0),也就是遵從系統(tǒng)的設(shè)置了。

2. 設(shè)置tableView的contentInsetAdjustmentBehavior屬性

如果不需要系統(tǒng)為你設(shè)置邊緣距離,可以做以下設(shè)置:

//如果iOS的系統(tǒng)是11.0,會(huì)有這樣一個(gè)宏定義“#define __IPHONE_11_0? 110000”;如果系統(tǒng)版本低于11.0則沒(méi)有這個(gè)宏定義

#ifdef __IPHONE_11_0

if ([tableView respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]) {

tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;

}

#endif

contentInsetAdjustmentBehavior屬性也是用來(lái)取代automaticallyAdjustsScrollViewInsets屬性的,推薦使用這種方式。

3. 通過(guò)設(shè)置iOS 11新增的屬性addtionalSafeAreaInset;

iOS 11之前,大家是通過(guò)將Controller的automaticallyAdjustsScrollViewInsets屬性設(shè)置為NO,來(lái)禁止系統(tǒng)對(duì)tableView調(diào)整contentInsets的。如果還是想從Controller級(jí)別解決問(wèn)題,那么可以通過(guò)設(shè)置Controller的additionalSafeAreaInsets屬性,如果SafeAreaInset值為(20,0,0,0),那么設(shè)置additionalSafeAreaInsets屬性值為(-20,0,0,0),則SafeAreaInsets不會(huì)對(duì)adjustedContentInset值產(chǎn)生影響,tableView內(nèi)容不會(huì)顯示異常。這里需要注意的是addtionalSafeAreaInset是Controller的屬性,要知道SafeAreaInset的值是由哪個(gè)Controller引起的,可能是由自己的Controller調(diào)整的,可能是navigationController調(diào)整的。是由哪個(gè)Controller調(diào)整的,則設(shè)置哪個(gè)Controller的addtionalSafeAreaInset值來(lái)抵消掉SafeAreaInset值。

五、遇到的另外一個(gè)與安全區(qū)域無(wú)關(guān)的tableView內(nèi)容下移的問(wèn)題

我的作品頁(yè)面的tableView下移了約40pt,這里是否跟安全區(qū)域有關(guān)呢?

查了下頁(yè)面結(jié)構(gòu),tableView的父視圖的frame在navigationbar的bottom之下,tableView在父視圖的安全區(qū)域內(nèi),打印出來(lái)tableView的SafeAreaInset值也是(0,0,0,0);所以不是安全區(qū)域?qū)е碌膬?nèi)容下移。

經(jīng)過(guò)查看代碼,發(fā)現(xiàn)tableView的style:UITableViewStyleGrouped類(lèi)型,默認(rèn)tableView開(kāi)頭和結(jié)尾是有間距的,不需要這個(gè)間距的話,可以通過(guò)實(shí)現(xiàn)heightForHeaderInSection方法(返回一個(gè)較小值:0.1)和viewForHeaderInSection(返回一個(gè)view)來(lái)去除頭部的留白,底部同理。

iOS 11上發(fā)生tableView頂部有留白,原因是代碼中只實(shí)現(xiàn)了heightForHeaderInSection方法,而沒(méi)有實(shí)現(xiàn)viewForHeaderInSection方法。那樣寫(xiě)是不規(guī)范的,只實(shí)現(xiàn)高度,而沒(méi)有實(shí)現(xiàn)view,但代碼這樣寫(xiě)在iOS 11之前是沒(méi)有問(wèn)題的,iOS 11之后應(yīng)該是由于開(kāi)啟了估算行高機(jī)制引起了bug。添加上viewForHeaderInSection方法后,問(wèn)題就解決了。或者添加以下代碼關(guān)閉估算行高,問(wèn)題也得到解決。

self.tableView.estimatedRowHeight = 0;

self.tableView.estimatedSectionHeaderHeight = 0;

self.tableView.estimatedSectionFooterHeight = 0;

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容