[[116420]]

WWDC 2014 已經(jīng)過去一個(gè)多月。最激動人心的莫過于 Swift 這門新語言的發(fā)布，我在之前已經(jīng)寫了一些關(guān)于這么語言的第一印象和一些初步的探索。 在寫這篇文章的時(shí)候，Swift 隨著 beta 3 得到了重大的更新，而這門語言現(xiàn)在也還在劇烈的變化之中。對于 Swift，現(xiàn)在大家的探索才剛剛上路，很多背后的機(jī)制還并不是非常清楚，或者有可能發(fā)生巨大的變化，因此在這里和之后的幾篇文章，直到穩(wěn)定的 1.0 版本出現(xiàn)，我不再打算繼續(xù)深入針對 Swift 寫什么文章。這基本出于對未來可能的變化會容易誤導(dǎo)讀到文章的新人的考慮，而并不是說建議我們現(xiàn)在可以放下 Swift，而安心等待正式版本。在我的觀念里，對于一個(gè)尚不穩(wěn)定的版本的探索和研究，遠(yuǎn)比之后被動去接受別人的結(jié)果要來的有趣得多，理解也會深入得多。 因此如果您有時(shí)間的話，建議還是能盡早接觸和使用會比較好。Github 上有一個(gè)不錯(cuò)的 repo，記錄了 Swift 一路以來的變化，并探討了不足以及以后可能的變化，希望深研 Swift 的同學(xué)不妨關(guān)注看看。

這篇總覽先簡要介紹下在我看來作為 iOS 開發(fā)者應(yīng)該關(guān)注的開發(fā)時(shí)的變化，在之后一系列文章里我會對其中的某幾個(gè)部分詳細(xì)探討一下，而其余的可能就在本文中做簡介。總而言之，這次 WWDC 2014 的相關(guān)筆記（現(xiàn)在來說的話是暫定計(jì)劃要寫的內(nèi)容）大概整理如下：

開發(fā)者所需要知道的 iOS8 SDK 新特性：

• iOS 界面開發(fā)的大一統(tǒng)
• iOS 通知中心擴(kuò)展制作入門
• 可視化開發(fā)，IB 的新時(shí)代
• TableView 和 CollectionView
• iOS 和 Mac 整合開發(fā)
• 通知中心和應(yīng)用使用重心的改變
• 應(yīng)用擴(kuò)展 (Extension)

這是一個(gè)千呼萬喚始出來的特性，也是一個(gè)可以發(fā)揮無限想象力的特性。現(xiàn)在 Apple 允許我們在 app 中添加一個(gè)新的 target，用來提供一些擴(kuò)展功能：比如在系統(tǒng)的通知中心中顯示一個(gè)自己的 widget，在某些應(yīng)用的 Action 中加入自己的操作，在分享按扭里加入自己的條目，更甚至于添加自定義的鍵盤等等。每一種操作對應(yīng)這一個(gè)應(yīng)用擴(kuò)展的入口，在開發(fā)中我們只需要在工程中新建立 一個(gè)對應(yīng)相應(yīng)入口的 target，就能從一個(gè)很好的模板開始進(jìn)行一些列開發(fā)，來實(shí)現(xiàn)這些傳統(tǒng)意義上可能需要越獄才能實(shí)現(xiàn)的功能。

對于應(yīng)用擴(kuò)展，Apple 將其定義為 App 的功能的自然延伸，因此不是單獨(dú)存在的，而是隨著應(yīng)用本體的包作為附屬而被一同下載和安裝到用戶的設(shè)備中的，用戶需要在之后選擇將其開啟。另外，由于應(yīng)用 擴(kuò)展和應(yīng)用是屬于兩個(gè)不同的 target 的，因此它們之間的數(shù)據(jù)和操作上的交互遵循的是另一套原則。關(guān)于應(yīng)用擴(kuò)展的更詳細(xì)的內(nèi)容，我計(jì)劃在之后通過一個(gè)通知中心的 today 小框體控件的例子來詳細(xì)說明。

App 開發(fā)時(shí)的統(tǒng)一

