WWDC 2015蘋果開發(fā)者大會是移動開發(fā)者一年一度的盛會，InfoQ中文站除了第一時(shí)間整理Keynote內(nèi)容分享給大家之外，還邀請了資深的一線開發(fā)者分享他們的收獲。本文為王巍（@onevcat）對WWDC上透露的iOS 9 SDK新特性的總結(jié)，分享給廣大的iOS開發(fā)者。

年年歲歲花相似，歲歲年年人不同。今年的 WWDC 一如既往的熱鬧，得益于 Apple 的隨機(jī)抽選機(jī)制，這兩年有更多的中國開發(fā)者有機(jī)會親臨現(xiàn)場進(jìn)行體驗(yàn)，并與全球開發(fā)者取得更多的交流。更多的開發(fā)者可能只能在家里或者公司遠(yuǎn)程關(guān)注這一全球 Apple 開發(fā)者的盛會，但是這也并沒有減少大家對于開發(fā)的熱情。

生命不息，學(xué)習(xí)不止。從 WWDC 開始受到廣大開發(fā)者的關(guān)注以來，這就是一個(gè)開發(fā)者們學(xué)習(xí)和提高的重要途徑。可以感受到近年來國內(nèi)開發(fā)者的平均水平越來越高，希望這樣的趨勢能夠保持下去，畢竟只有在社區(qū)的支持下，開發(fā)者們才會是最強(qiáng)力的存在。

事不宜遲，讓我們來看看今年的 WWDC 中開發(fā)者可能需要重點(diǎn)關(guān)注的一些內(nèi)容吧。

iOS 9 時(shí)代開發(fā)者面臨的最大的挑戰(zhàn)和最急切的任務(wù)可能有兩個(gè)方面，首先是如何利用和適配全新的 iPad 分屏多任務(wù)特性，其次是如何面對和利用 watchOS 2 來構(gòu)建原生的手表 app。另外的新課題基本就都是現(xiàn)有框架的衍生和擴(kuò)展，包括從單元測試擴(kuò)展到 UI 測試，如何進(jìn)一步占領(lǐng)和使用系統(tǒng)的通知中心及搜索頁面，以及 Swift 2 的使用等。

可以說，經(jīng)過了 iOS 7 和 iOS 8 連續(xù)兩次重量級的變革和更新，對普通的 app 開發(fā)者來說，iOS 9 SDK 略歸于緩和及平靜，新的 SDK 在 API 和整體設(shè)計(jì)上并沒有發(fā)生像之前兩個(gè)系統(tǒng)那樣翻天覆地的改變。開發(fā)者們也正可以利用這個(gè)機(jī)會稍作喘息，在這一年里盡快熟悉和至少過渡到使用 iOS 8 SDK 的特性來構(gòu)筑自己的 app (比如嘗試使用 Size Class 和 Presentation Controller 等)。盡量提升自己的職業(yè)能力和制作 app 的水平，并保證能跟上滾滾向前的 Apple 車輪，應(yīng)該是今年 Cocoa 開發(fā)者們的主要任務(wù)。從近幾年的 WWDC 技術(shù)路線圖來看，Apple 開發(fā)可謂是環(huán)環(huán)相扣，如果哪一年你的技術(shù)停步不前，之后想要再趕上可能要付出的就是成倍的精力了。

這可以說是 iOS 9 最大的賣點(diǎn)了。多任務(wù)特性，特別是分屏多任務(wù)使得 iPad 真正變得像一個(gè)堪當(dāng)重任的個(gè)人電腦。雖然在很早以前就已經(jīng)有越獄插件能讓 iPad 同時(shí)運(yùn)行多個(gè)程序，但是 Apple 還是很謹(jǐn)慎地到 2015 年才在自己性能最為強(qiáng)勁的移動設(shè)備上實(shí)裝這個(gè)功能。iOS 9 中的多任務(wù)分為三種表現(xiàn)形式，分別是臨時(shí)調(diào)出的滑動覆蓋 (Slide Over)，視頻播放的畫中畫模式 (Picture in Picture) 以及真正的同時(shí)使用兩個(gè) app 的分割視圖 (Split View)。現(xiàn)在能運(yùn)行 iOS 9 的設(shè)備中只有最新的 iPad Air 2 支持分割視圖方式，但是相信隨著設(shè)備的更新，分割視圖的使用方式很可能成為人們?nèi)粘Ｊ褂?iPad 的一種主流方式，因此提早進(jìn)行準(zhǔn)備是開發(fā)者們的必修功課。

