ios9新特性

標籤：

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 開發人員們的主要任務。從近幾年的 WWDC 技術路線圖來看，Apple 開發可謂是環環相扣，如果哪一年你的技術停步不前，之後想要再趕上可能要付出的就是成倍的精力了。

Multitasking

這可以說是 iOS 9 最大的賣點了。多任務特性，特別是分屏多任務使得 iPad 真正變得像一個堪當重任的個人電腦。雖然在很早以前就已經有越獄外掛程式能讓 iPad 同時運行多個程式，但是 Apple 還是很謹慎地到 2015 年才在自己效能最為強勁的行動裝置上實裝這個功能。iOS 9 中的多任務分為三種表現形式，分別是臨時調出的滑動覆蓋 (Slide Over)，視頻播放的畫中畫模式 (Picture in Picture) 以及真正的同時使用兩個 app 的分割視圖 (Split View)。現在能運行 iOS 9 的裝置中只有最新的 iPad Air 2 支援分割視圖方式，但是相信隨著裝置的更新，分割視圖的使用方式很可能成為人們日常使用 iPad 的一種主流方式，因此提早進行準備是開發人員們的必修功課。

雖然第一眼看上去感覺要支援多任務的視圖會是一件非常複雜的事情，但是實際上如果你在前一年就緊跟 Apple 步伐的話，就很簡單了。滑動覆蓋和分割視圖的 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 成為建立項目時的預設，再到去年加入的非同步代碼測試和效能測試。可以說現在 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 的可用性，並通過檢查系統版本並進行對比來做這件事情。現在有了 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 等，但是這確實是很有意義的一步。現在的 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 開發中的朋友的福利。現在你可以不需要加入付費的開發人員計劃就能將 app 部署到自己的裝置上了，而在以前這至少需要你加入 99 美金每年的開發人員計劃，這可以說進一步降低了進行 Apple 開發的門檻。

 

ios9新特性