前言

iOS 11 已經(jīng)發(fā)布了一段時間了，隨手記團隊也早早的完成了適配。在這里，我們做了點總結(jié)，與大家一起分享一下關(guān)于 iOS 11 一些新特性的適配。

UIView & UIViewController

Layout Margins

iOS 11 中，官方提供了一種新的布局方法——通過 layout margins 進行布局。官方文檔 Positioning Content Within Layout Margins 稱，使用這種布局可以保證各個 content 之間不會相互覆蓋。

總的來說，layout margins 可以視作視圖的內(nèi)容和內(nèi)容之間的空隙。它由每個邊的 insetValues 組成，分別是 top, bottom, leading and trailing. 對應(yīng)的是上、下、左、右。

Auto Layout with Layout Margins

如果使用 Auto Layout 進行布局，并希望約束遵循 layout margins，那么必須要在 Xcode 中打開 Constrain to margins 選項。這樣，如果父視圖的 layout margins 改變，那么所有綁定于父視圖 margins 的子視圖都會更新布局。

注意

如果沒有開啟這個選項，那么所有建立的約束都會依賴于父視圖的 bounds.

Manually Layout with Layout Margins

如果沒有使用 Auto Layout, 而是通過設(shè)置 frame 布局的話，要遵循 layout margins 也并不困難，只需要在布局計算時使用 directionalLayoutMargins 這個屬性。

var directionalLayoutMargins: NSDirectionalEdgeInsets { get set }

官方文檔中闡述道，對于 view controller 的根視圖，它的 directionalLayoutMargins 默認值是由 systemMinimumLayoutMargins和SafeAreaInsets 決定的。在 iPhone X 下打印根視圖的這三個屬性可以看到它們的關(guān)系。

override func viewDidAppear(_ animated: Bool) {
 super.viewDidAppear(animated)
 print("SafeAreaInsets :" + "\(self.view.safeAreaInsets)")
 print("systemMinimumLayoutMargins :" + "\(self.systemMinimumLayoutMargins)")
 print("directionalLayoutMargins: " + "\(self.view.directionalLayoutMargins)")
 
 // SafeAreaInsets :UIEdgeInsets(top: 88.0, left: 0.0, bottom: 34.0, right: 0.0)
 // systemMinimumLayoutMargins :NSDirectionalEdgeInsets(top: 0.0, leading: 16.0, bottom: 0.0, trailing: 16.0)
 // directionalLayoutMargins: NSDirectionalEdgeInsets(top: 88.0, leading: 16.0, bottom: 34.0, trailing: 16.0)
}

結(jié)果顯而易見，directionalLayoutMargins 的默認值由 systemMinimumLayoutMargins 和 safeAreaInsets 組成。

注意

systemMinimumLayoutMargins 屬性是否可用由 view controller 的布爾值屬性viewRespectsSystemMinimumLayoutMargins決定，默認為true.

如果手動對 directionalLayoutMargins 賦值，那么在 viewRespectsSystemMinimumLayoutMargins 開啟的情況下，系統(tǒng)會比較賦值后的 directionalLayoutMargins 和 systemMinimumLayoutMargins ，并取其較大值作為最終的 margins。

print("systemMinimumLayoutMargins :" + "\(self.systemMinimumLayoutMargins)")
print("origin directionalLayoutMargins: " + "\(self.view.directionalLayoutMargins)")

// 這里把 leading 和 trailing 分別賦值為相對于 systemMinimumLayoutMargins 的較大值20和較小值10
self.view.directionalLayoutMargins = NSDirectionalEdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 10)
print("assigned directionalLayoutMargins: " + "\(self.view.directionalLayoutMargins)")

// 打印日志可見只有 leading 的值改變?yōu)槭謩淤x的值，trailing 依然遵循于 systemMinimumLayoutMargins
systemMinimumLayoutMargins :NSDirectionalEdgeInsets(top: 0.0, leading: 16.0, bottom: 0.0, trailing: 16.0)
origin directionalLayoutMargins: NSDirectionalEdgeInsets(top: 88.0, leading: 16.0, bottom: 34.0, trailing: 16.0)
assigned directionalLayoutMargins: NSDirectionalEdgeInsets(top: 88.0, leading: 20.0, bottom: 34.0, trailing: 16.0)

注意

如果不希望受到systemMinimumLayoutMargins的影響，那么把 view controller 的viewRespectsSystemMinimumLayoutMargins設(shè)為false即可.

Navigation bar

進入了 iOS 11，蘋果為提供了更為漂亮和醒目的大標題的樣式，如果想開啟這樣的功能，其實很簡單。
只需要將 navigation bar 中的 prefersLargeTitles 置為 true 即可，這樣便自動有了來自 iOS 11 中的大標題的樣式。