雖然第一眼看上去感覺要支持多任務(wù)的視圖會是一件非常復(fù)雜的事情，但是實(shí)際上如果你在前一年就緊跟 Apple 步伐的話，就很簡單了。滑動覆蓋和分割視圖的 app 會使用 iOS 8 引入的 Size Class 中的 Compact Width 和 Regular Height 的設(shè)定，配合上 AutoLayout 來進(jìn)行布局。也就是說，如果你的 app 之前就是 iPhone 和 iPad 通用的，并且已經(jīng)使用了 Size Class 進(jìn)行布局的話，基本上你不需要再額外做什么事兒就已經(jīng)能支持 iOS 9 的多任務(wù)視圖了。但是如果不幸你還沒有使用這些技術(shù)的話，可能你會需要盡快遷移到這套布局方式中，才能完美支持了。

視頻 app 的畫中畫模式相對簡單一些，如果你使用 AVPlayerViewController 或者 AVPlayerLayer 來播放視頻的話，那什么都不用做就已經(jīng)支持了。但如果你之前選擇的方案是 MPMoviePlayerController 或者 MPMoviePlayerViewController 的話，你可能也需要今早遷移到 AVKit 的框架下來，因?yàn)?Media Player 將在 iOS 9 被標(biāo)記為 deprecated 并不再繼續(xù)維護(hù)。

在新的 watchOS 2 中，Watch App 的架構(gòu)發(fā)生了巨大改變。新系統(tǒng)中 Watch App 的 extension 將不像現(xiàn)在這樣存在于 iPhone 中，而是會直接安裝到手表里去，Apple Watch 從一個(gè)單純的界面顯示器進(jìn)化為了可執(zhí)行開發(fā)者代碼的設(shè)備。得益于此，開發(fā)者們也可以在 extension 中訪問到像數(shù)字表冠和 (雖然都只是很初級的訪問，但是聊勝于無) 心跳計(jì)數(shù)這樣的情報(bào)。雖然有所進(jìn)步，但是其實(shí) Apple 在 watchOS 2 里表現(xiàn)出來的態(tài)度還是十分謹(jǐn)慎，這可能和初代 Apple Watch 的設(shè)備限制有很大關(guān)系，所以實(shí)際上留給 app 開發(fā)者的電量和性能空間并不是十分廣闊。但是相比起現(xiàn)在的 WatchKit 來說，可以脫離 iPhone 運(yùn)行本身就是了不起的進(jìn)步了。而為了和 iPhone 進(jìn)行通訊，現(xiàn)在還添加了 WatchConnectivity 這個(gè)新框架。我們有足夠的理由期待 Apple Watch 和 WatchKit 在接下來兩三年里的表現(xiàn)。

在開發(fā)領(lǐng)域里，測試一直是保障產(chǎn)品質(zhì)量關(guān)鍵。從 Xcode 4 以來，測試在 app 開發(fā)中的地位可謂是逐年上升。從 XCT 框架的引入，到測試 target 成為新建項(xiàng)目時(shí)的默認(rèn)，再到去年加入的異步代碼測試和性能測試。可以說現(xiàn)在 Xcode 自帶的測試框架已經(jīng)能滿足絕大部分單元測試的需求了。

但是這并不夠。開發(fā)一個(gè) iOS app 從來都是更注重 UI 和用戶體驗(yàn)的工作，而簡單地單元測試可以很容易地保證 model 層的正確，卻很難在 UI 方面有所作為。如何為一個(gè) app 編寫 UI 測試一直是 Cocoa 社區(qū)的難題之一。之前的話有像是 KIF，Automating，甚至是 FBSnapshotTestCase 這種腦洞大開的方案。今年 Apple 給出了一個(gè)更加誘人的選項(xiàng)，那就是 Xcode 自帶的 XCUITest 的一系列工具。

和大部分已有的 UI 測試工具類似，XCUI 使用 Accessibility 標(biāo)記來確定 view，但因?yàn)槭?Apple 自家的東西，它可以自動記錄你的操作流程，所以你只需要書寫最后的驗(yàn)證部分就可以了，比其他的 UI 測試工具方便很多。

Swift 經(jīng)過了一年的改善和進(jìn)步，現(xiàn)在已經(jīng)可以很好地?fù)?dān)任 app 開發(fā)的工作了。筆者自己也已經(jīng)使用 Swift 作為日常工作的主要語言有半年多時(shí)間了，這半年里的總體感覺是越寫越舒暢。Swift 2 里主要的改動是錯(cuò)誤處理方面的變化，Apple 從 Cocoa 傳統(tǒng)的基于 NSError 錯(cuò)誤處理方式變?yōu)榱?throw catch 的異常處理機(jī)制。這個(gè)轉(zhuǎn)變確實(shí)可以讓程序更加安全，新增的 ErrorType 也很好地將錯(cuò)誤描述進(jìn)行了統(tǒng)一。但是在實(shí)際接觸了一兩天之后，在語法上感覺要比原來的處理寫的代碼多一些。可能是長久以來使用 NSError 的習(xí)慣導(dǎo)致吧，筆者還并沒有能很好地全面接受 Swift 2 中的異常機(jī)制。不過這次 Apple 做的相對激進(jìn)，把 Cocoa API 中的 error 全數(shù)替換成了 throw。所以不管情不情愿，轉(zhuǎn)型到異常處理是 Swift 開發(fā)者必須面對的了。

