整理iOS9適配中出現的坑（圖文）

本文主要是說一些iOS9適配中出現的坑，如果只是要單純的了解iOS9新特性可以看瞄神的開發者所需要知道的 iOS 9 SDK 新特性。9月17日凌晨，蘋果給用戶推送了iOS9正式版，隨著有用戶陸續升級iOS9，也就逐漸的衍生出了一系列的問題，筆者也在趕忙為自己維護的App做適配，本文寫的一些坑基本都是親身體驗了。

一、NSAppTransportSecurity

iOS9讓所有的HTTP默認使用了HTTPS，原來的HTTP協議傳輸都改成TLS1.2協議進行傳輸。直接造成的情況就是App發請求的時候彈出網絡無法連接。解決辦法就是在項目的info.plist 文件里加上如下節點：

NSAppTransportSecurity -?NSAllowsArbitraryLoads

這個子節點的意思是：是否允許任性的加載？！ 設為YES的話就將禁用了AppTransportSecurity轉而使用用戶自定義的設置，這個問題就解決了。

如果你不是在董鉑然博客園看到本文，請點擊查看原文。

?

上面說是蘋果限制了HTTP協議，但是也并不是說所有的HTTPS都能完美適配iOS9了。

舉個栗子，從app內起webView加載https的網頁。新建個項目寫幾行起網頁的代碼

123456789101112

- (void)loadView{????UIWebView *web = [[UIWebView alloc]initWithFrame:[UIScreen mainScreen].bounds];????self.view = web;}- (void)viewDidLoad {????[super viewDidLoad];?????????UIWebView *web = (UIWebView *)self.view; //董鉑然????NSURL *url = [NSURL URLWithString:@"https://github.com/"];????NSURLRequest *request = [NSURLRequest requestWithURL:url];????[web loadRequest:request];}

中間的url就是我們想要加載的https地址，用https://baidu.com/ 和?https://github.com/ 分別試一下，結果不同

??

github的網頁能打開，百度的網頁打不開，下面打印了一行log

1	NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)

原因是蘋果的官方資料說首先必須要基于TLS 1.2版本協議。然后證書的加密的算法還需要達到SHA256或者更高位的RSA密鑰或ECC密鑰，如果不符合，請求將被中斷并返回nil.

在瀏覽器中是可以直接查看這個網站的加密算法的，先點綠鎖再點證書信息。

從右邊兩張圖可以看出，github帶RSA加密的SHA-256符合蘋果的要求，所以才可以展示。

針對百度的情況可以在info.plist中配置如下，如果網站引用的比較多應該是需要針對每個網站進行配置。

NSAppTransportSecurity，NSExceptionDomains，NSIncludesSubdomains，NSExceptionRequiresForwardSecrecy，NSExceptionAllowInsecureHTTPLoads 寫在下面便于復制。

其中的ForwardSecrecy理解為超前的密碼保護算法，在官方資料里有寫，一共是11種。配置完畢百度可以訪問。

? ?

??

二、Bitcode

bitcode的理解應該是把程序編譯成的一種過渡代碼，然后蘋果再把這個過渡代碼編譯成可執行的程序。bitcode也允許蘋果在后期重新優化我們程序的二進制文件，有類似于App瘦身的思想。

用了xcode7的編譯器編譯之前沒問題的項目可能會出現下列報錯。

1	XXXX’ does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

問題的原因是：某些第三方庫還不支持bitcode。要不然是等待庫的開發者升級了此項功能我們更新庫，要不就是把這個bitcode禁用。

禁用的方法就是找到如下配置，選為NO.(iOS中bitcode是默認YES，watchOS中bitcodes是不讓改的必須YES。)

?

三、設置信任

這一條只和企業級應用或inhose 有關，和AppStore渠道的應用無關。

在iOS8只是彈出一個窗問你是否需要讓手機信任這個應用，但是在iOS9卻直接禁止，如果真的想信任需要自己去手動開啟。類似于Mac系統從未知開發者處下載的dmg直接打不開，然后要到系統偏好設置的安全性與隱私手動打開。 下圖展示左邊iOS8,右邊iOS9

?

用戶需要去 設置---》通用---》描述文件 里面自行添加信任。