隨著一代代的 iPhone 和 iPad 的出現(xiàn)，iOS 設(shè)備的屏幕尺寸也開始出現(xiàn)分裂的趨勢。之前一套屏幕兩個(gè)方向吃遍全世界的美好時(shí)光已然不再，現(xiàn)在至少已經(jīng)有 3.5 寸，4寸和 10(7) 寸三種分辨率/尺寸的機(jī)型需要進(jìn)行適配，再考慮到每個(gè)尺寸的橫豎兩種方向，以及日益呼聲愈高的 4.7 寸和 5.5 寸的 iPhone，可以相見現(xiàn)在的布局方式已然不堪重負(fù)。雖然在 iOS 6 Apple 就推出了 Auto Layout 來輔助完成布局工作，解決了原來的相對布局的一些問題，但是在以絕對尺寸為度量的坐標(biāo)系統(tǒng)中，難免還是有所掣肘。在 iOS 8 中，Apple 的工程師們可以說“極富想象力”地干脆把限制和表征屏幕尺寸的長寬數(shù)字給去掉了，取而代之使用 size classes 的概念，將長寬尺寸按照設(shè)備類型和方向歸類為 regular 和 compact 兩類。通過為不同的設(shè)備定義尺寸分類，用來定義同類型的操作特性，這使得開發(fā)者更容易利用一套 UI 來適配不同的屏幕。

iOS 8 在 UIKit 中添加了一整套使用 size classes 來進(jìn)行布局的 API，并且將原有的比較復(fù)雜（或者說有些冗余）的 API 作廢了。結(jié)合新的 Interface Builder 和 Auto Layout，可以說對于多尺寸屏幕的適配得到了前所未有的簡化。

不僅如此，像是原來 iPad 專有的 SplitController 等也被以適應(yīng)不同 regular 和 compact 的尺寸類型的形式 port 到了 iPhone 上，在程序設(shè)計(jì)方面兩者更加統(tǒng)一了。另外，一直陪伴我們的 UIAlertView 和 UIActionSheet 這些老面孔也將退出舞臺，取而代之全部統(tǒng)一以 UIViewController 來呈現(xiàn)。

這是一個(gè)好的開始，也是一個(gè)好的變化。可以看到 Apple 在避免平臺碎片化上正在努力。

iCloud 相關(guān)

作為幫主的最后一件作品，iCloud 其實(shí)非常可惜，一直沒有能在 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 更進(jìn)一步，推出了全新的被稱為 Cloud Kit 的框架。如果您熟悉或者使用過像 Parse 或者 AVOS Cloud 之類的 BaaS 的話，可能會對這個(gè)框架感到親切。但是和傳統(tǒng)的 BaaS 稍有不同的是，Cloud Kit 更多的是傾向于使用 iCloud 對數(shù)據(jù)進(jìn)行集成。你可以不更改應(yīng)用現(xiàn)有的數(shù)據(jù)模型和結(jié)構(gòu)，而只是使用 Cloud Kit 來從云端獲取數(shù)據(jù)或者向云端存儲數(shù)據(jù)。

相比與 Parse 和 AVOS 的 API，由于可以和系統(tǒng)深度集成，有很多在其他類似 BaaS 中沒有的特性 (比如訂閱某個(gè)公共對象)。但是因?yàn)槭?Apple 自家產(chǎn)品，其缺點(diǎn)也是顯而易見并且致命的 -- 你無法在非 Apple 的平臺上使用這個(gè)框架。也就是說，如果你的應(yīng)用火了，想接著出個(gè)安卓版的話，那就只能呵呵了。所以雖然 Cloud Kit 看起來很美好，而且基本等同于免費(fèi)使用，但是因?yàn)槠脚_的限制，而它所涉及的內(nèi)容又是對跨平臺需求很強(qiáng)又繞不開的數(shù)據(jù)，所以可能實(shí)際中能實(shí)用的機(jī)會并不太 多。當(dāng)然，如果應(yīng)用是 for iOS only 的話，使用 Cloud Kit 應(yīng)該是很不錯(cuò)的選擇。

關(guān)于云端存儲的另一個(gè)新變化是存儲源的可變化。以前我們基本別無選擇，想使用沙盒外的文件的話，要么就是 iCloud 同一個(gè) container 內(nèi)的文件，要么就需要來個(gè)像 Dropbox 這樣的第三方庫去做一堆登陸驗(yàn)證什么的。不論那種方式都可以說挺麻煩的。而現(xiàn)在隨著 iCloud Drive 的引入，在應(yīng)用間共享訪問文件就變得很容易了。更甚，我們現(xiàn)在可以使用 UIDocumentPickerViewController 來從第三方存儲 (以及第三方 app 通過應(yīng)用擴(kuò)展所實(shí)現(xiàn)的存儲) 中選取文件。

Handoff 及其他 iOS 與 Mac 的協(xié)同開發(fā)

