iOS開發(fā)--iOS11&&iPhoneX適配

一、前言

iOS11發(fā)布也有一段時(shí)間了，每次版本升級(jí)，相關(guān)的適配工作當(dāng)然是下個(gè)版本的核心工作之一。而且這次iOS11的更新，相對(duì)于iOS10的更新來說，改動(dòng)點(diǎn)還是比較多的。除了iOS11系統(tǒng)的更新之外，iPhoneX劉海的打理工作也是必不可少。以前我們總是慶幸作為iOS開發(fā)者，不必像Android開發(fā)者需要考慮各種不同機(jī)型的適配問題。但是現(xiàn)在，隨著iPhone各種歷史版本的存在，各種花式的新版本產(chǎn)生，不同版本之間的適配問題，也是未來我們作為iOS開發(fā)者必然要考慮的重要問題之一。

這次我主要負(fù)責(zé)我們這邊兩款A(yù)pp(滴滴代駕司機(jī)端+駕管App)iOS11&iPhoneX適配工作。中間也躺過很多坑，一一記錄了下來寫成這篇文章，既是對(duì)自己工作的一次總結(jié)，也可以分享給其他iOS開發(fā)者，能夠讓大家少趟一些坑。

本文將分為三個(gè)部分，分別從三方庫適配、UI適配、權(quán)限適配、補(bǔ)充知識(shí)等方面分別進(jìn)行展開。

二、三方庫適配問題。

2.1 CocoaLumberjack 編譯出錯(cuò)

1.png

CocoaLumberjack編譯報(bào)錯(cuò)

問題原因：

從錯(cuò)誤提示可以看出在Xcode9中os_log_error的第二個(gè)參數(shù)format必須要為不可變的string類型，而不是char*。

解決方案：

我們只要改成如下形式就可以了
os_log_error(OS_LOG_DEFAULT, "%s", msg);

如果你的工程是pod依賴的話，將pod版本升級(jí)到3.3.0版本即可。

2.2 WebViewJavascriptBridge崩潰處理

我們代駕司機(jī)端web容器使用的是WKWebView，jsBridge使用的是WebViewJavascriptBridge這個(gè)三方庫，更新到Xcode9之后，只要進(jìn)入WKWebView容器，就會(huì)產(chǎn)生如下crash:

1.png

WebViewJavascriptBridge crash

問題原因：

當(dāng)你使用WKWebView作為你的H5容器的時(shí)候，WKNavigationDelegate有個(gè)回調(diào)就是

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void(^)(WKNavigationActionPolicy))decisionHandler;

這個(gè)回調(diào)主要負(fù)責(zé)根據(jù)webView、navigationAction相關(guān)信息決定這次跳轉(zhuǎn)是否可以繼續(xù)進(jìn)行。調(diào)用decisionHandler(WKNavigationActionPolicyAllow);響應(yīng)這次跳轉(zhuǎn)請(qǐng)求。調(diào)用decisionHandler(WKNavigationActionPolicyCancel);就是不響應(yīng)這次跳轉(zhuǎn)請(qǐng)求。

查看WebViewJavascriptBridge源碼可以看出，在WKWebViewJavascriptBridge.m文件中

WKVebViewCrash.png

在Xcode9中，如果連續(xù)看了兩次調(diào)用decisionHandler方法就會(huì)crash。這個(gè)問題在之前版本的Xcode均是沒有問題的。

解決方案：

  • 方案一：修改源碼

    在上面代碼的149行和150行之間添加return;

  • 方案二：pod依賴，原作者沒有修改此問題，無法修改源碼，也可以在業(yè)務(wù)代碼中進(jìn)行規(guī)避。

    在你自己業(yè)務(wù)代碼的對(duì)應(yīng)對(duì)調(diào)中添加排除代碼，如下：

WKWebViewCrash2.png

2.3 LumberjackConsole UI適配

1.png

問題原因:

