開發者需要知道的iOS 8 SDK新特性
WWDC 2014 已經過去一個多月。最激動人心的莫過于 Swift 這門新語言的發布，我在之前已經寫了一些關于這么語言的第一印象和一些初步的探索。 在寫這篇文章的時候，Swift 隨著 beta 3 得到了重大的更新，而這門語言現在也還在劇烈的變化之中。對于 Swift，現在大家的探索才剛剛上路，很多背后的機制還并不是非常清楚，或者有可能發生巨大的變化，因此在這里和之后的幾篇文章，直到穩定的 1.0 版本出現，我不再打算繼續深入針對 Swift 寫什么文章。這基本出于對未來可能的變化會容易誤導讀到文章的新人的考慮，而并不是說建議我們現在可以放下 Swift，而安心等待正式版本。在我的觀念里，對于一個尚不穩定的版本的探索和研究，遠比之后被動去接受別人的結果要來的有趣得多，理解也會深入得多。 因此如果您有時間的話，建議還是能盡早接觸和使用會比較好。Github 上有一個不錯的 repo，記錄了 Swift 一路以來的變化，并探討了不足以及以后可能的變化，希望深研 Swift 的同學不妨關注看看。
這篇總覽先簡要介紹下在我看來作為 iOS 開發者應該關注的開發時的變化，在之后一系列文章里我會對其中的某幾個部分詳細探討一下，而其余的可能就在本文中做簡介。總而言之，這次 WWDC 2014 的相關筆記（現在來說的話是暫定計劃要寫的內容）大概整理如下：
開發者所需要知道的 iOS8 SDK 新特性：
- iOS 界面開發的大一統
- iOS 通知中心擴展制作入門
- 可視化開發，IB 的新時代
- TableView 和 CollectionView
- iOS 和 Mac 整合開發
- 通知中心和應用使用重心的改變
- 應用擴展 (Extension)
這是一個千呼萬喚始出來的特性，也是一個可以發揮無限想象力的特性?，F在 Apple 允許我們在 app 中添加一個新的 target，用來提供一些擴展功能：比如在系統的通知中心中顯示一個自己的 widget，在某些應用的 Action 中加入自己的操作，在分享按扭里加入自己的條目，更甚至于添加自定義的鍵盤等等。每一種操作對應這一個應用擴展的入口，在開發中我們只需要在工程中新建立 一個對應相應入口的 target，就能從一個很好的模板開始進行一些列開發，來實現這些傳統意義上可能需要越獄才能實現的功能。
對于應用擴展，Apple 將其定義為 App 的功能的自然延伸，因此不是單獨存在的，而是隨著應用本體的包作為附屬而被一同下載和安裝到用戶的設備中的，用戶需要在之后選擇將其開啟。另外，由于應用 擴展和應用是屬于兩個不同的 target 的，因此它們之間的數據和操作上的交互遵循的是另一套原則。關于應用擴展的更詳細的內容，我計劃在之后通過一個通知中心的 today 小框體控件的例子來詳細說明。
App 開發時的統一
隨著一代代的 iPhone 和 iPad 的出現，iOS 設備的屏幕尺寸也開始出現分裂的趨勢。之前一套屏幕兩個方向吃遍全世界的美好時光已然不再，現在至少已經有 3.5 寸，4寸和 10(7) 寸三種分辨率/尺寸的機型需要進行適配，再考慮到每個尺寸的橫豎兩種方向，以及日益呼聲愈高的 4.7 寸和 5.5 寸的 iPhone，可以相見現在的布局方式已然不堪重負。雖然在 iOS 6 Apple 就推出了 Auto Layout 來輔助完成布局工作，解決了原來的相對布局的一些問題，但是在以絕對尺寸為度量的坐標系統中，難免還是有所掣肘。在 iOS 8 中，Apple 的工程師們可以說“極富想象力”地干脆把限制和表征屏幕尺寸的長寬數字給去掉了，取而代之使用 size classes 的概念，將長寬尺寸按照設備類型和方向歸類為 regular 和 compact 兩類。通過為不同的設備定義尺寸分類，用來定義同類型的操作特性，這使得開發者更容易利用一套 UI 來適配不同的屏幕。
iOS 8 在 UIKit 中添加了一整套使用 size classes 來進行布局的 API，并且將原有的比較復雜（或者說有些冗余）的 API 作廢了。結合新的 Interface Builder 和 Auto Layout，可以說對于多尺寸屏幕的適配得到了前所未有的簡化。
不僅如此，像是原來 iPad 專有的 SplitController 等也被以適應不同 regular 和 compact 的尺寸類型的形式 port 到了 iPhone 上，在程序設計方面兩者更加統一了。另外，一直陪伴我們的 UIAlertView 和 UIActionSheet 這些老面孔也將退出舞臺，取而代之全部統一以 UIViewController 來呈現。
這是一個好的開始，也是一個好的變化?？梢钥吹?Apple 在避免平臺碎片化上正在努力。
iCloud 相關
作為幫主的最后一件作品，iCloud 其實非常可惜，一直沒有能在 Apple 的生態圈中特別出彩。首先主要是由于 iCloud 相關的開發和 API 使用起來有一定難度，另外就是之前的 SDK 在和 iCloud 相關的各種 API 或多或少都有一些小問題。在 iOS 7 中 iCloud，特別是 iCloud 和 CoreData 結合的部分的 API 的穩定性和易用性得到了很大的改善。而在 iOS 8 中，Apple 更進一步，推出了全新的被稱為 Cloud Kit 的框架。如果您熟悉或者使用過像 Parse 或者 AVOS Cloud 之類的 BaaS 的話，可能會對這個框架感到親切。但是和傳統的 BaaS 稍有不同的是，Cloud Kit 更多的是傾向于使用 iCloud 對數據進行集成。你可以不更改應用現有的數據模型和結構，而只是使用 Cloud Kit 來從云端獲取數據或者向云端存儲數據。
相比與 Parse 和 AVOS 的 API，由于可以和系統深度集成，有很多在其他類似 BaaS 中沒有的特性 (比如訂閱某個公共對象)。但是因為是 Apple 自家產品，其缺點也是顯而易見并且致命的 -- 你無法在非 Apple 的平臺上使用這個框架。也就是說，如果你的應用火了，想接著出個安卓版的話，那就只能呵呵了。所以雖然 Cloud Kit 看起來很美好，而且基本等同于免費使用，但是因為平臺的限制，而它所涉及的內容又是對跨平臺需求很強又繞不開的數據，所以可能實際中能實用的機會并不太 多。當然，如果應用是 for iOS only 的話，使用 Cloud Kit 應該是很不錯的選擇。
關于云端存儲的另一個新變化是存儲源的可變化。以前我們基本別無選擇，想使用沙盒外的文件的話，要么就是 iCloud 同一個 container 內的文件，要么就需要來個像 Dropbox 這樣的第三方庫去做一堆登陸驗證什么的。不論那種方式都可以說挺麻煩的。而現在隨著 iCloud Drive 的引入，在應用間共享訪問文件就變得很容易了。更甚，我們現在可以使用 UIDocumentPickerViewController 來從第三方存儲 (以及第三方 app 通過應用擴展所實現的存儲) 中選取文件。
Handoff 及其他 iOS 與 Mac 的協同開發
雖然 PC 市場一直疲軟，但是得益于 iDevice 的銷售和品牌接受度的回升，Mac 的銷量反而逆市上揚。這點在國內尤為明顯，確實可以感覺到身邊開始使用 Mac 的人在逐漸變多，這對于我們這些 iOS 開發者來說其實是一個不錯的機會。iOS 8 中的 Handoff 機制（就是可以在 Mac 上繼續完成在 iOS 上半途的工作）給 for both iOS and Mac 的應用帶來了一個不錯的契合點和賣點。而近年來在整合兩個系統上的動作，也可以看得出 Apple 確實希望利用龐大的 iOS 的開發人員資源來進一步完善和豐富 Mac。iOS 開發和 Mac 開發其實同根同源，因此在轉換的時候并不是很困難的事情。
我們一直以來都可以寫出跨兩個平臺的 Model 部分的代碼，而只需要關心在表現上的區別。而現在 Cocoa 和 CocoaTouch 在官方支持自制 framework 后，利用 framework 來完成這一過程可以說更加簡單了。
Health Kit 和 Home Kit
這是對應兩個現在很熱的領域 -- 可穿戴式設備和智能家電 -- 所加入的框架。基本上來說 Apple 想做的事情就是以 iOS 為基礎，為其他 app 建立一個平臺以及成為用戶數據的管理者。
Health Kit 就是一個用戶體征參數的數據庫，第三方應用可以向用戶申請權限使用其中的數據或是向其中匯報數據。而 Home Kit 則以家庭，房間和設備的組織形式來管理和控制家中適配了 Home Kit 的智能家電。這兩個超級年輕的框架的 API 相對都還比較簡單，結構也很好，相信稍有經驗的 iOS 開發者都能在很快掌握用法。唯一的限制在于作為普通開發者（比如我這樣的只能自己業余玩的）可能手邊現在不會有合適的設備來進行測試，所以很多東西其實沒 有辦法驗證。不過對于 Home Kit，Apple給我們提供了一個模擬器來模擬智能家電設備，您可以在 Xcode 6 的 Open Developer Tool 菜單中找到 Home Kit Accessory Simulator。使用模擬器可以發現，添加并且控制自定義的智能家電，用來前期開發還是蠻方便的。
如果能入手一些適配于 Health Kit 或者 Home Kit 的設備的話，我可能會補充一些關于這方面的開發心得。
游戲方面
最大的改變莫過于 Scene Kit 的加入了。不過游戲天生的容易跨平臺的特性 (并且也有這方面的強烈需求)，與平臺限制的 Sprite Kit 是沖突的，所以去年的 Sprite Kit 也還沒多少人用。暫時看來這個世界現在是，并且在一段時間內還會是被 Cocos2dx/Unity 所統治的。Scene Kit 的未來估計會和 Sprite Kit 比較類似，作為對于一直進行 iOS 應用開發的開發者來說，有著不需要學習和熟悉新語言的優勢，容易與系統的其他框架進行集成，所以用來轉型還算不錯的選擇。但除此之外其他方面可能也并沒有 多少可以吸引人的地方了。
另一個重大改變是對于 A7 和以上級別的 GPU 推出了一套全新的稱為 Metal 的繪制 API，從 Keynote 的 Zen Garden 的演示來看，Metal 的性能毋庸置疑是令人折服的，Metal 的渲染方式和著色器也相當有趣。但是其實這些內容更多地是偏向底層以及面向引擎開發的，對于使用游戲引擎來制作游戲的大多數開發者來說，并不需要知道或者 理解其中的東西。在 A7 的芯片下使用 Apple 自家的 Sprite Kit 或者 Scene Kit 的話，就可以直接受益于 Metal，而其他一些知名的第三方引擎，比如 Unity 和 UE 也都會在 iOS 8 推出后支持 Metal。因此，作為引擎使用者，并不需要做出除了升級開發使用的游戲引擎之外的任何改變。
其他重要改動
Local 和 Remote 通知的變化
現在需要顯示 UI 或者播放聲音的通知，包括 Local 通知也需要實現彈窗獲得用戶許可了。使用 -registerUserNotificationSettings: 來向用戶獲取許可。作為補償，現在對于不需要打擾用戶（也就是 iOS 7 加入的靜默通知）的類型不再需要彈框獲取用戶許可。不過因為本地推送是需要許可的，所以無論怎樣如果你想要依靠通知來提高用戶留存率的話，現在都繞不開用 戶許可了。
另外，通知中心加入了非常方便的 Action 特性，用戶可以在收到通知后，在不打開應用的情況下完成一些操作。可以說配合通知中心的 Today 擴展，用戶現在在很可能可以在不打開應用的情況下就獲取到他們想要的信息，并完成互動。這對于開發者可以說是一件喜憂參半的事情，一方面我們可以給用戶提 供更好更快的使用體驗，但是另一方面這將降低用戶打開應用的意愿。不過 Apple 現在的總體思路還是 app 的體驗才是最重要的，所以正確的道路應該還是優先做好 app 的體驗，并且摸索一個應用和通知之間的平衡點，讓大家都滿意。
CoreLocation
CoreLocation 室內定位。現在 CL 可以給出在建筑物中的樓層定位信息了，直接訪問 CLLocation 實例的 floor，如果當前位置可用的話，會返回一個包含位置信息的非 nil 的 CLFloor 以標識當前樓層。這個使得定位應用的可能性大大擴展了，想象一下在復雜的地鐵站或者大廈里迷路的時候，還可以依賴定位系統，幸福感涌上心頭啊。
Touch ID
Touch ID API，說是開放了 Touch ID 的驗證，但是實際上能做的事情還是比較有限。因為現在提供的 API 只能驗證用戶是不是手機主人本人，而不能給出一個識別的標志或者唯一編碼，所以想用 Touch ID 做注冊登陸什么的話可能還是不太現實。不過在進行支付驗證之類的已登錄后的再次確認操作時就比較好用?，F在看來的話這組 API 就是為了簡化像 Paypal 或者支付寶這樣的第三方支付和確認的流程的。希望之后能繼續放開，如果能給一個唯一標識的話，也許就可以干掉整個討厭的注冊和登陸系統了。
相機和照片
新增加了 Photos.framework 框架，這個框架用于與系統內置的 Photo 應用進行交互，不僅可以替代原來的 Assets Library 作為照片和視頻的選取，還能與 iCloud 照片流進行交互。除此之外，一個很重要的特性是還可以監聽其他應用對于照片的改變，可以說整個框架非常靈活。
本文鏈接：http://www.cocoachina.com/applenews/devnews/2014/0716/9157.html
【編輯推薦】
【責任編輯：chenqingxiang TEL：（010）68476606】