這種問題的處理方法也就兩種：1.提前周知暫時不要升級iOS9 ?2.大多是公司員工使用的企業級應用，群發一個指導郵件。?

?

四、字體

iOS8中，字體是Helvetica，中文的字體有點類似于“華文細黑”。只是蘋果手機自帶渲染，所以看上去可能比普通的華文細黑要美觀。iOS9中，中文系統字體變為了專為中國設計的“蘋方” 有點類似于一種word字體“幼圓”。字體有輕微的加粗效果，并且最關鍵的是字體間隙變大了！

所以很多原本寫死了width的label可能會出現“...”的情況。

?iOS8

?iOS9 蛋疼

上面這兩張圖也可以直觀的看出同一個界面，同一個label的變化。

所以為了在界面顯示上不出錯，就算是固定長度的文字也還是建議使用sizetofit 或者ios向上取整 ceilf() 或者提前計算

12	CGSize size = [title sizeWithAttributes:@{NSFontAttributeName: [UIFont systemFontOfSize:14.0f]}];CGSize adjustedSize = CGSizeMake(ceilf(size.width), ceilf(size.height));

?

五、URL scheme

URL scheme一般使用的場景是應用程序有分享或跳其他平臺授權的功能，分享或授權后再跳回來。

在iOS8并沒有做過多限制，但是iOS9需要將你要在外部調用的URL scheme列為白名單，才可以完成跳轉

如果iOS9沒做適配 會報如下錯誤

1	canOpenURL: failed for URL : "mqzone://qqapp" - error: "This app is not allowed to query for scheme mqzone"

具體的解決方案也是要在info.plist中設置 LSApplicationQueriesSchemes 類型為數組，下面添加所有你用到的scheme

?

六、statusbar

這個還好只是報一個警告，如果就是不管他，也不會出現問題。

1	<Error>: CGContextSaveGState: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.

以前我們為了能夠實時的控制頂部statusbar的樣式，可能會在喜歡使用

12	[[UIApplication sharedApplication] setStatusBarStyle:UIStatusBarStyleLightContent][[UIApplication sharedApplication]setStatusBarHidden:YES];

但是這么做之前需要將 info.plist 里面加上View controller-based status bar appearance ?BOOL值設為NO，就是把控制器控制狀態欄的權限給禁了，用UIApplication來控制。但是這種做法在iOS9不建議使用了，建議我們使用吧那個BOOL值設為YES，然后用控制器的方法來管理狀態欄比如。

1234	- (UIStatusBarStyle)preferredStatusBarStyle{????return UIStatusBarStyleLightContent;}

點進頭文件可以驗證剛才說法：

1	@property(readwrite, nonatomic,getter=isStatusBarHidden) BOOL statusBarHidden NS_DEPRECATED_IOS(2_0, 9_0, "Use -[UIViewController prefersStatusBarHidden]");

?

七、didFinishLaunchingWithOptions

如果運行的時候報下列錯誤，那就是你的didFinishLaunchingWithOptions寫的不對了