iOS7之后，如何你設(shè)置self.edgesForExtendedLayout = UIRectEdgeNone的話,系統(tǒng)通過設(shè)置UIViewController的automaticallyAdjustsScrollViewInsets屬性來自動(dòng)調(diào)整UIScrollView的contentInset，使UIscrollView能夠呈現(xiàn)在我們的可是范圍之內(nèi)，而不會(huì)被navBar擋住。這個(gè)屬性在iOS11中被廢棄掉了，在iOS11中代替該屬性功能的則是UIScrollView類中的contentInsetAdjustmentBehavior和adjustedContentInset屬性.在iOS11中用來決定scrollView超出安全區(qū)域與邊緣距離的屬性是adjustedContentInset而不是contentInset。當(dāng)scrollView超出安全區(qū)域時(shí)系統(tǒng)會(huì)自動(dòng)調(diào)整SafeAreaInsets值，進(jìn)而影

響 adjustedContentInset，所以導(dǎo)致scrollView下移20pt或者64pt。當(dāng)使用自定義的 navigationbar，并且scrollView的frame超出安全區(qū)域，SafeAreaInsets為(20,0,0,0);當(dāng)使用系統(tǒng)的navigationbar，SafeAreaInsets為(64,0,0,0)。

解決方案:

在UIScrollView或者UITableView初始化的地方，加入如下代碼即可。

針對(duì)LumberjackConsole這個(gè)開源庫，我們可以在PTEConsoleTableView.m文件中的commonInit最后加入如下代碼即可。

if([self respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]){
[self setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];
}

三、UI適配

3.1 NavBar中右上角的customView產(chǎn)生偏移

1.png

問題原因:

在iOS11中，新的導(dǎo)航視圖，使用了AutoLayout布局。而我們這邊右上角的兩個(gè)按鈕組合成一個(gè)customView，然后把這個(gè)customView設(shè)置給setRightBarButtonItems而來。customView內(nèi)部都是frame布局，所以在自動(dòng)布局下面出錯(cuò)。

解決方案:

NavBar中的customView里面針對(duì)iOS11，均要采用自動(dòng)布局。

1.png

3.2 NavBar中自定義TitleView產(chǎn)生偏移

1.png

問題原因:

同上

解決方案:

同上

這里需要注意一點(diǎn)，自動(dòng)布局的UI是延遲設(shè)置frame的。如果aView采用自動(dòng)布局。然后你馬上調(diào)用它的aView.bounds是不正確的。

3.3 NavBar中按鈕的響應(yīng)區(qū)域都變小了。

1.png

問題原因:

iOS11之前，雖然我們?cè)O(shè)置了NavBar上每一個(gè)[btn sizeToFit]。蘋果依然會(huì)幫我們把每一個(gè)按鈕的點(diǎn)擊區(qū)域擴(kuò)大，可以點(diǎn)擊區(qū)域如上圖綠色區(qū)域所示。但是在iOS11中，你的按鈕的bounds為多大，那你的點(diǎn)擊區(qū)域就只有多大。估計(jì)這個(gè)改動(dòng)也與這次NavBar的大概有關(guān)系。

解決方案:

擴(kuò)大每一個(gè)btn的bounds，而不要使用sizeToFit方法。

3.4 NavBar的BarButtonItem無法貼邊。有（非plus手機(jī)16pt，plus手機(jī)20pt）的區(qū)域浪費(fèi)。造成UI偏移，并且最左側(cè)和最右側(cè)區(qū)域無法點(diǎn)擊。

1.png

問題原因:

這個(gè)UINavigationBarContentView平鋪在導(dǎo)航欄中作為iOS11的各個(gè)按鈕的父視圖,該視圖的所有的子視圖都會(huì)有一個(gè)layoutMargins被占用,也就是系統(tǒng)調(diào)整的占位。

解決方案:

去掉系統(tǒng)默認(rèn)占位。

系統(tǒng)并沒有提供我們直接去掉系統(tǒng)默認(rèn)占位的方法，那怎么做呢？

我們新建一個(gè)UINavigationBar的分類，hook住UINavigationBar的layoutSubviews方法。然后遍歷View，重新設(shè)置layoutMargin約束。

1.png

重新設(shè)置layoutMargin約束

3.5 UITableView 默認(rèn)開啟Self-Sizing，導(dǎo)致UI顯示有問題。

1.png

問題原因:

在iOS11中UITableView會(huì)默認(rèn)使 Self-Sizing,這會(huì)導(dǎo)致tableView