self.navigationController.navigationBar.prefersLargeTitles = true

這里可以注意到，prefersLargeTitles 是配置在的 navigation controller 中的 navigation bar 中的。也就是說該 navigation controller 容器中的所有的 view controller 在此配置之后，都會受到影響。所以如果你要在當(dāng)前的 navigation controller 中推入一個新的 view controller 的話，那么該 view controller 也會是大標題。因此為了避免這個問題，UIKit 為 UINavigationItem 提供了 largeTitleDisplayMode 屬性。

該屬性默認為 UINavigationItem.LargeTitleDisplayMode.automatic, 即保持與前面已經(jīng)顯示過的 navigation item 一致的樣式。 如果想在后來的一個 view controller 避免大標題樣式那么可以這么配置：

self.navigationItem.largeTitleDisplayMode = .never

除了大標題以外，在 iOS 11 中，UIKit 還為 navigation item 提供了便于管理搜索的接口。
具體參考如下:

self.navigationItem.searchController = self.searchController
self.navigationItem.hidesSearchBarWhenScrolling = true

在配置好你的 search controller 之后便可以直接提供給 navigation item 的 searchController屬性上，這樣的便能夠在導(dǎo)航欄看到一個漂亮的搜索框了。

此外還可以給 navigation item 中的屬性 hidesSearchBarWhenScrolling 設(shè)置為 true, 他可以使你 view controller 中管理的 scroll view 在滑動的時候自動隱藏 search bar.

Scroll view

如果使用過 view controller 管理過 scroll view 的話，想必對 automaticallyAdjustsScrollViewInsets 這個屬性一定不陌生。在 iOS 11 之前，該屬性可以讓 view controller 自動管理 scroll view 中的 content inset. 但是，在實際在開發(fā)的過程中，這樣的自動管理的方式會帶來麻煩，尤其是一些在 content inset 需要動態(tài)調(diào)整的情況。

為此，在 iOS 11, UIKit 廢棄了 automaticallyAdjustsScrollViewInsets 屬性，并將該的職責(zé)轉(zhuǎn)移到 scroll view 本身。因此，在 iOS 11 中，為了解決這個問題，有兩個 scroll view 的新屬性。一個是用于管理調(diào)整 content inset 行為的屬性 contentInsetAdjustmentBehavior, 另一個是獲取調(diào)整后的填充的屬性 adjustedContentInset. 同時，UIScrollViewDelegate 也提供了新的代理方法，以方便開發(fā)者獲取 inset 變化的時機:

optional func scrollViewDidChangeAdjustedContentInset(_ scrollView: UIScrollView)

至此，對于這個「自動為開發(fā)者設(shè)置 inset」 的特性，蘋果算是提供了相當(dāng)完備的接口了。

不過作為開發(fā)者的我們要注意的是，如果對原本自動設(shè)置 contentInset 屬性的行為有依賴，在新的 iOS 11 的適配中，可能得做出調(diào)整。

此外，為了便于開發(fā)者在 scroll view 中使用 Auto Layout. UIKit 還提供了兩個新的屬性。一個是 contentLayoutGuide, 它用來獲取當(dāng)前在 scroll view 內(nèi)的內(nèi)容的 layout guides. 而另一個是 frameLayoutGuide, 他用來獲取實際內(nèi)容的 layout guides. 這樣說有點繁瑣，還是看 WWDC 的原圖吧：

Table view

實際上對于 table view 而言，其最大的更新就在于新的特性 Drag and Drop 了吧。但是這個特性在適配中暫時不需要考慮，本文就不介紹了，讓我們一起來看看其他有意思的變化。

首先是在 iOS 11 中，table view 默認開啟了 self-sizing, 可以注意到 estimatedRowHeight, estimatedSectionHeaderHeight 以及 estimatedSectionFooterHeight 都被默認設(shè)置為 UITableViewAutomaticDimension. 但是我們知道，如果原本已經(jīng)實現(xiàn) tableView:heightForRowAtIndexPath: 之類的方法并返回了高度，那么在布局方面是不會有影響的，這對 iOS 11 適配而言是個好消息。

在 iOS 11 中，有了新的 layout margins 的概念，因此 UIKit 也為 separator inset 做了額外的補充?，F(xiàn)在 separator inset 可以有兩個來源，一個是從 cell 的邊緣開始 (UITableViewSeparatorInsetReference.fromCellEdges) ，另一個是從 table view 默認的填充開始 (UITableViewSeparatorInsetReference.fromAutomaticInsets)。其中，默認的填充由 table view 的 layout margins 進行控制。