1	***** Assertion failure in -[UIApplication _runWithMainScene:transitionContext:completion:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3505.16/UIApplication.m:3294**

iOS9不允許在didFinishLaunchingWithOptions結束了之后還沒有設置window的rootViewController。 也許是xcode7的編譯器本身就不支持。

解決的方法當然就是先初始化個值，之后再賦值替換掉

12	UIWindow *window = [[UIWindowalloc] initWithFrame:[UIScreenmainScreen].bounds];window.rootViewController = [[UIViewController alloc]init];

?

八、tableView

雖然現在的iOS9已經推送正式版了，但是iOS9使用時還是會感覺到App比以前更加卡頓了，tableView拖動時卡頓顯示的最為明顯。 并且之前遇到一個bug，原本好的項目用xcode7一編譯，tableView刷新出了問題 ，[tableView reloadData]無效 有一行cell明明改變了但是刷新不出來。 感覺可能是這個方法和某種新加的特性沖突了，猜測可能是reloadData的操作被推遲到下一個RunLoop執行最終失效。

解決的方法是，注釋[tableView reloadData]，改用局部刷新，問題居然就解決了。

1	[self.tableView reloadSections:[NSIndexSet indexSetWithIndex:0] withRowAnimation:UITableViewRowAnimationNone];

?

九、NSLocalizableString（XCode7問題）

如果你程序啟動后出現主頁面一片空白，或是報了以下的棧調用錯誤。那就是NSLocalizableString的死循環導致堆棧溢出了。

1234567891011121314151617

#0? 0x003052a8 in -[NSLocalizableString length] ()#1? 0x003052cc in -[NSLocalizableString length] ()#2? 0x003052cc in -[NSLocalizableString length] ()#3? 0x003052cc in -[NSLocalizableString length] ()#4? 0x003052cc in -[NSLocalizableString length] ()#5? 0x003052cc in -[NSLocalizableString length] ()#6? 0x003052cc in -[NSLocalizableString length] ()#7? 0x003052cc in -[NSLocalizableString length] ()#8? 0x003052cc in -[NSLocalizableString length] ()#9? 0x003052cc in -[NSLocalizableString length] ()#10 0x003052cc in -[NSLocalizableString length] ()#11 0x003052cc in -[NSLocalizableString length] ()#12 0x003052cc in -[NSLocalizableString length] ()#13 0x003052cc in -[NSLocalizableString length] ()#14 0x003052cc in -[NSLocalizableString length] ()#15 0x003052cc in -[NSLocalizableString length] ()#16 0x003052cc in -[NSLocalizableString length] ()

這個的解決方法就是找到特定的頁面，然后將English 前面的勾勾上。

?

十、bundle identifier（Xcode7問題）

如果你遇到了在本地編譯通過，但是在CI上打包失敗。并且報的錯誤是和bundle identifier相關，那很有可能是你plist文件中寫的bundle?identifier沒有起作用。

因為xcode7新增了此功能，在target下面的BuildSetting里面增加了Product Bundle identifier。蘋果之后的做法應該是推薦在此處設置bundle identifier，此處的設置會比info.plist里面優先讀取。

如果你的Bundle identifier一直沒變，可能不會發現此問題。如果改變了，你在plist中修改是無效的。

另一個做法就是在ci打包的配置Execute shell上增加以下代碼

1	"Set :CFBundleIdentifier com.XXX.XXX" "XXX/Supporting Files/XXX-Info.plist"

?

十一、 ActionSheet

Actionsheet 在iOS8的時候改了一次版，當時是和AlertView二合一，并且以AlertViewController作為載體，之后再present出來，這在當時，蘋果應該是想統一各個控件的展示方式，但是很多人可能并沒有在意因為直接show那個方法并沒有廢除，大家都覺得應該是新舊都能用，再加上有的公司可能自己還做了一定擴展，諸多原因導致還是用的舊方法。

在iOS9上使用舊方法直接show，會出現左圖的問題。如果用的是AlertViewController的方法則不會出現問題（右圖）

? ??

我猜測可能是sheet的windowLevel比鍵盤低導致的。但是將優先級設到10000，然后顯示在keyWindow上。

12	sheet.window.windowLevel = 10000;[sheet showInView:[UIApplication sharedApplication].keyWindow];

然后沒有效果，然后又查了下stackoverflow 有個方法能取出優先級最高的window

123	UIWindow *topWindow = [[[UIApplication sharedApplication].windows sortedArrayUsingComparator:^NSComparisonResult(UIWindow *win1, UIWindow *win2) {????return win1.windowLevel - win2.windowLevel;}] lastObject];

試了下還是沒有效果。 應該鍵盤的優先級無論如何都是最高的， 想蓋在鍵盤上面的方法行不通。

當然，如果更換的成本比較大，也并不是沒有辦法，直接設置彈sheet之前收回鍵盤就好了。

?

如果你不是在董鉑然博客園看到本文，請點擊查看原文。?

暫時遇到這些問題，感覺iOS9的出現讓所有iOS開發都是菊花一緊，預祝所有的iOS都能及時的做好適配改完bug，下個版本一上線，所有問題都解決。

分類: 技術調研，探索分析標簽: OC, iOS, iOS9, 適配, 新特性好文要頂關注我收藏該文董鉑然
關注 - 7
粉絲 - 281 +加關注 7 ? 上一篇：iOS警告收錄及科學快速的消除方法
? 下一篇：將自己寫的庫上傳到cocoapods（2015）

總結

以上是生活随笔為你收集整理的整理iOS9适配中出现的坑（图文）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。