的 estimatedRowHeight 、 estimatedSectionHeaderHeight 、 estimatedSectionFooterHeight 的高度估算屬性由默認(rèn)的0變成 UITableViewAutomaticDimension ,reloadData時(shí)可能會(huì)導(dǎo)致最后顯示的contentSize與預(yù)想的不一致;

同時(shí)在iOS11中如果不實(shí)現(xiàn) -tableView: viewForHeaderInSection: 和 tableView: viewForFooterInSection: 方法，則 -tableView: heightForHeaderInSection: 和 - tableView: heightForFooterInSection: 不會(huì)被調(diào)用，而iOS11之前則沒問題。上述都可能會(huì)導(dǎo)致界面出現(xiàn)錯(cuò)亂。

解決方案:

單獨(dú)關(guān)閉摸一個(gè)UITableView的Self-Sizing。

_tableView.estimatedRowHeight = 0;

_tableView.estimatedSectionFooterHeight = 0;

_tableView.estimatedSectionHeaderHeight = 0;

關(guān)閉所有的UIScroolView、UITableView和UICollectionView的Self-Sizing：

UIScrollView.appearance.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;

UITableView.appearance.estimatedRowHeight = 0;

UITableView.appearance.estimatedSectionFooterHeight = 0;

UITableView.appearance.estimatedSectionHeaderHeight = 0;

3.6 keyWindow獲取錯(cuò)誤, 導(dǎo)致UI問題。

1.png

問題原因:

機(jī)器貓圖標(biāo)是一個(gè)UIWindow，windowLevel級(jí)別比UIWindowLevelStatusBar還高，所以可以常駐UI最上方。第一次進(jìn)入該頁面，點(diǎn)擊“更多”，彈出popView，點(diǎn)擊收藏，彈出系統(tǒng)UIAlertView，此時(shí)UIAlertView變成了keyWindow。當(dāng)UIAlertView消失的時(shí)候，keyWindow會(huì)被誰接管呢？

iOS11之前，彈出UIAlertView之前的keyWindow是[[UIApplication sharedApplication].delegate window]，那么消失的時(shí)候，keyWindow還是[[UIApplication sharedApplication].delegate window]。

iOS11, 彈出UIAlertView之前的keyWindow是[[UIApplication sharedApplication].delegate window]，那么消失的時(shí)候，keyWindow變成z軸最高的UIWindow，即變成了機(jī)器貓那個(gè)window。所以導(dǎo)致popView被添加到機(jī)器貓window中，造成UI樣式問題。

解決方案:

重寫自定義UIWindow的becomeKeyWindow的方法，每次自定義window將會(huì)變?yōu)閗eyWindow的時(shí)候，把keyWindow改成[[UIApplication sharedApplication].delegate window]。

- (void)becomeKeyWindow{

UIWindow *appWindow = [[UIApplication sharedApplication].delegate window];

[appWindow makeKeyWindow];

}

3.7 狀態(tài)欄高度寫死為20pt，導(dǎo)致在iPhoneX上面遮擋住statusBar。

1.png

問題原因:

iPhoneX上的statusBar的高度為44pt，跟其他iPhone型號(hào)的20pt不一樣。所以以后我們?cè)谝詓tatusBar為定位點(diǎn)的時(shí)候，不能寫死20pt。而要使用[UIApplication sharedApplication].statusBarFrame.size.height來獲取，為了方便，可以定義為宏，放到pch文件中，如下：

#define kApplicationStatusBarHeight [UIApplication sharedApplication].statusBarFrame.size.height//狀態(tài)欄的高度`

解決方案:

狀態(tài)欄高度定位的時(shí)候不要寫死20，要使用[UIApplication sharedApplication].statusBarFrame.size.height來獲取。

補(bǔ)充

iOS11之前導(dǎo)航欄默認(rèn)高度為64pt(這里高度指statusBar + NavigationBar)，iOS11之后如果設(shè)置 prefersLargeTitles = YES則為96pt，默認(rèn)情況下還是64pt，但在iPhoneX上由于劉海的出現(xiàn) statusBar由以前的20pt變成 44pt，所以iPhoneX上高度變?yōu)?8pt，如果項(xiàng)目里隱藏了導(dǎo)航欄加了自定義按鈕之類的，這里需要注意適配一下。

3.8 通過遍歷statusBar的subviews中的UIStatusBarDataNetworkItemView獲取網(wǎng)絡(luò)狀態(tài)在iPhoneX上會(huì)crash。

