iOS10 新特性
隨著WWDC16的結(jié)束爷耀，iOS版本號(hào)也跨入了兩位數(shù) 10.0销凑。對(duì)于開(kāi)發(fā)者來(lái)說(shuō)酬滤，好消息是iOS10中并沒(méi)有加入太多內(nèi)容。相比于開(kāi)疆?dāng)U土弄诲，iOS 10 更專注的是對(duì)現(xiàn)有內(nèi)容的改進(jìn)愚战，以彌補(bǔ)之前迅速發(fā)展所留下的一些問(wèn)題，這其實(shí)正是 Apple 當(dāng)下所亟需做的事情。
生態(tài)整合與 Extension 開(kāi)發(fā)
在 iOS 10 里 Apple 延續(xù)了前幾年的策略寂玲，那就是進(jìn)行平臺(tái)整合塔插。全世界現(xiàn)在沒(méi)有另外一家廠商在掌握了包括桌面，移動(dòng)到穿戴的一系列硬件設(shè)備的同時(shí)拓哟，還掌控了相應(yīng)的從操作系統(tǒng)想许，到應(yīng)用軟件，再到軟件商店這樣一套完整的布局断序。Apple 顯然也非常明白這個(gè)優(yōu)勢(shì)意味著什么伸刃。所以近年來(lái) Apple 一直強(qiáng)調(diào)平臺(tái)整合，如果你的應(yīng)用能夠同時(shí)在 iOS逢倍，watchOS 以及 macOS 上工作的話捧颅，毫無(wú)疑問(wèn)將會(huì)更容易吸引用戶以及 Apple 的喜愛(ài)。
另外一點(diǎn)則是各個(gè)應(yīng)用之間的整合和交互较雕。不難發(fā)現(xiàn)碉哑，隨著近年來(lái) extension 開(kāi)發(fā)的興起，Apple 逐漸在從 app 是“用戶體驗(yàn)的核心”這個(gè)理念中轉(zhuǎn)移亮蒋，變?yōu)橛脩魬?yīng)該也可以在通知中心扣典，桌面掛件或者手表這樣的地方完成必要交互。而應(yīng)用之間的交互在以前可以說(shuō)是 iOS 系統(tǒng)的禁區(qū)慎玖，但是去年隨著 Workflow 的成功贮尖，Apple 對(duì)于應(yīng)用之間的交互有助于用戶生產(chǎn)力的提升有了清晰的認(rèn)識(shí)。今年 SDK 中幾個(gè)重大更新其實(shí)都是圍繞這個(gè)主題來(lái)進(jìn)行的趁怔。
1湿硝、Extension 是什么？
首先我們得問(wèn)润努，Extension 是什么关斜？這里可能會(huì)有很多不同的解釋。
一個(gè)很明顯的例子是便是使用了相同術(shù)語(yǔ)的 Firefox 和 Chrome 的 Extension铺浇，這兩大瀏覽器提供了非常豐富的 Extension 用于游覽器本身以及增強(qiáng) Web 瀏覽體驗(yàn)痢畜。確切地說(shuō)，這里的 Extension 是一種 Plugin鳍侣。
還有一個(gè)是 Android 的 Intent丁稀，Intent 使 App 可以實(shí)現(xiàn)相關(guān) Intent，在系統(tǒng)或者一個(gè) App 里倚聚，用戶可以自由的選擇另一個(gè) App 去完成特定的任務(wù)线衫。所以，Android 的 Intent 是一種 IPC（應(yīng)用程序間的通訊）秉沼。
這里的分類有點(diǎn)極端桶雀，畢竟瀏覽器有真正的 Plugin，如 Flash 插件唬复；Android 也有提供 Widget矗积，也更接近系統(tǒng)的 Plugin。在這點(diǎn)上敞咧，我可以說(shuō) iOS/OS X 的 Extension 也是混合了上面提到的一切：既有 Plugin 的部分（如 Today）棘捣，也有 IPC 的部分（如 Share、Photo Editing）休建。
于是讓我們就 Extension 簡(jiǎn)單地理解為：增強(qiáng)系統(tǒng)默認(rèn)功能乍恐，能讓 App 之間的協(xié)同工作成為可能。
2测砂、SiriKit
SiriKit Siri API 的開(kāi)放自然是 iOS 10 SDK 中最激動(dòng)人心也是亮眼的特性茵烈。SiriKit 為我們提供一全套從語(yǔ)音識(shí)別到代碼處理，最后向用戶展示結(jié)果的流程砌些。Apple 加入了一套全新的框架 Intents.framework 來(lái)表示 Siri 獲取并解析的結(jié)果呜投。你的應(yīng)用需要提供一些關(guān)鍵字表明可以接受相關(guān)輸入，而 Siri 擴(kuò)展只需要監(jiān)聽(tīng)系統(tǒng)識(shí)別的用戶意圖 (intent)存璃，作出合適的響應(yīng)仑荐，修改以及實(shí)際操作，最后通過(guò) IntentsUI.framework 提供反饋纵东。整個(gè)過(guò)程非常清晰明了粘招，但是這也意味著開(kāi)發(fā)者所能擁有的自由度有限。
在 iOS 10 中偎球，我們只能用 SiriKit 來(lái)做六類事情洒扎，分別是：
語(yǔ)音和視頻通話
發(fā)送消息
發(fā)送或接收付款
搜索照片
約車
管理健身
如果你的應(yīng)用恰好正在處理這些領(lǐng)域的問(wèn)題的話，添加 Intents Extension 的支持會(huì)是很棒的選擇衰絮。它將提高用戶使用你的應(yīng)用的可能性逊笆，也能讓用戶在其他像是地圖這樣的系統(tǒng)級(jí)應(yīng)用中使用你的服務(wù)。
Siri和Maps通過(guò)Intents extension的擴(kuò)展方式和我們的應(yīng)用進(jìn)行交互岂傲，其中难裆，類型為INExtension的對(duì)象扮演著Intents extension擴(kuò)展中直接協(xié)同Siri對(duì)象共同響應(yīng)用戶請(qǐng)求的關(guān)鍵角色。當(dāng)我們實(shí)現(xiàn)了Intents extension擴(kuò)展并產(chǎn)生了一個(gè)Siri請(qǐng)求事件時(shí)镊掖，一個(gè)典型的Intent事件的處理過(guò)程中總共有這三個(gè)步驟Resolve乃戈、Confirm和Handle：
Resolve階段。在Siri獲取到用戶的語(yǔ)音輸入之后亩进，生成一個(gè)INIntent對(duì)象症虑，將語(yǔ)音中的關(guān)鍵信息提取出來(lái)并且填充對(duì)應(yīng)的屬性。這個(gè)對(duì)象在稍后會(huì)傳遞給我們?cè)O(shè)置好的INExtension子類對(duì)象進(jìn)行處理归薛，根據(jù)子類遵循的不同服務(wù)protocol來(lái)選擇不同的解決方案
Confirm階段谍憔。在上一個(gè)階段通過(guò)handler(for intent:)返回了處理intent的對(duì)象匪蝙，此階段會(huì)依次調(diào)用confirm打頭的實(shí)例方法來(lái)判斷Siri填充的信息是否完成。匹配的判斷結(jié)果包括Exactly one match习贫、Two or more matches以及No match三種情況逛球。這個(gè)過(guò)程中可以讓Siri向用戶征求更具體的參數(shù)信息
在confirm方法執(zhí)行完成之后，Siri進(jìn)行最后的處理階段苫昌，生成答復(fù)對(duì)象颤绕，并且向此intent對(duì)象確認(rèn)處理結(jié)果然后執(zhí)顯示結(jié)果給用戶看
3、iMessage Apps
Message 應(yīng)用大概是 Apple 在宣傳 iOS 10 時(shí)著力最多的部分了祟身。雖然新的貼紙包奥务，自動(dòng)轉(zhuǎn)換顏文字，發(fā)送全屏效果等功能都很酷炫袜硫，但是對(duì)于程序開(kāi)發(fā)者來(lái)說(shuō)氯葬，可能還是對(duì) iMessage Apps 更感興趣。Xcode 8 中婉陷，Apple 在 iOS Application 模板中添加了一類新的項(xiàng)目類型溢谤，Messages Application。同時(shí)憨攒，模擬器甚至還開(kāi)發(fā)了新的雙人對(duì)話模式世杀，以供開(kāi)發(fā)者調(diào)試這類 app。
雖然名義上是獨(dú)立 app肝集，但實(shí)際上工作的依然是一個(gè) extension瞻坝。在該擴(kuò)展中，Messages.framework 將承擔(dān)與系統(tǒng)的 message 界面交互的主要職責(zé)杏瞻。你通過(guò)提供一個(gè)自定義的 View Controller所刀，來(lái)獲取用戶在使用你的 message app 時(shí)進(jìn)行對(duì)話的上下文，以及發(fā)送接收等操作捞挥，并做出合適的響應(yīng)浮创。這個(gè)擴(kuò)展在用來(lái)進(jìn)行直接在 Message 應(yīng)用中一些自定義共享會(huì)很好玩。但是鑒于 Apple 暫時(shí)沒(méi)有打算將 Message.app 跨平臺(tái)的原因砌函，可能也注定了這只會(huì)是一種補(bǔ)充斩披，而無(wú)法成為主流。
4讹俊、User Notifications
通知中心向來(lái)是 iOS 上的兵家必爭(zhēng)之地垦沉。如何提供適時(shí)有效的通知，往往決定了用戶活躍和留存的可能性仍劈。在 iOS 10 上厕倍，Apple 對(duì)通知進(jìn)行了加強(qiáng)和革新。現(xiàn)在贩疙，為了更好地處理和管理通知讹弯，和本地及推送通知相關(guān)的 API 被封裝到了全新的框架 UserNotifications.framework 中况既。在 iOS 10 中，開(kāi)發(fā)者的服務(wù)器有機(jī)會(huì)在本地或者遠(yuǎn)程通知發(fā)送給用戶之前再進(jìn)行修改组民。
另外棒仍，在之前加入了 notification action 以及 text input 的基礎(chǔ)上，iOS 10 又新增了為通知添加音頻邪乍，圖片，甚至視頻的功能《钥ⅲ現(xiàn)在庇楞，你的通知不僅僅是提醒用戶回到應(yīng)用的入口，更成為了一個(gè)展示應(yīng)用內(nèi)容否纬，向用戶傳遞多媒體信息的窗口吕晌。
之后會(huì)詳解。
IDE 和工具改進(jìn)
Xcode 8
在 app 簽名方面临燃，Apple 終于意識(shí)到了他們?cè)?Xcode 7 中所犯得錯(cuò)誤睛驳。我想可能不止一個(gè)人被證書(shū)和描述文件出問(wèn)題時(shí)的 "Fix Issue" 按鈕坑過(guò)。這個(gè)按鈕不僅不會(huì)修正問(wèn)題膜廊，反而會(huì)直接注銷現(xiàn)有的開(kāi)發(fā)者證書(shū)乏沸，然后“自作主張”地重新申請(qǐng)。大多數(shù)情況下爪瓜，這讓事情變得更加糟糕蹬跃。特別是對(duì)于新加入的開(kāi)發(fā)者，他們并不理解 Apple 的證書(shū)系統(tǒng)铆铆，錯(cuò)誤的操作和處置蝶缀，往往讓開(kāi)發(fā)環(huán)境變得不可挽回。Xcode 8 中薄货，同一個(gè)開(kāi)發(fā)者帳號(hào)現(xiàn)在允許多個(gè)開(kāi)發(fā)證書(shū)翁都，而完全重做的 app 簽名系統(tǒng)也足夠好用，并且避免了誤操作的可能性谅猾。在兼顧自動(dòng)配置的基礎(chǔ)上柄慰，也為大型項(xiàng)目和復(fù)雜的 CI 環(huán)境提供了足夠靈活的配置空間，這絕對(duì)值得點(diǎn)贊税娜。
另外 Xcode 終于提供了進(jìn)行代碼編輯器擴(kuò)展的能力∠燃澹現(xiàn)在開(kāi)發(fā)者可以創(chuàng)建 XCSourceEditorExtension 來(lái)對(duì) Xcode 的功能進(jìn)行擴(kuò)展了，在沒(méi)有文檔幫助和官方支持的情況下摸索著為 Xcode 制作插件的歷史也即將結(jié)束巧涧。
另外開(kāi)放了Runtime Issues的使用薯蝎。在開(kāi)發(fā)過(guò)程中，因?yàn)檎Z(yǔ)法或明顯的代碼錯(cuò)誤(例如Retain Cycle)谤绳，編譯器可以發(fā)現(xiàn)并報(bào)黃色或紅色警告占锯。但是一些因?yàn)榇a邏輯導(dǎo)致的錯(cuò)誤袒哥，編譯器并沒(méi)有辦法找到。這時(shí)候可以通過(guò)Xcode8提供的Runtime Issues新特性消略，查找到運(yùn)行過(guò)程中出現(xiàn)的問(wèn)題堡称，并通過(guò)Graph的方式將問(wèn)題可視化的展現(xiàn)給開(kāi)發(fā)者。
Thread Sanitizer spots:新的線程污點(diǎn)清理器, 解決多線程情況下的資源競(jìng)爭(zhēng)條件,數(shù)據(jù)的變化和其它相關(guān)線程的bug
View Debugger:使用更新的帶有更大的保真度和視覺(jué)精度檢查UI約束問(wèn)題的視圖調(diào)試器
Memory Debugger:可以用新的內(nèi)存調(diào)試跟蹤器跟蹤發(fā)出的內(nèi)存泄漏警報(bào)艺演。
Swift 3
Swift 開(kāi)源已經(jīng)過(guò)去半年時(shí)間却紧。在 Swift 2.2 中我們已經(jīng)看到了開(kāi)源的社區(qū)力量對(duì)語(yǔ)言產(chǎn)生的深刻影響，而在 Swift 3 中這一影響的效果將更加明顯胎撤。
最大的變化在于 Foundation 框架的重新導(dǎo)入晓殊，可能過(guò)一段時(shí)間再回頭看的話，這將標(biāo)志著 Swift 與 Objective-C 徹底分家伤提。Foundation 框架中的 API 現(xiàn)在以更符合 Swift 的方式被導(dǎo)入到語(yǔ)言中巫俺。大體來(lái)說(shuō)，這些變化包括去除NS前綴肿男，將絕大部分 class 轉(zhuǎn)換為 struct (雖然底層還是 copy-on-write 的引用實(shí)現(xiàn)介汹，可以參看ReferenceConvertible協(xié)議的內(nèi)容)，去掉 API 中重復(fù)的語(yǔ)義等舶沛。如果在當(dāng)前你還能看出 Swift 和 Objective-C 在使用 Foundation 或者說(shuō)開(kāi)發(fā) app 時(shí)同根同源的話嘹承，Swift 3 正式發(fā)布后可能情況會(huì)大不相同。
由于引用類型向值類型的轉(zhuǎn)換如庭，也將導(dǎo)致我們?cè)谑褂?Swift 開(kāi)發(fā)時(shí)的思考方式發(fā)生變化赶撰。以往的 Foundation 框架中類型的可變性是由不可變類型和它的可變類型版本 (比如NSData和NSMutableData) 來(lái)進(jìn)行區(qū)分的。而在 Swift 3 中柱彻，一般來(lái)說(shuō)將只有作為結(jié)構(gòu)體的不可變類型 (比如Data)豪娜，對(duì)于這類結(jié)構(gòu)體的改變，將會(huì)是更安全的基于寫時(shí)復(fù)制的行為哟楷，而不再是原來(lái)可變對(duì)象那樣的危險(xiǎn)的內(nèi)存操作瘤载。這在很多時(shí)候除了保證數(shù)據(jù)共享時(shí)的安全性以外，內(nèi)部的引用特性也保證了調(diào)用速度卖擅。實(shí)際上鸣奔，因?yàn)闇p少了不必要的復(fù)制 (比如根據(jù)一個(gè)不可變對(duì)象創(chuàng)建相應(yīng)的可變對(duì)象)，實(shí)際上通過(guò) Swift 3 的 API 使用 Foundation 的速度將比原來(lái)更快惩阶！