此外，iOS 11 還為 table view 添加了更多的滑動操作的控制能力。分別可以通過以下兩個 UITableViewDelegate 的方法

實現(xiàn)：

func tableView(_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration?
func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration?

我們可以注意到兩個方法均要求返回一個 UISwipeActionsConfiguration 實例。為構(gòu)造這個實例，我們還需要構(gòu)造一個由 UIContextualAction 實例組成的數(shù)組。UIContextualAction 與原本的 UITableViewRowAction 大致類似，但是要注意在 contextual action 的參數(shù) handler 中，我們需要調(diào)用 handler 參數(shù)中的 completionHandler 才能完成操作。從這一點我們可以看到，似乎在新的 action 中，我們可以做一些異步操作相關(guān)的事情。

下面是一個刪除操作的示例:

override func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
 let contextualAction = UIContextualAction.init(style: .destructive, title: "Delete") { (style, title, completionHandler) in
  // 刪除指定的數(shù)據(jù)
  completionHandler(true)
 }
 
 let actionsConfiguration = UISwipeActionsConfiguration.init(actions: [contextualAction])
 return actionsConfiguration
}

在 swipe actions configuration 中，我們還需要注意一點，那就是新的 performsFirstActionWithFullSwipe 屬性。通過開啟這個屬性的配置（默認開啟），我們可以為第一個動作提供 full swipe 操作 (一種通過過度滑動從而觸發(fā)動作的交互) 。

如果僅僅實現(xiàn)了以往的編輯的代理方法，在 iOS 11 中，對于第一個動作將會默認支持 full swipe, 且不能關(guān)閉。

Face ID

如果已經(jīng)做過了 Touch ID 那么實際上適配 Face ID 便并不難了。即便是不做任何的改動，估計 Face ID 也是可以直接使用的（寫作時, iPhone X 還未上市），當(dāng)然相關(guān)的體驗肯定會打點折扣，畢竟文案以及相關(guān)的提示操作還是在僅有 Touch ID 的前提下實現(xiàn)的。

與以往一樣，可以通過 LAContext 類實現(xiàn)生物識別認證。不過需要注意的是，因為支持了新的 Face ID 認證，蘋果便為 LAContext 類添加了新的接口 biometryType 用于區(qū)分 Touch ID 以及 Face ID。同時，以往僅涵蓋 Touch ID 的錯誤類型，也在 iOS 11 中廢棄了，相應(yīng)的，蘋果提供了新的更通用的錯誤類型予以替代。

IOS 11 下適配UITableView

UIScrollView及其子類在IOS 11之前的版本UI顯示完全正常，但是在IOS 11上面會顯示奇葩的界面。

 （1）先看一下UITablevIew。

原本在VC里面的automaticallyAdjustsScrollViewInsets竟然過期了，在IOS 11下 APPLE推薦使用UIScrollView的contentInsetAdjustmentBehavior屬性進行設(shè)置自動計算滾動視圖的內(nèi)容邊距。

@property(nonatomic,assign) BOOL automaticallyAdjustsScrollViewInsets

在IOS11的SDK下，UIScrollView的這個屬性

@property(nonatomic) UIScrollViewContentInsetAdjustmentBehavior contentInsetAdjustmentBehavior //這個屬性是一個枚舉類型的

{

UIScrollViewContentInsetAdjustmentAutomatic,//scrollView會自動計算和適應(yīng)頂部和底部的內(nèi)邊距并且在scrollView 不可滾動時,也會設(shè)置內(nèi)邊距.

UIScrollViewContentInsetAdjustmentScrollableAxes, //自動適應(yīng)邊距

UIScrollViewContentInsetAdjustmentNever， //和 automaticallyAdjustsScrollViewInsets=NO有著同樣的效果，不計算內(nèi)邊距

UIScrollViewContentInsetAdjustmentAlways//根據(jù)safeAreaInsets （安全區(qū)域）計算內(nèi)邊距

 }

所以，在IOS 11 下，需要設(shè)置ScrollView：

 self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;

如果需要全局設(shè)置的話，需要這么設(shè)置：

if (@available(iOS 11.0, *)) {

 

 [[UIScrollView appearance] setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];

}

這樣設(shè)置后使用UITableview 、UICollectionView、UIScrollview的時候就不需要再單獨設(shè)置該屬性了，因為UIView以及他的子類都是遵循UIAppearance協(xié)議的。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

Reference

• Positioning Content Within Layout Margins
• directionalLayoutMargins
• systemMinimumLayoutMargins
• SafeAreaInsets

最新評論