另外 Apple 新加了一些像是 guard 和 defer 這樣的控制流關(guān)鍵字，這在其他一些語言里也是很實(shí)用的特性，這讓 Swift 的書寫更加簡化，閱讀起來更流暢。為了解決在運(yùn)行時(shí)的不同 SDK 的可用性的問題，Apple 還在 Swift 2 里加入了 avaliable 塊，以前我們需要自己去記憶 API 的可用性，并通過檢查系統(tǒng)版本并進(jìn)行對比來做這件事情。現(xiàn)在有了 avaliable 檢測，編譯器將會檢查出那些可能出現(xiàn)版本不匹配的 API 調(diào)用，app 開發(fā)的安全性得到了進(jìn)一步的保障。為了讓整個(gè) SDK 更適合 Swift 的語法習(xí)慣，Apple 終于在 Objective-C 中引入了泛型。這看似是 Objective-C 的加強(qiáng)，但是實(shí)際上卻實(shí)實(shí)在在地是為 Swift 一統(tǒng) Apple 開發(fā)開路。有了 Objective-C 泛型以后，用 Swift 訪問 Cocoa API 基本不會再得到 AnyObject 類型了，這使得 Swift 的安全特性又上了一層臺階。

最后是 Swift 2 開源的消息。Swift 的編譯器和標(biāo)準(zhǔn)庫將在今年年底開源，對于一般的 app 開發(fā)者來說可能并不會帶來什么巨變，但這確實(shí)意味著 Swift 將從一門 app 制作的專用語言轉(zhuǎn)型為一門通用語言。最容易想到的就是基于 Swift 的后端開發(fā)，也許我們會在看到 Javascript 一統(tǒng)天下之前就能先感受一下 Swift 全棧的力量？

筆者在日本工作，因?yàn)檫@邊大家流量都是包月且溢出的，所以基本不會有人對 app 的尺寸介意，無非就是下載 5 秒還是 10 秒的區(qū)別。但是在和國內(nèi)同行交流的時(shí)候，發(fā)現(xiàn)國內(nèi) app 開發(fā)對尺寸的要求近乎苛刻。因?yàn)?iOS app 為了后向兼容，現(xiàn)在都同時(shí)包含了 32 bit 和 64 bit 兩個(gè) slice。另外在圖片資源方面，更是 1x 2x 3x 的圖像一應(yīng)俱全 (好吧現(xiàn)在 1x 應(yīng)該不太需要了)。而用戶使用 app 時(shí)，因?yàn)樵O(shè)備是特定的，其實(shí)只需要其中的一套資源。但是現(xiàn)在在購買和下載的時(shí)候卻是把整個(gè) app 包都下載了。

Apple 終于意識到了這件事情有多傻，iOS 9 中終于可以僅選擇需要的內(nèi)容 (Slicing) 下載了。這對用戶來說是很大的利好，因?yàn)橹恍枰壍?iOS 9，就可以節(jié)省很多流量。對于開發(fā)者來說，并沒有太多要做的事情，只需要使用 asset catalog 來管理素材標(biāo)記 2x 3x 就可以了。

給 App 瘦身的另一個(gè)手段是提交 Bitcode 給 Apple，而不是最終的二進(jìn)制。Bitcode 是 LLVM 的中間碼，在編譯器更新時(shí)，Apple 可以用你之前提交的 Bitcode 進(jìn)行優(yōu)化，這樣你就不必在編譯器更新后再次提交你的 app，也能享受到編譯器改進(jìn)所帶來的好處。Bitcode 支持在新項(xiàng)目中是默認(rèn)開啟的，沒有特別理由的話，你也不需要將它特意關(guān)掉。

最后就是按需加載的資源。這可能在游戲中應(yīng)用場景會多一些。你可以用 tag 來組織像圖像或者聲音這樣的資源，比如把它們標(biāo)記為 level1，level2 這樣。然后一開始只需要下載 level1 的內(nèi)容，在玩的過程中再去下載 level2。或者也可以通過這個(gè)來推后下載那些需要內(nèi)購才能獲得的資源文件。在一些大型游戲里這是很常見的優(yōu)化方法，現(xiàn)在在 iOS 9 里也可以方便地使用了。

