開發者需要知道的iOS9 SDK新特性
年年歲歲花相似，歲歲年年人不同。今年的 WWDC 一如既往的熱鬧，但是因為要照顧家里剛出生的寶寶以及寶寶的娘，就只能在家里的“窩里蹲”家庭影院來關注這一全球 Apple 開發者的盛會了。
生命不息，學習不止。一如以往幾年，我會陸續寫一些關于 WWDC 和新的 SDK 里我覺得有意思和我自己重點關注和學習的內容?，F在回頭看前幾年寫的東西，愈來愈感覺到以前青蔥歲月的自己真是傻得可愛。不過一路以來的成長軌跡倒是很明顯，也希望自己能就這樣淡然地將這段旅程繼續下去。
矯情結束，該干活了。讓我們來看看今年的 WWDC 中我認為的開發者需要關注的一些內容吧。
總覽
iOS 9 時代開發者面臨的最大的挑戰和最急切的任務可能有兩個方面，首先是如何利用和適配 iPad 的新的分屏多任務特性，其次是如何面對和利用 watchOS 2 來構建原生的手表 app。另外的新課題基本就都是現有框架的衍生和擴展，包括從單元測試擴展到 UI 測試，如何進一步占領和使用系統的通知中心及搜索頁面，以及 Swift 2 的使用等。
可以說，經過了 iOS 7 和 iOS 8 連續兩次重量級的變革和更新，對普通的 app 開發者來說，iOS 9 SDK 略歸于緩和和平靜，新的 SDK 在 API 和整體設計上并沒有發生什么非常巨大的改變。開發者們也正可以利用這個機會喘息一下，盡快進一步熟悉和至少過渡到使用 iOS 8 SDK 的內容來構筑自己的 app (比如嘗試使用 Size Class 和 Presentation Controller 等)，盡快提升自己的職業技能和制作的 app 的水平，并保證能跟上滾滾向前的 Apple 車輪，應該是今年 Cocoa 開發者們的主要任務。
Multitasking
這可以說是 iOS 9 最大的賣點了。多任務特性，特別是分屏多任務使得 iPad 真正變得像一個堪當重任的個人電腦。雖然在很早以前就已經有越獄插件能讓 iPad 同時運行多個程序，但是 Apple 還是很謹慎地到 2015 年才在自己性能最為強勁的移動設備上實裝這個功能。iOS 9 中的多任務分為三種表現形式，分別是臨時調出的滑動覆蓋 (Slide Over)，視頻播放的畫中畫模式 (Picture in Picture) 以及真正的同時使用兩個 app 的分割視圖 (Split View)。現在能運行 iOS 9 的設備中只有最新的 iPad Air 2 支持分割視圖方式，但是相信隨著設備的更新，分割視圖的使用方式很可能成為人們日常使用 iPad 的一種主流方式，因此提早進行準備是開發者們的必修功課。
雖然第一眼看上去感覺要支持多任務的視圖會是一件非常復雜的事情，但是實際上如果你在前一年就緊跟 Apple 步伐的話，就很簡單了?；瑒痈采w和分割視圖的 app 會使用 iOS 8 引入的 Size Class 中的 Compact Width 和 Regular Height 的設定，配合上 AutoLayout 來進行布局。也就是說，如果你的 app 之前就是 iPhone 和 iPad 通用的，并且已經使用了 Size Class 進行布局的話，基本上你不需要再額外做什么事兒就已經能支持 iOS 9 的多任務視圖了。但是如果不幸你還沒有使用這些技術的話，可能你會需要盡快遷移到這套布局方式中，才能完美支持了。
視頻 app 的畫中畫模式相對簡單一些，如果你使用 AVPlayerViewController 或者 AVPlayerLayer 來播放視頻的話，那什么都不用做就已經支持了。但如果你之前選擇的方案是 MPMoviePlayerController 或者 MPMoviePlayerViewController 的話，你可能也需要盡早遷移到 AVKit 的框架下來，因為 Media Player 將在 iOS 9 被標記為 deprecated 并不再繼續維護。
相關專題筆記
watchOS 2
在新的 watchOS 2 中，Watch App 的架構發生了巨大改變。新系統中 Watch App 的 extension 將不像現在這樣存在于 iPhone 中，而是會直接安裝到手表里去，Apple Watch 從一個單純的界面顯示器進化為了可執行開發者代碼的設備。得益于此，開發者們也可以在 extension 中訪問到像數字表冠和 (雖然都只是很初級的訪問，但是聊勝于無) 心跳計數這樣的情報。雖然有所進步，但是其實 Apple 在 watchOS 2 里表現出來的態度還是十分謹慎，這可能和初代 Apple Watch 的設備限制有很大關系，所以實際上留給 app 開發者的電量和性能空間并不是十分廣闊。但是相比起現在的 WatchKit 來說，可以脫離 iPhone 運行本身就是了不起的進步了。而為了和 iPhone 進行通訊，現在還添加了 WatchConnectivity 這個新框架。我們有足夠的理由期待 Apple Watch 和 WatchKit 在接下來兩三年里的表現。
相關專題筆記
UI Test
在開發領域里，測試一直是保障產品質量關鍵。從 Xcode 4 以來，測試在 app 開發中的地位可謂是逐年上升。從 XCT 框架的引入，到測試 target 成為新建項目時的默認，再到去年加入的異步代碼測試和性能測試?？梢哉f現在 Xcode 自帶的測試框架已經能滿足絕大部分單元測試的需求了。
但是這并不夠。開發一個 iOS app 從來都是更注重 UI 和用戶體驗的工作，而簡單地單元測試可以很容易地保證 model 層的正確，卻很難在 UI 方面有所作為。如何為一個 app 編寫 UI 測試一直是 Cocoa 社區的難題之一。之前的話有像是 KIF，Automating，甚至是 FBSnapshotTestCase 這種腦洞大開的方案。今年 Apple 給出了一個更加誘人的選項，那就是 Xcode 自帶的 XCUITest 的一系列工具。
和大部分已有的 UI 測試工具類似，XCUI 使用 Accessibility 標記來確定 view，但因為是 Apple 自家的東西，它可以自動記錄你的操作流程，所以你只需要書寫最后的驗證部分就可以了，比其他的 UI 測試工具方便很多。
Swift 2
Swift 經過了一年的改善和進步，現在已經可以很好地擔任 app 開發的工作了。筆者自己也已經使用 Swift 作為日常工作的主要語言有半年多時間了，這半年里的總體感覺是越寫越舒暢。Swift 2 里主要的改動是錯誤處理方面的變化，Apple 從 Cocoa 傳統的基于 NSError 錯誤處理方式變為了 throw catch 的異常處理機制。這個轉變確實可以讓程序更加安全，新增的 ErrorType 也很好地將錯誤描述進行了統一。但是在實際接觸了一兩天之后，在語法上感覺要比原來的處理寫的代碼多一些。可能是長久以來使用 NSError 的習慣導致吧，筆者還并沒有能很好地全面接受 Swift 2 中的異常機制。不過這次 Apple 做的相對激進，把 Cocoa API 中的 error 全數替換成了 throw。所以不管情不情愿，轉型到異常處理是 Swift 開發者必須面對的了。
另外 Apple 新加了一些像是 guard 和 defer 這樣的控制流關鍵字，這在其他一些語言里也是很實用的特性，這讓 Swift 的書寫更加簡化，閱讀起來更流暢。為了解決在運行時的不同 SDK 的可用性的問題，Apple 還在 Swift 2 里加入了 avaliable 塊，以前我們需要自己去記憶 API 的可用性，并通過檢查系統版本并進行對比來做這件事情?，F在有了 avaliable 檢測，編譯器將會檢查出那些可能出現版本不匹配的 API 調用，app 開發的安全性得到了進一步的保障。為了讓整個 SDK 更適合 Swift 的語法習慣，Apple 終于在 Objective-C 中引入了泛型。這看似是 Objective-C 的加強，但是實際上卻實實在在地是為 Swift 一統 Apple 開發開路。有了 Objective-C 泛型以后，用 Swift 訪問 Cocoa API 基本不會再得到 AnyObject 類型了，這使得 Swift 的安全特性又上了一層臺階。
最后是 Swift 2 開源的消息。Swift 的編譯器和標準庫將在今年年底開源，對于一般的 app 開發者來說可能并不會帶來什么巨變，但這確實意味著 Swift 將從一門 app 制作的專用語言轉型為一門通用語言。最容易想到的就是基于 Swift 的后端開發，也許我們會在看到 Javascript 一統天下之前就能先感受一下 Swift 全棧的力量？
App Thinning
筆者在日本工作，因為這邊大家流量都是包月且溢出的，所以基本不會有人對 app 的尺寸介意，無非就是下載 5 秒還是 10 秒的區別。但是在和國內同行交流的時候，發現國內 app 開發對尺寸的要求近乎苛刻。因為 iOS app 為了后向兼容，現在都同時包含了 32 bit 和 64 bit 兩個 slice。另外在圖片資源方面，更是 1x 2x 3x 的圖像一應俱全 (好吧現在 1x 應該不太需要了)。而用戶使用 app 時，因為設備是特定的，其實只需要其中的一套資源。但是現在在購買和下載的時候卻是把整個 app 包都下載了。
Apple 終于意識到了這件事情有多傻，iOS 9 中終于可以僅選擇需要的內容 (Slicing) 下載了。這對用戶來說是很大的利好，因為只需要升級到 iOS 9，就可以節省很多流量。對于開發者來說，并沒有太多要做的事情，只需要使用 asset catalog 來管理素材標記 2x 3x 就可以了。
給 App 瘦身的另一個手段是提交 Bitcode 給 Apple，而不是最終的二進制。Bitcode 是 LLVM 的中間碼，在編譯器更新時，Apple 可以用你之前提交的 Bitcode 進行優化，這樣你就不必在編譯器更新后再次提交你的 app，也能享受到編譯器改進所帶來的好處。Bitcode 支持在新項目中是默認開啟的，沒有特別理由的話，你也不需要將它特意關掉。
最后就是按需加載的資源。這可能在游戲中應用場景會多一些。你可以用 tag 來組織像圖像或者聲音這樣的資源，比如把它們標記為 level1，level2 這樣。然后一開始只需要下載 level1 的內容，在玩的過程中再去下載 level2?；蛘咭部梢酝ㄟ^這個來推后下載那些需要內購才能獲得的資源文件。在一些大型游戲里這是很常見的優化方法，現在在 iOS 9 里也可以方便地使用了。
人工智能和搜索 API
如果說這屆 WWDC Keynote 上還有什么留給我印象深��的內容的話，我會給更加智能的手機助理投上一票。雖然看起來還很初級，比如就是插入耳機時播放你喜歡的音樂，推薦你可能會聯系的人和打開的 app 等，但是這確實是很有意義的一步?，F在的 Siri 只是一個問答系統，如果上下文中斷，“她”甚至不記得前面兩句話說了些什么。一個不會記住 Boss 習慣的秘書一定不是一個好護士，而 Apple 正在讓 iPhone 向這方面努力。好消息是我們大概暫時還不用擔心會碰到故意不通過圖靈測試的機器，所以在人工智能上還有很大的空間可以發揮。
而搜索 API 實質上讓 app 多了一個可能的入口。有些用戶會非常頻繁地使用搜索界面，這是一個絕好的展示你的 app 和提高打開率的機會。如果 app 類型合適的話，這是非常值得一做的追加特性。
游戲相關
游戲類的 app 因為在不同的移動平臺上的用戶體驗并沒有鴻溝似的差異，所以是最容易跨平臺的 - 畢竟現在無論哪個開發商都無法忽視安卓的份額。這也是 Apple 自家的 SpriteKit 和 SceneKit 這樣的游戲框架一直不溫不火的原因。比起被局限在 Apple 平臺，更多的開發商選擇像是 Unity 或者 Cocos2d-x 這樣的跨平臺方案。但是今年 Apple 還是持續加強了游戲方面的開發工具支持，包括負責狀態機維護和尋路等的 GameplayKit 框架，負責錄像和回放游戲過程的 ReplayKit 框架，以及物理建模的 Model I/O 框架。
這些其實都是在 Apple 的游戲開發體系中補充了一些游戲業界已經很成熟的算法和工具，為開發者節省了不少時間。對于個人開發者自制的游戲來說，Apple 的工具提供了相對低的門檻，易于上手。但是在現在大部分游戲開發都需要跨平臺的年代，總感覺 Apple 體系是否能順利走下去還需要進一步觀察。
其他
HomeKit，CloudKit，HealthKit 等等雜七雜八的框架。如果是 iOS Only 的 app 的話，使用 CloudKit 做 BaaS 也許是不錯的選擇，但是也要面臨今后跨平臺數據難以共享的風險。其他幾個框架專業性相對較強，大部分需要配合硬件支援，其實一直說智能硬件是下一個爆點，但是至少現在為止還沒能爆出大的聲響，更多的卻已經進入到廉價競爭 (手環什么的你懂的)，只能說期待這些設備的后續表現吧。
最后是一個對于剛入門或者打算投身到 Apple 開發中的朋友的福利?，F在你可以不需要加入付費的開發者計劃就能將 app 部署到自己的設備上了，而在以前這至少需要你加入 99 美金每年的開發者計劃，這可以說進一步降低了進行 Apple 開發的門檻。
總結
正如上面提到的，對開發者來說，今年的 WWDC 并沒有像 13 年和 14 年那樣顛覆性的變化，大多是對已有特性的加強補充和對開發工具鏈的增強。今年可以說是一個 Cocoa 開發者們沉淀之前知識，增進自己技能的好機會。現在 WWDC 15 還在如火如荼的進行之中。如果你打算盡早擁抱新 SDK 的變化的話，請不要猶豫，直接訪問 Apple 的開發者網站，去尋找和觀看自己感興趣的話題吧。
蘋果iOS 9值得升級的10個理由 http://www.linuxidc.com/Linux/2015-06/118595.htm
iOS 的詳細介紹：請點這里