雖然 PC 市場一直疲軟，但是得益于 iDevice 的銷售和品牌接受度的回升，Mac 的銷量反而逆市上揚(yáng)。這點(diǎn)在國內(nèi)尤為明顯，確實(shí)可以感覺到身邊開始使用 Mac 的人在逐漸變多，這對于我們這些 iOS 開發(fā)者來說其實(shí)是一個(gè)不錯(cuò)的機(jī)會。iOS 8 中的 Handoff 機(jī)制（就是可以在 Mac 上繼續(xù)完成在 iOS 上半途的工作）給 for both iOS and Mac 的應(yīng)用帶來了一個(gè)不錯(cuò)的契合點(diǎn)和賣點(diǎn)。而近年來在整合兩個(gè)系統(tǒng)上的動作，也可以看得出 Apple 確實(shí)希望利用龐大的 iOS 的開發(fā)人員資源來進(jìn)一步完善和豐富 Mac。iOS 開發(fā)和 Mac 開發(fā)其實(shí)同根同源，因此在轉(zhuǎn)換的時(shí)候并不是很困難的事情。

我們一直以來都可以寫出跨兩個(gè)平臺的 Model 部分的代碼，而只需要關(guān)心在表現(xiàn)上的區(qū)別。而現(xiàn)在 Cocoa 和 CocoaTouch 在官方支持自制 framework 后，利用 framework 來完成這一過程可以說更加簡單了。

Health Kit 和 Home Kit

這是對應(yīng)兩個(gè)現(xiàn)在很熱的領(lǐng)域 -- 可穿戴式設(shè)備和智能家電 -- 所加入的框架。基本上來說 Apple 想做的事情就是以 iOS 為基礎(chǔ)，為其他 app 建立一個(gè)平臺以及成為用戶數(shù)據(jù)的管理者。

Health Kit 就是一個(gè)用戶體征參數(shù)的數(shù)據(jù)庫，第三方應(yīng)用可以向用戶申請權(quán)限使用其中的數(shù)據(jù)或是向其中匯報(bào)數(shù)據(jù)。而 Home Kit 則以家庭，房間和設(shè)備的組織形式來管理和控制家中適配了 Home Kit 的智能家電。這兩個(gè)超級年輕的框架的 API 相對都還比較簡單，結(jié)構(gòu)也很好，相信稍有經(jīng)驗(yàn)的 iOS 開發(fā)者都能在很快掌握用法。唯一的限制在于作為普通開發(fā)者（比如我這樣的只能自己業(yè)余玩的）可能手邊現(xiàn)在不會有合適的設(shè)備來進(jìn)行測試，所以很多東西其實(shí)沒 有辦法驗(yàn)證。不過對于 Home Kit，Apple給我們提供了一個(gè)模擬器來模擬智能家電設(shè)備，您可以在 Xcode 6 的 Open Developer Tool 菜單中找到 Home Kit Accessory Simulator。使用模擬器可以發(fā)現(xiàn)，添加并且控制自定義的智能家電，用來前期開發(fā)還是蠻方便的。

如果能入手一些適配于 Health Kit 或者 Home Kit 的設(shè)備的話，我可能會補(bǔ)充一些關(guān)于這方面的開發(fā)心得。

游戲方面

最大的改變莫過于 Scene Kit 的加入了。不過游戲天生的容易跨平臺的特性 (并且也有這方面的強(qiáng)烈需求)，與平臺限制的 Sprite Kit 是沖突的，所以去年的 Sprite Kit 也還沒多少人用。暫時(shí)看來這個(gè)世界現(xiàn)在是，并且在一段時(shí)間內(nèi)還會是被 Cocos2dx/Unity 所統(tǒng)治的。Scene Kit 的未來估計(jì)會和 Sprite Kit 比較類似，作為對于一直進(jìn)行 iOS 應(yīng)用開發(fā)的開發(fā)者來說，有著不需要學(xué)習(xí)和熟悉新語言的優(yōu)勢，容易與系統(tǒng)的其他框架進(jìn)行集成，所以用來轉(zhuǎn)型還算不錯(cuò)的選擇。但除此之外其他方面可能也并沒有 多少可以吸引人的地方了。