問題原因:

之前我們采用遍歷statusBar，獲取UIStatusBarDataNetworkItemView實(shí)例，再獲取網(wǎng)絡(luò)狀態(tài)的。代碼如下：
+ (NSNumber *) dataNetworkTypeFromStatusBar {

UIApplication *app = [UIApplication sharedApplication];

NSArray *subviews = [[[app valueForKey:@"statusBar"] valueForKey:@"foregroundView"] subviews];

NSNumber *dataNetworkItemView = nil;

@try{

if ([subviews count] > 0) {

for (id subview in subviews) {

if([subview isKindOfClass:[NSClassFromString(@"UIStatusBarDataNetworkItemView") class]]) {

dataNetworkItemView = subview;

break;

}

}

}

}

@catch(NSException *exception) {

}

@finally {

}

return [dataNetworkItemView valueForKey:@"dataNetworkType"];

}

|

但是在iphoneX的statusBar的內(nèi)部結(jié)構(gòu)已經(jīng)改變，不能根據(jù)遍歷獲取UIStatusBarDataNetworkItemView的狀態(tài)獲取網(wǎng)絡(luò)狀態(tài)狀態(tài)。

可以通過po [statusBar recursiveDescription]打印出來iphoneX內(nèi)部結(jié)構(gòu)了，可以看出變化非常的大。

解決方案:

使用AFNetworking中的AFNetworkReachabilityManager類，或者使用Reachability庫獲取網(wǎng)絡(luò)連接狀態(tài)。

四、權(quán)限適配

4.1 無法獲取定位信息，第一次打開app也無法彈出定位權(quán)限提示框

問題原因:

iOS11 定位相關(guān)的權(quán)限做了更改，在iOS11上使用了新的定位權(quán)限key。

解決方案:

如果原來申請(qǐng)的權(quán)限是始終允許NSLocationAlwaysUsageDescription，那么需要在保留原來的key的基礎(chǔ)上增加NSLocationWhenInUseUsageDescription和NSLocationAlwaysAndWhenInUsageDescription。

五、其他一些補(bǔ)充

5.1 如何判斷該設(shè)備是不是iPhoneX

1.png

5.2 一些常用的宏定義

#define IS_IPHONE_X [KDDeviceHelper is_iPhone_X]

#define IPHONE_NAVIGATIONBAR_HEIGHT (IS_IPHONE_X ? 88: 64)

#define IPHONE_STATUSBAR_HEIGHT (IS_IPHONE_X ? 44: 20)

#define IPHONE_SAFEBOTTOMAREA_HEIGHT (IS_IPHONE_X ? 34: 0)

#define IPHONE_TOPSENSOR_HEIGHT (IS_IPHONE_X ? 32: 0)

轉(zhuǎn)發(fā)自此文特此聲明，如有問題，請(qǐng)聯(lián)系我！

?著作權(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)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

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

  • 編譯器升級(jí)xcode9，準(zhǔn)備適配一下iphoneX的布局，調(diào)試時(shí)發(fā)現(xiàn)由于一些ios11新特性或者底層變化的原因，x...
    YY程序猿閱讀 3,993評(píng)論 4贊 28
  • 一、前言 iOS11發(fā)布也有一段時(shí)間了，每次版本升級(jí)，相關(guān)的適配工作當(dāng)然是下個(gè)版本的核心工作之一。而且這次iOS1...
    景銘巴巴閱讀 11,151評(píng)論 8贊 105
  • 一.iPhone X尺寸問題 1. 高度增加了145pt，變成812pt. 2.屏幕圓角顯示，注意至少留10pt邊...
    騎行天下閱讀 13,260評(píng)論 5贊 36
  • 博客傳送門前陣子項(xiàng)目開發(fā)忙成狗，就一直沒做iOS11的適配，直到XcodeGM版發(fā)布后，我胸有成竹的在iPhone...
    張?jiān)掳?/span>閱讀 30,189評(píng)論 55贊 239
  • 相信大家已經(jīng)被iPhoneX的劉海洗腦了，除了吐槽，留給我們的還有比較麻煩的適配工作。下面針對(duì)在整理過程中發(fā)現(xiàn)的適...
    smile麗語閱讀 5,019評(píng)論 6贊 21

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