一、前言
iOS11發(fā)布也有一段時間了立镶，每次版本升級壁袄，相關的適配工作當然是下個版本的核心工作之一。而且這次iOS11的更新谜慌，相對于iOS10的更新來說然想，改動點還是比較多的。除了iOS11系統(tǒng)的更新之外欣范，iPhoneX劉海的打理工作也是必不可少。以前我們總是慶幸作為iOS開發(fā)者令哟，不必像Android開發(fā)者需要考慮各種不同機型的適配問題恼琼。但是現(xiàn)在，隨著iPhone各種歷史版本的存在屏富，各種花式的新版本產(chǎn)生晴竞，不同版本之間的適配問題，也是未來我們作為iOS開發(fā)者必然要考慮的重要問題之一狠半。
這次我主要負責我們這邊兩款App(滴滴代駕司機端+駕管App)iOS11&iPhoneX適配工作噩死。中間也躺過很多坑，一一記錄了下來寫成這篇文章神年，既是對自己工作的一次總結(jié)已维，也可以分享給其他iOS開發(fā)者，能夠讓大家少趟一些坑已日。
本文將分為三個部分垛耳，分別從三方庫適配、UI適配飘千、權(quán)限適配堂鲜、補充知識等方面分別進行展開。
二护奈、三方庫適配問題缔莲。
2.1 CocoaLumberjack 編譯出錯
CocoaLumberjack編譯報錯
問題原因：
從錯誤提示可以看出在Xcode9中os_log_error的第二個參數(shù)format必須要為不可變的string類型，而不是char*霉旗。
解決方案：
我們只要改成如下形式就可以了
os_log_error(OS_LOG_DEFAULT, "%s", msg);
如果你的工程是pod依賴的話痴奏，將pod版本升級到3.3.0版本即可磺箕。
2.2 WebViewJavascriptBridge崩潰處理
我們代駕司機端web容器使用的是WKWebView，jsBridge使用的是WebViewJavascriptBridge這個三方庫抛虫，更新到Xcode9之后松靡，只要進入WKWebView容器，就會產(chǎn)生如下crash:
WebViewJavascriptBridge crash
問題原因：
當你使用WKWebView作為你的H5容器的時候建椰，WKNavigationDelegate有個回調(diào)就是
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void(^)(WKNavigationActionPolicy))decisionHandler;
這個回調(diào)主要負責根據(jù)webView雕欺、navigationAction相關信息決定這次跳轉(zhuǎn)是否可以繼續(xù)進行。調(diào)用decisionHandler(WKNavigationActionPolicyAllow);響應這次跳轉(zhuǎn)請求棉姐。調(diào)用decisionHandler(WKNavigationActionPolicyCancel);就是不響應這次跳轉(zhuǎn)請求屠列。
查看WebViewJavascriptBridge源碼可以看出，在WKWebViewJavascriptBridge.m文件中
在Xcode9中伞矩，如果連續(xù)看了兩次調(diào)用decisionHandler方法就會crash笛洛。這個問題在之前版本的Xcode均是沒有問題的。
解決方案：
-
方案一：修改源碼
在上面代碼的149行和150行之間添加return;
-
方案二：pod依賴乃坤，原作者沒有修改此問題苛让，無法修改源碼，也可以在業(yè)務代碼中進行規(guī)避湿诊。
在你自己業(yè)務代碼的對應對調(diào)中添加排除代碼狱杰，如下：
2.3 LumberjackConsole UI適配
問題原因:
iOS7之后，如何你設置self.edgesForExtendedLayout = UIRectEdgeNone的話,系統(tǒng)通過設置UIViewController的automaticallyAdjustsScrollViewInsets屬性來自動調(diào)整UIScrollView的contentInset厅须，使UIscrollView能夠呈現(xiàn)在我們的可是范圍之內(nèi)仿畸，而不會被navBar擋住。這個屬性在iOS11中被廢棄掉了朗和，在iOS11中代替該屬性功能的則是UIScrollView類中的contentInsetAdjustmentBehavior和adjustedContentInset屬性.在iOS11中用來決定scrollView超出安全區(qū)域與邊緣距離的屬性是adjustedContentInset而不是contentInset错沽。當scrollView超出安全區(qū)域時系統(tǒng)會自動調(diào)整SafeAreaInsets值，進而影
響 adjustedContentInset眶拉，所以導致scrollView下移20pt或者64pt千埃。當使用自定義的 navigationbar，并且scrollView的frame超出安全區(qū)域镀层，SafeAreaInsets為(20,0,0,0);當使用系統(tǒng)的navigationbar镰禾，SafeAreaInsets為(64,0,0,0)。
解決方案:
在UIScrollView或者UITableView初始化的地方唱逢，加入如下代碼即可吴侦。
針對LumberjackConsole這個開源庫，我們可以在PTEConsoleTableView.m文件中的commonInit最后加入如下代碼即可坞古。
if([self respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]){
[self setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];
}
三备韧、UI適配
3.1 NavBar中右上角的customView產(chǎn)生偏移
問題原因:
在iOS11中，新的導航視圖痪枫，使用了AutoLayout布局织堂。而我們這邊右上角的兩個按鈕組合成一個customView叠艳，然后把這個customView設置給setRightBarButtonItems而來。customView內(nèi)部都是frame布局易阳，所以在自動布局下面出錯附较。
解決方案:
NavBar中的customView里面針對iOS11，均要采用自動布局潦俺。
3.2 NavBar中自定義TitleView產(chǎn)生偏移
問題原因:
同上
解決方案:
同上
這里需要注意一點拒课，自動布局的UI是延遲設置frame的。如果aView采用自動布局。然后你馬上調(diào)用它的aView.bounds是不正確的。
3.3 NavBar中按鈕的響應區(qū)域都變小了讥巡。
問題原因:
iOS11之前，雖然我們設置了NavBar上每一個[btn sizeToFit]卢鹦。蘋果依然會幫我們把每一個按鈕的點擊區(qū)域擴大，可以點擊區(qū)域如上圖綠色區(qū)域所示劝堪。但是在iOS11中冀自，你的按鈕的bounds為多大，那你的點擊區(qū)域就只有多大幅聘。估計這個改動也與這次NavBar的大概有關系凡纳。
解決方案:
擴大每一個btn的bounds，而不要使用sizeToFit方法帝蒿。
3.4 NavBar的BarButtonItem無法貼邊。有（非plus手機16pt巷怜，plus手機20pt）的區(qū)域浪費葛超。造成UI偏移，并且最左側(cè)和最右側(cè)區(qū)域無法點擊延塑。
問題原因:
這個UINavigationBarContentView平鋪在導航欄中作為iOS11的各個按鈕的父視圖,該視圖的所有的子視圖都會有一個layoutMargins被占用,也就是系統(tǒng)調(diào)整的占位绣张。
解決方案:
去掉系統(tǒng)默認占位。
系統(tǒng)并沒有提供我們直接去掉系統(tǒng)默認占位的方法关带，那怎么做呢侥涵？
我們新建一個UINavigationBar的分類，hook住UINavigationBar的layoutSubviews方法宋雏。然后遍歷View芜飘，重新設置layoutMargin約束。
重新設置layoutMargin約束
3.5 UITableView 默認開啟Self-Sizing磨总，導致UI顯示有問題嗦明。
問題原因:
在iOS11中UITableView會默認使 Self-Sizing,這會導致tableView
的 estimatedRowHeight 、 estimatedSectionHeaderHeight 蚪燕、 estimatedSectionFooterHeight 的高度估算屬性由默認的0變成 UITableViewAutomaticDimension ,reloadData時可能會導致最后顯示的contentSize與預想的不一致;
同時在iOS11中如果不實現(xiàn) -tableView: viewForHeaderInSection: 和 tableView: viewForFooterInSection: 方法娶牌，則 -tableView: heightForHeaderInSection: 和 - tableView: heightForFooterInSection: 不會被調(diào)用奔浅，而iOS11之前則沒問題。上述都可能會導致界面出現(xiàn)錯亂诗良。
解決方案:
單獨關閉摸一個UITableView的Self-Sizing汹桦。
_tableView.estimatedRowHeight = 0;
_tableView.estimatedSectionFooterHeight = 0;
_tableView.estimatedSectionHeaderHeight = 0;
關閉所有的UIScroolView、UITableView和UICollectionView的Self-Sizing：
UIScrollView.appearance.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
UITableView.appearance.estimatedRowHeight = 0;
UITableView.appearance.estimatedSectionFooterHeight = 0;
UITableView.appearance.estimatedSectionHeaderHeight = 0;
3.6 keyWindow獲取錯誤, 導致UI問題鉴裹。
問題原因:
機器貓圖標是一個UIWindow舞骆，windowLevel級別比UIWindowLevelStatusBar還高，所以可以常駐UI最上方壹罚。第一次進入該頁面葛作，點擊“更多”，彈出popView猖凛，點擊收藏赂蠢，彈出系統(tǒng)UIAlertView，此時UIAlertView變成了keyWindow辨泳。當UIAlertView消失的時候虱岂，keyWindow會被誰接管呢？
iOS11之前菠红，彈出UIAlertView之前的keyWindow是[[UIApplication sharedApplication].delegate window]第岖，那么消失的時候，keyWindow還是[[UIApplication sharedApplication].delegate window]试溯。
iOS11, 彈出UIAlertView之前的keyWindow是[[UIApplication sharedApplication].delegate window]蔑滓，那么消失的時候，keyWindow變成z軸最高的UIWindow遇绞，即變成了機器貓那個window键袱。所以導致popView被添加到機器貓window中，造成UI樣式問題摹闽。
解決方案:
重寫自定義UIWindow的becomeKeyWindow的方法蹄咖，每次自定義window將會變?yōu)閗eyWindow的時候，把keyWindow改成[[UIApplication sharedApplication].delegate window]付鹿。
- (void)becomeKeyWindow{
UIWindow *appWindow = [[UIApplication sharedApplication].delegate window];
[appWindow makeKeyWindow];
}
3.7 狀態(tài)欄高度寫死為20pt澜汤，導致在iPhoneX上面遮擋住statusBar。
問題原因:
iPhoneX上的statusBar的高度為44pt舵匾，跟其他iPhone型號的20pt不一樣俊抵。所以以后我們在以statusBar為定位點的時候，不能寫死20pt纽匙。而要使用[UIApplication sharedApplication].statusBarFrame.size.height來獲取务蝠，為了方便，可以定義為宏，放到pch文件中馏段，如下：
#define kApplicationStatusBarHeight [UIApplication sharedApplication].statusBarFrame.size.height//狀態(tài)欄的高度`
解決方案:
狀態(tài)欄高度定位的時候不要寫死20轩拨，要使用[UIApplication sharedApplication].statusBarFrame.size.height來獲取。
補充
iOS11之前導航欄默認高度為64pt(這里高度指statusBar + NavigationBar)院喜，iOS11之后如果設置 prefersLargeTitles = YES則為96pt亡蓉，默認情況下還是64pt，但在iPhoneX上由于劉海的出現(xiàn) statusBar由以前的20pt變成 44pt喷舀，所以iPhoneX上高度變?yōu)?8pt砍濒，如果項目里隱藏了導航欄加了自定義按鈕之類的，這里需要注意適配一下硫麻。
3.8 通過遍歷statusBar的subviews中的UIStatusBarDataNetworkItemView獲取網(wǎng)絡狀態(tài)在iPhoneX上會crash爸邢。
問題原因:
之前我們采用遍歷statusBar，獲取UIStatusBarDataNetworkItemView實例拿愧，再獲取網(wǎng)絡狀態(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)絡狀態(tài)狀態(tài)浇辜。
可以通過po [statusBar recursiveDescription]打印出來iphoneX內(nèi)部結(jié)構(gòu)了券敌，可以看出變化非常的大。
解決方案:
使用AFNetworking中的AFNetworkReachabilityManager類柳洋，或者使用Reachability庫獲取網(wǎng)絡連接狀態(tài)待诅。
四、權(quán)限適配
4.1 無法獲取定位信息熊镣，第一次打開app也無法彈出定位權(quán)限提示框
問題原因:
iOS11 定位相關的權(quán)限做了更改卑雁，在iOS11上使用了新的定位權(quán)限key。
解決方案:
如果原來申請的權(quán)限是始終允許NSLocationAlwaysUsageDescription绪囱，那么需要在保留原來的key的基礎上增加NSLocationWhenInUseUsageDescription和NSLocationAlwaysAndWhenInUsageDescription序厉。
五、其他一些補充
5.1 如何判斷該設備是不是iPhoneX
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ā)自此文特此聲明毕箍，如有問題，請聯(lián)系我道盏！
