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