如果說這屆 WWDC Keynote 上還有什么留給我印象深刻的內(nèi)容的話，我會給更加智能的手機(jī)助理投上一票。雖然看起來還很初級，比如就是插入耳機(jī)時(shí)播放你喜歡的音樂，推薦你可能會聯(lián)系的 人和打開的 app 等，但是這確實(shí)是很有意義的一步。現(xiàn)在的 Siri 只是一個(gè)問答系統(tǒng)，如果上下文中斷，“她”甚至不記得前面兩句話說了些什么。一個(gè)不會記住 Boss 習(xí)慣的秘書一定不是一個(gè)好護(hù)士，而 Apple 正在讓 iPhone 向這方面努力。好消息是我們大概暫時(shí)還不用擔(dān)心會碰到故意不通過圖靈測試的機(jī)器，所以在人工智能上還有很大的空間可以發(fā)揮。

而搜索 API 實(shí)質(zhì)上讓 app 多了一個(gè)可能的入口。有些用戶會非常頻繁地使用搜索界面，這是一個(gè)絕好的展示你的 app 和提高打開率的機(jī)會。如果 app 類型合適的話，這是非常值得一做的追加特性。

游戲類的 app 因?yàn)樵诓煌囊苿悠脚_上的用戶體驗(yàn)并沒有鴻溝似的差異，所以是最容易跨平臺的 - 畢竟現(xiàn)在無論哪個(gè)開發(fā)商都無法忽視安卓的份額。這也是 Apple 自家的 SpriteKit 和 SceneKit 這樣的游戲框架一直不溫不火的原因。比起被局限在 Apple 平臺，更多的開發(fā)商選擇像是 Unity 或者 Cocos2d-x 這樣的跨平臺方案。但是今年 Apple 還是持續(xù)加強(qiáng)了游戲方面的開發(fā)工具支持，包括負(fù)責(zé)狀態(tài)機(jī)維護(hù)和尋路等的 GameplayKit 框架，負(fù)責(zé)錄像和回放游戲過程的 ReplayKit 框架，以及物理建模的 Model I/O 框架。

這些其實(shí)都是在 Apple 的游戲開發(fā)體系中補(bǔ)充了一些游戲業(yè)界已經(jīng)很成熟的算法和工具，為開發(fā)者節(jié)省了不少時(shí)間。對于個(gè)人開發(fā)者自制的游戲來說，Apple 的工具提供了相對低的門檻，易于上手。但是在現(xiàn)在大部分游戲開發(fā)都需要跨平臺的年代，總感覺 Apple 體系是否能順利走下去還需要進(jìn)一步觀察。

HomeKit，CloudKit，HealthKit 等等雜七雜八的框架。如果是 iOS Only 的 app 的話，使用 CloudKit 做 BaaS 也許是不錯(cuò)的選擇，但是也要面臨今后跨平臺數(shù)據(jù)難以共享的風(fēng)險(xiǎn)。其他幾個(gè)框架專業(yè)性相對較強(qiáng)，大部分需要配合硬件支援，其實(shí)一直說智能硬件是下一個(gè)爆點(diǎn)， 但是至少現(xiàn)在為止還沒能爆出大的聲響，更多的卻已經(jīng)進(jìn)入到廉價(jià)競爭 (手環(huán)什么的你懂的)，只能說期待這些設(shè)備的后續(xù)表現(xiàn)吧。

最后是一個(gè)對于剛?cè)腴T或者打算投身到 Apple 開發(fā)中的朋友的福利。現(xiàn)在你可以不需要加入付費(fèi)的開發(fā)者計(jì)劃就能將 app 部署到自己的設(shè)備上了，而在以前這至少需要你加入 99 美金每年的開發(fā)者計(jì)劃，這可以說進(jìn)一步降低了進(jìn)行 Apple 開發(fā)的門檻。

正如上面提到的，對開發(fā)者來說，今年的 WWDC 并沒有像 13 年和 14 年那樣顛覆性的變化，大多是對已有特性的加強(qiáng)補(bǔ)充和對開發(fā)工具鏈的增強(qiáng)。今年可以說是一個(gè) Cocoa 開發(fā)者們沉淀之前知識，增進(jìn)自己技能的好機(jī)會。現(xiàn)在 WWDC 15 還在如火如荼的進(jìn)行之中。如果你打算盡早擁抱新 SDK 的變化的話，請不要猶豫，直接訪問 Apple 的開發(fā)者網(wǎng)站，去尋找和觀看自己感興趣的話題吧。