另一個(gè)重大改變是對于 A7 和以上級別的 GPU 推出了一套全新的稱為 Metal 的繪制 API，從 Keynote 的 Zen Garden 的演示來看，Metal 的性能毋庸置疑是令人折服的，Metal 的渲染方式和著色器也相當(dāng)有趣。但是其實(shí)這些內(nèi)容更多地是偏向底層以及面向引擎開發(fā)的，對于使用游戲引擎來制作游戲的大多數(shù)開發(fā)者來說，并不需要知道或者 理解其中的東西。在 A7 的芯片下使用 Apple 自家的 Sprite Kit 或者 Scene Kit 的話，就可以直接受益于 Metal，而其他一些知名的第三方引擎，比如 Unity 和 UE 也都會在 iOS 8 推出后支持 Metal。因此，作為引擎使用者，并不需要做出除了升級開發(fā)使用的游戲引擎之外的任何改變。

其他重要改動

Local 和 Remote 通知的變化

現(xiàn)在需要顯示 UI 或者播放聲音的通知，包括 Local 通知也需要實(shí)現(xiàn)彈窗獲得用戶許可了。使用 -registerUserNotificationSettings: 來向用戶獲取許可。作為補(bǔ)償，現(xiàn)在對于不需要打擾用戶（也就是 iOS 7 加入的靜默通知）的類型不再需要彈框獲取用戶許可。不過因?yàn)楸镜赝扑褪切枰S可的，所以無論怎樣如果你想要依靠通知來提高用戶留存率的話，現(xiàn)在都繞不開用 戶許可了。

另外，通知中心加入了非常方便的 Action 特性，用戶可以在收到通知后，在不打開應(yīng)用的情況下完成一些操作。可以說配合通知中心的 Today 擴(kuò)展，用戶現(xiàn)在在很可能可以在不打開應(yīng)用的情況下就獲取到他們想要的信息，并完成互動。這對于開發(fā)者可以說是一件喜憂參半的事情，一方面我們可以給用戶提 供更好更快的使用體驗(yàn)，但是另一方面這將降低用戶打開應(yīng)用的意愿。不過 Apple 現(xiàn)在的總體思路還是 app 的體驗(yàn)才是最重要的，所以正確的道路應(yīng)該還是優(yōu)先做好 app 的體驗(yàn)，并且摸索一個(gè)應(yīng)用和通知之間的平衡點(diǎn)，讓大家都滿意。

CoreLocation

CoreLocation 室內(nèi)定位。現(xiàn)在 CL 可以給出在建筑物中的樓層定位信息了，直接訪問 CLLocation 實(shí)例的 floor，如果當(dāng)前位置可用的話，會返回一個(gè)包含位置信息的非 nil 的 CLFloor 以標(biāo)識當(dāng)前樓層。這個(gè)使得定位應(yīng)用的可能性大大擴(kuò)展了，想象一下在復(fù)雜的地鐵站或者大廈里迷路的時(shí)候，還可以依賴定位系統(tǒng)，幸福感涌上心頭啊。

Touch ID

Touch ID API，說是開放了 Touch ID 的驗(yàn)證，但是實(shí)際上能做的事情還是比較有限。因?yàn)楝F(xiàn)在提供的 API 只能驗(yàn)證用戶是不是手機(jī)主人本人，而不能給出一個(gè)識別的標(biāo)志或者唯一編碼，所以想用 Touch ID 做注冊登陸什么的話可能還是不太現(xiàn)實(shí)。不過在進(jìn)行支付驗(yàn)證之類的已登錄后的再次確認(rèn)操作時(shí)就比較好用。現(xiàn)在看來的話這組 API 就是為了簡化像 Paypal 或者支付寶這樣的第三方支付和確認(rèn)的流程的。希望之后能繼續(xù)放開，如果能給一個(gè)唯一標(biāo)識的話，也許就可以干掉整個(gè)討厭的注冊和登陸系統(tǒng)了。

相機(jī)和照片

新增加了 Photos.framework 框架，這個(gè)框架用于與系統(tǒng)內(nèi)置的 Photo 應(yīng)用進(jìn)行交互，不僅可以替代原來的 Assets Library 作為照片和視頻的選取，還能與 iCloud 照片流進(jìn)行交互。除此之外，一個(gè)很重要的特性是還可以監(jiān)聽其他應(yīng)用對于照片的改變，可以說整個(gè)框架非常靈活。

本文鏈接：http://www.cocoachina.com/applenews/devnews/2014/0716/9157.html  

【編輯推薦】

1. ShareSDK重金收購Mob.com 全面轉(zhuǎn)型移動開發(fā)者服務(wù)平臺
2. Android開發(fā)奧秘：工具IDE，SDK，谷歌服務(wù)等一網(wǎng)打盡

【責(zé)任編輯：chenqingxiang TEL：（010）68476606】