之前寫了一篇適配 iOS 11 的文章鏈接，如今 iPhone X 上市后，又要掀起一波適配潮了。對于開發者來說， iPhone X 并不像之前的產品那么容易適配。因為齊劉海、虛擬 HomeIndicator，可以說是相當有特點了。那么，X 到底做了哪些改變，怎么適配，下面我們就來詳細談談。
iPhone X 的一些改變
關于 iPhone X（后文中簡稱為 X）的屏幕尺寸，由于個性的劉海以及取消了物理 Home 按鍵而用虛擬按鍵 Home Indicator 取代，所以理所當然屏幕的高度會高一些。我們知道，6、7、8的尺寸都一樣，是375 * 667 pt，而 X 的尺寸是 375 * 812 pt，寬度跟前者一樣，由于是 @3x，所以像素尺寸是1125 * 2436 px。即加長版的 iPhone 8。具體見下圖
關于細節高度變化。Status Bar 的高度由之前的 20 pt 變為 44 pt，增加了 24 pt 是為了適應劉海對頂部空間的影響。
如果沒有 Large Title，導航欄加狀態欄的總體高度是 44 + 44 = 88 pt。如果有 Large Title，總體高度達到 44 + 52 = 96 pt。這跟之前的 64 pt 還是有很大差距的。
另外，底部的虛擬鍵 Home Indicator 的高度是 34 pt，適配的時候注意內容不能跟他有視圖層疊，否則會很影響顯示效果。底部的總高度為 49 + 34 pt = 83 pt。（其中 49 為 Tab Bar 高度）。
從上面數據不難看出，X 的改變甚至比之前的 4 -> 5 的差別都大。
好消息是，大多數使用標準的、系統提供的 UI 元素（如 UINavigationBar、UITableView、UICollectionView）將會自動適配 iPhone X。背景將會延伸到屏幕的邊界，UI 元素將會被合適地放置。比如 Navigation Bar 的背景色會自動延伸到 Status Bar 中，Tab Bar 、Tool Bar 會被合適的放置在 Home Indicator 上面，其背景色也會延伸到屏幕底端。
當然，現在大多項目中的很多控件都是各種自定義，而且上述系統控件也不是百分百場景下都能適配的，所以為了完美適配 iPhone X，只能老老實實跟著筆者認識一下蘋果的這套適配方案，適配工作才可能開展的順利一些。
修改啟動圖
適配過 iPhone 4 到 iPhone 5 的開發者應該都知道，當年由于屏幕尺寸的較大變化，如果沒做適配在 iPhone 5 運行就會有大大的黑邊。解決方案就是配置啟動圖（LaunchScreen.storyboard 啟動除外）。X 也是一樣。
如果項目使用的是圖集（Launch Images Asset），直接讓設計師多做一張像素 1125 * 2436 px 的啟動圖即可。
如果是用的故事板啟動圖（Launch Screen.storyboard），則無需過多設置。
接下來，編譯運行一下項目，就沒有黑邊了，但取而代之的會看到頂部和底部擁擠的布局，那么我們下面來具體談一下怎么適配。
通過 Safe Area 來適配 X
談到適配 iOS 11 || iPhone X，不得不認識一下 Safe Area。Safe Area 的出現也是為了給適配 iPhone X 工作提供方便。這部分我會盡可能詳細介紹一下 Safe Area，掌握了 Safe Area，也就基本完成了 X 的 UI 適配工作。
認識 Safe Area 之前，我們先花兩分鐘時間復習一下 topLayoutGuide 和 bottomLayoutGuide。
iOS 7 之后蘋果給 UIViewController 引入了 topLayoutGuide 和 bottomLayoutGuide，目的就是保護內容不被各種 Bar 遮擋，如（StatusBar, NavBar, ToolBar, TabBar）。這個屬性有一個 length 值( 如 topLayoutGuide.length)，這個值可能由當前的 ViewController 或者 NavigationController 或者 TabbarController 決定。
一個獨立的ViewController，不包含于任何其他的ViewController。如果狀態欄可見，topLayoutGuide表示狀態欄的底部，否則表示這個ViewController的上邊緣。
包含于其他ViewController的ViewController不對這個屬性起決定作用，而是由容器ViewController決定這個屬性的含義：
如果導航欄（Navigation Bar）可見，topLayoutGuide表示導航欄的底部。
如果狀態欄可見，topLayoutGuide表示狀態欄的底部。
如果都不可見，表示ViewController的上邊緣。
這部分還比較好理解，總之是屏幕上方任何遮擋內容的欄的最底部。
這兩個屬性是 VC 的屬性，平常用的場景可能不是太多。但是僅僅描述上和下的安全內邊距在 iPhone X 之前是足夠使用的，因為不管橫屏還是豎屏，只需知道上下安全內邊距即可。但是在 X 上就行不通了，豎屏狀態大多場景下還好，可是橫屏情況下，要想適配酷酷的劉海和 Home Indicator，僅僅這兩個屬性就力不從心了。蘋果只好重新構思這塊代碼，自然就有了SafeArea 的解決方案（相信如果讓你來設計這塊代碼來幫助廣大開發者適配 X ，也應該很快想到類似方案）。
SafeArea，顧名思義，是安全區域。原則上所有的控制視圖都應該在這上面繪制，超出這個區域就會有可能被 NavBar 或 StatusBar 或 ToolBar 或 Home Indicator 等遮擋而影響交互體驗。看下面這張官方文檔的示例圖：
在 iOS 11 中，蘋果置過期了上面的控制器 VC 屬性 top/bottomLayoutGuide，取而代之的是 View 屬性 safeAreaLayoutGuide，safeAreaInsets。下面就細細說一下蘋果的這套 SafeArea 解決方案如何。
我們先說一下safeAreaInsets。
SafeAreaInsets
顧名思義，它就是安全區域的內邊距。
簡而言之，它的值是（StatusBarHeight + NavBarHeight, 0, HomeIndicatorHeight + TabBarHeight, 0）
在 X 上運行，即（44 + 44， 0， 34 + 49， 0）。（當然，上面的公式中的控件都沒有隱藏。）
但是要注意，SafeAreaInsets這個屬性的取用時機要當心。在ViewDidLoad中這個值是 zero 的，通過下面打印，可以看出端倪
viewDidLoad => {0, 0, 0, 0}
viewWillAppear: =>{0, 0, 0, 0}
viewSafeAreaInsetsDidChange =>{44, 0, 34, 0}
viewWillLayoutSubviews =>{44, 0, 34, 0}
viewDidLayoutSubviews =>{44, 0, 34, 0}
viewDidAppear: =>{44, 0, 34, 0}
綜上，可以在viewSafeAreaInsetsDidChange方法中取值（view也有個類似方法，safeAreaInsetsDidChange），也可以在viewWillLayoutSubviews取值。
我們如果之前用過 top/bottomLayoutGuide，就會很自然就知道了SafeAreaInsets的用法。很類似，這個屬性就是告訴開發者，添加的控件最好在這個安全內邊距區域內。view.safeAreaLayoutGuide.layoutFrame就是通過該內邊距計算獲得。
- 用 Xib 創建視圖的話，如果是 iOS 9 +，那么很簡單直接將控件的相對布局對象改為
safe area即可。 - 如果不是 Xib 視圖，或者要支持 iOS 8 +，那么用代碼也很簡單。以控制器為例，向控制器視圖中添加子控件布局的時候，布局不要直接以 View 為參照視圖，要用到
SafeAreaInsetsUIEdgeInsets insets = self.view.safeAreaInsets; [label mas_makeConstraints:^(MASConstraintMaker *make) { // ... make.bottom.mas_equalTo(-insets.bottom); }];
AdditionalSafeAreaInsets
當 view controller 的子視圖覆蓋了嵌入的子 view controller 的視圖的時候。比如說， 當 UINavigationController 和 UITabbarController 中的 bar 是半透明(translucent) 狀態的時候, 就有 additionalSafeAreaInsets。
You might use this property to extend the safe area to include custom content in your interface. For example, a drawing app might use this property to avoid displaying content underneath tool palettes.
官方文檔舉的例子是在一個畫畫 App 中通過該屬性來延伸安全區域，從而避免畫筆畫到了畫板上。
注意這個屬性是在原來的基礎上疊加多少，不是改為了多少。
