隨手記 iOS 11 適配實踐總結

隨手記技術團隊發表於2017-11-07
iOS

歡迎關注微信公眾號「隨手記技術團隊」，檢視更多隨手記團隊的技術文章。
本文作者：丁同舟、王博文
原文連結：mp.weixin.qq.com/s/rP_ryWL2r…

iOS 11 已經發布了一段時間了，隨手記團隊也早早的完成了適配。在這裡，我們做了點總結，與大家一起分享一下，關於 iOS 11 一些新特性的適配。

UIView & UIViewController

Layout Margins

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

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

View's Margin
View's Margin

Auto Layout with Layout Margins

如果使用 Auto Layout 進行佈局，並希望約束遵循 layout margins，那麼必須要在 Xcode 中開啟 Constrain to margins 選項。這樣，如果父檢視的 layout margins 改變，那麼所有繫結於父檢視 margins 的子檢視都會更新佈局。

開啟Constrain to margins選項
開啟Constrain to margins選項

注意

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

Manually Layout with Layout Margins

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

var directionalLayoutMargins: NSDirectionalEdgeInsets { get set }複製程式碼

官方文件中闡述道，對於 view controller 的根檢視，它的 directionalLayoutMargins 預設值是由 systemMinimumLayoutMargins和SafeAreaInsets 決定的。在 iPhone X 下列印根檢視的這三個屬性可以看到它們的關係。

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)
}複製程式碼

結果顯而易見，directionalLayoutMargins 的預設值由 systemMinimumLayoutMargins 和 safeAreaInsets 組成。

注意

systemMinimumLayoutMargins 屬性是否可用由 view controller 的布林值屬性viewRespectsSystemMinimumLayoutMargins決定，預設為true.

如果手動對 directionalLayoutMargins 賦值，那麼在 viewRespectsSystemMinimumLayoutMargins 開啟的情況下，系統會比較賦值後的 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 的值改變為手動賦的值，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設為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 在此配置之後，都會受到影響。所以如果你要在當前的 navigation controller 中推入一個新的 view controller 的話，那麼該 view controller 也會是大標題。因此為了避免這個問題，UIKit 為 UINavigationItem 提供了 largeTitleDisplayMode 屬性。

該屬性預設為 UINavigationItem.LargeTitleDisplayMode.automatic, 即保持與前面已經顯示過的 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 屬性上，這樣的便能夠在導航欄看到一個漂亮的搜尋框了。
此外還可以給 navigation item 中的屬性 hidesSearchBarWhenScrolling 設定為 true, 他可以使你 view controller 中管理的 scroll view 在滑動的時候自動隱藏 search bar.

Scroll view

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

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

optional func scrollViewDidChangeAdjustedContentInset(_ scrollView: UIScrollView)複製程式碼

至此，對於這個「自動為開發者設定 inset」 的特性，蘋果算是提供了相當完備的介面了。

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

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

scroll-view-example-1
scroll-view-example-1

Table view

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

首先是在 iOS 11 中，table view 預設開啟了 self-sizing, 可以注意到 estimatedRowHeight, estimatedSectionHeaderHeight 以及 estimatedSectionFooterHeight 都被預設設定為 UITableViewAutomaticDimension. 但是我們知道，如果原本已經實現 tableView:heightForRowAtIndexPath: 之類的方法並返回了高度，那麼在佈局方面是不會有影響的，這對 iOS 11 適配而言是個好訊息。

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

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

func tableView(_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration?
func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration?複製程式碼

我們可以注意到兩個方法均要求返回一個 UISwipeActionsConfiguration 例項。為構造這個例項，我們還需要構造一個由 UIContextualAction 例項組成的陣列。UIContextualAction 與原本的 UITableViewRowAction 大致類似，但是要注意在 contextual action 的引數 handler 中，我們需要呼叫 handler 引數中的 completionHandler 才能完成操作。從這一點我們可以看到，似乎在新的 action 中，我們可以做一些非同步操作相關的事情。
下面是一個刪除操作的示例:

override func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
    let contextualAction = UIContextualAction.init(style: .destructive, title: "Delete") { (style, title, completionHandler) in
        // 刪除指定的資料
        completionHandler(true)
    }

    let actionsConfiguration = UISwipeActionsConfiguration.init(actions: [contextualAction])
    return actionsConfiguration
}複製程式碼

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

如果僅僅實現了以往的編輯的代理方法，在 iOS 11 中，對於第一個動作將會預設支援 full swipe, 且不能關閉。

Face ID

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

與以往一樣，可以通過 LAContext 類實現生物識別認證。不過需要注意的是，因為支援了新的 Face ID 認證，蘋果便為 LAContext 類新增了新的介面 biometryType 用於區分 Touch ID 以及 Face ID。同時，以往僅涵蓋 Touch ID 的錯誤型別，也在 iOS 11 中廢棄了，相應的，蘋果提供了新的更通用的錯誤型別予以替代。

Reference

Positioning Content Within Layout Margins

directionalLayoutMargins

systemMinimumLayoutMargins

SafeAreaInsets

相關文章