iOS10 新特性
隨著WWDC16的結(jié)束，iOS版本號也跨入了兩位數(shù) 10.0。對于開發(fā)者來說，好消息是iOS10中并沒有加入太多內(nèi)容。相比于開疆?dāng)U土，iOS 10 更專注的是對現(xiàn)有內(nèi)容的改進(jìn)，以彌補(bǔ)之前迅速發(fā)展所留下的一些問題，這其實(shí)正是 Apple 當(dāng)下所亟需做的事情。
生態(tài)整合與 Extension 開發(fā)
在 iOS 10 里 Apple 延續(xù)了前幾年的策略，那就是進(jìn)行平臺整合。全世界現(xiàn)在沒有另外一家廠商在掌握了包括桌面，移動到穿戴的一系列硬件設(shè)備的同時，還掌控了相應(yīng)的從操作系統(tǒng)，到應(yīng)用軟件，再到軟件商店這樣一套完整的布局。Apple 顯然也非常明白這個優(yōu)勢意味著什么。所以近年來 Apple 一直強(qiáng)調(diào)平臺整合，如果你的應(yīng)用能夠同時在 iOS，watchOS 以及 macOS 上工作的話，毫無疑問將會更容易吸引用戶以及 Apple 的喜愛。
另外一點(diǎn)則是各個應(yīng)用之間的整合和交互。不難發(fā)現(xiàn)，隨著近年來 extension 開發(fā)的興起，Apple 逐漸在從 app 是“用戶體驗(yàn)的核心”這個理念中轉(zhuǎn)移，變?yōu)橛脩魬?yīng)該也可以在通知中心，桌面掛件或者手表這樣的地方完成必要交互。而應(yīng)用之間的交互在以前可以說是 iOS 系統(tǒng)的禁區(qū)，但是去年隨著 Workflow 的成功，Apple 對于應(yīng)用之間的交互有助于用戶生產(chǎn)力的提升有了清晰的認(rèn)識。今年 SDK 中幾個重大更新其實(shí)都是圍繞這個主題來進(jìn)行的。
1、Extension 是什么？
首先我們得問，Extension 是什么？這里可能會有很多不同的解釋。
一個很明顯的例子是便是使用了相同術(shù)語的 Firefox 和 Chrome 的 Extension，這兩大瀏覽器提供了非常豐富的 Extension 用于游覽器本身以及增強(qiáng) Web 瀏覽體驗(yàn)。確切地說，這里的 Extension 是一種 Plugin。
還有一個是 Android 的 Intent，Intent 使 App 可以實(shí)現(xiàn)相關(guān) Intent，在系統(tǒng)或者一個 App 里，用戶可以自由的選擇另一個 App 去完成特定的任務(wù)。所以，Android 的 Intent 是一種 IPC（應(yīng)用程序間的通訊）。
這里的分類有點(diǎn)極端，畢竟瀏覽器有真正的 Plugin，如 Flash 插件；Android 也有提供 Widget，也更接近系統(tǒng)的 Plugin。在這點(diǎn)上，我可以說 iOS/OS X 的 Extension 也是混合了上面提到的一切：既有 Plugin 的部分（如 Today），也有 IPC 的部分（如 Share、Photo Editing）。
于是讓我們就 Extension 簡單地理解為：增強(qiáng)系統(tǒng)默認(rèn)功能，能讓 App 之間的協(xié)同工作成為可能。
2、SiriKit
SiriKit Siri API 的開放自然是 iOS 10 SDK 中最激動人心也是亮眼的特性。SiriKit 為我們提供一全套從語音識別到代碼處理，最后向用戶展示結(jié)果的流程。Apple 加入了一套全新的框架 Intents.framework 來表示 Siri 獲取并解析的結(jié)果。你的應(yīng)用需要提供一些關(guān)鍵字表明可以接受相關(guān)輸入，而 Siri 擴(kuò)展只需要監(jiān)聽系統(tǒng)識別的用戶意圖 (intent)，作出合適的響應(yīng)，修改以及實(shí)際操作，最后通過 IntentsUI.framework 提供反饋。整個過程非常清晰明了，但是這也意味著開發(fā)者所能擁有的自由度有限。
在 iOS 10 中，我們只能用 SiriKit 來做六類事情，分別是：
語音和視頻通話
發(fā)送消息
發(fā)送或接收付款
搜索照片
約車
管理健身
如果你的應(yīng)用恰好正在處理這些領(lǐng)域的問題的話，添加 Intents Extension 的支持會是很棒的選擇。它將提高用戶使用你的應(yīng)用的可能性，也能讓用戶在其他像是地圖這樣的系統(tǒng)級應(yīng)用中使用你的服務(wù)。
Siri和Maps通過Intents extension的擴(kuò)展方式和我們的應(yīng)用進(jìn)行交互，其中，類型為INExtension的對象扮演著Intents extension擴(kuò)展中直接協(xié)同Siri對象共同響應(yīng)用戶請求的關(guān)鍵角色。當(dāng)我們實(shí)現(xiàn)了Intents extension擴(kuò)展并產(chǎn)生了一個Siri請求事件時，一個典型的Intent事件的處理過程中總共有這三個步驟Resolve、Confirm和Handle：
Resolve階段。在Siri獲取到用戶的語音輸入之后，生成一個INIntent對象，將語音中的關(guān)鍵信息提取出來并且填充對應(yīng)的屬性。這個對象在稍后會傳遞給我們設(shè)置好的INExtension子類對象進(jìn)行處理，根據(jù)子類遵循的不同服務(wù)protocol來選擇不同的解決方案
Confirm階段。在上一個階段通過handler(for intent:)返回了處理intent的對象，此階段會依次調(diào)用confirm打頭的實(shí)例方法來判斷Siri填充的信息是否完成。匹配的判斷結(jié)果包括Exactly one match、Two or more matches以及No match三種情況。這個過程中可以讓Siri向用戶征求更具體的參數(shù)信息
在confirm方法執(zhí)行完成之后，Siri進(jìn)行最后的處理階段，生成答復(fù)對象，并且向此intent對象確認(rèn)處理結(jié)果然后執(zhí)顯示結(jié)果給用戶看
3、iMessage Apps
Message 應(yīng)用大概是 Apple 在宣傳 iOS 10 時著力最多的部分了。雖然新的貼紙包，自動轉(zhuǎn)換顏文字，發(fā)送全屏效果等功能都很酷炫，但是對于程序開發(fā)者來說，可能還是對 iMessage Apps 更感興趣。Xcode 8 中，Apple 在 iOS Application 模板中添加了一類新的項(xiàng)目類型，Messages Application。同時，模擬器甚至還開發(fā)了新的雙人對話模式，以供開發(fā)者調(diào)試這類 app。
雖然名義上是獨(dú)立 app，但實(shí)際上工作的依然是一個 extension。在該擴(kuò)展中，Messages.framework 將承擔(dān)與系統(tǒng)的 message 界面交互的主要職責(zé)。你通過提供一個自定義的 View Controller，來獲取用戶在使用你的 message app 時進(jìn)行對話的上下文，以及發(fā)送接收等操作，并做出合適的響應(yīng)。這個擴(kuò)展在用來進(jìn)行直接在 Message 應(yīng)用中一些自定義共享會很好玩。但是鑒于 Apple 暫時沒有打算將 Message.app 跨平臺的原因，可能也注定了這只會是一種補(bǔ)充，而無法成為主流。
4、User Notifications
通知中心向來是 iOS 上的兵家必爭之地。如何提供適時有效的通知，往往決定了用戶活躍和留存的可能性。在 iOS 10 上，Apple 對通知進(jìn)行了加強(qiáng)和革新。現(xiàn)在，為了更好地處理和管理通知，和本地及推送通知相關(guān)的 API 被封裝到了全新的框架 UserNotifications.framework 中。在 iOS 10 中，開發(fā)者的服務(wù)器有機(jī)會在本地或者遠(yuǎn)程通知發(fā)送給用戶之前再進(jìn)行修改。
另外，在之前加入了 notification action 以及 text input 的基礎(chǔ)上，iOS 10 又新增了為通知添加音頻，圖片，甚至視頻的功能。現(xiàn)在，你的通知不僅僅是提醒用戶回到應(yīng)用的入口，更成為了一個展示應(yīng)用內(nèi)容，向用戶傳遞多媒體信息的窗口。
之后會詳解。
IDE 和工具改進(jìn)
Xcode 8
在 app 簽名方面，Apple 終于意識到了他們在 Xcode 7 中所犯得錯誤。我想可能不止一個人被證書和描述文件出問題時的 "Fix Issue" 按鈕坑過。這個按鈕不僅不會修正問題，反而會直接注銷現(xiàn)有的開發(fā)者證書，然后“自作主張”地重新申請。大多數(shù)情況下，這讓事情變得更加糟糕。特別是對于新加入的開發(fā)者，他們并不理解 Apple 的證書系統(tǒng)，錯誤的操作和處置，往往讓開發(fā)環(huán)境變得不可挽回。Xcode 8 中，同一個開發(fā)者帳號現(xiàn)在允許多個開發(fā)證書，而完全重做的 app 簽名系統(tǒng)也足夠好用，并且避免了誤操作的可能性。在兼顧自動配置的基礎(chǔ)上，也為大型項(xiàng)目和復(fù)雜的 CI 環(huán)境提供了足夠靈活的配置空間，這絕對值得點(diǎn)贊。
另外 Xcode 終于提供了進(jìn)行代碼編輯器擴(kuò)展的能力。現(xiàn)在開發(fā)者可以創(chuàng)建 XCSourceEditorExtension 來對 Xcode 的功能進(jìn)行擴(kuò)展了，在沒有文檔幫助和官方支持的情況下摸索著為 Xcode 制作插件的歷史也即將結(jié)束。
另外開放了Runtime Issues的使用。在開發(fā)過程中，因?yàn)檎Z法或明顯的代碼錯誤(例如Retain Cycle)，編譯器可以發(fā)現(xiàn)并報黃色或紅色警告。但是一些因?yàn)榇a邏輯導(dǎo)致的錯誤，編譯器并沒有辦法找到。這時候可以通過Xcode8提供的Runtime Issues新特性，查找到運(yùn)行過程中出現(xiàn)的問題，并通過Graph的方式將問題可視化的展現(xiàn)給開發(fā)者。
Thread Sanitizer spots:新的線程污點(diǎn)清理器, 解決多線程情況下的資源競爭條件,數(shù)據(jù)的變化和其它相關(guān)線程的bug
View Debugger:使用更新的帶有更大的保真度和視覺精度檢查UI約束問題的視圖調(diào)試器
Memory Debugger:可以用新的內(nèi)存調(diào)試跟蹤器跟蹤發(fā)出的內(nèi)存泄漏警報。
Swift 3
Swift 開源已經(jīng)過去半年時間。在 Swift 2.2 中我們已經(jīng)看到了開源的社區(qū)力量對語言產(chǎn)生的深刻影響，而在 Swift 3 中這一影響的效果將更加明顯。
最大的變化在于 Foundation 框架的重新導(dǎo)入，可能過一段時間再回頭看的話，這將標(biāo)志著 Swift 與 Objective-C 徹底分家。Foundation 框架中的 API 現(xiàn)在以更符合 Swift 的方式被導(dǎo)入到語言中。大體來說，這些變化包括去除NS前綴，將絕大部分 class 轉(zhuǎn)換為 struct (雖然底層還是 copy-on-write 的引用實(shí)現(xiàn)，可以參看ReferenceConvertible協(xié)議的內(nèi)容)，去掉 API 中重復(fù)的語義等。如果在當(dāng)前你還能看出 Swift 和 Objective-C 在使用 Foundation 或者說開發(fā) app 時同根同源的話，Swift 3 正式發(fā)布后可能情況會大不相同。
由于引用類型向值類型的轉(zhuǎn)換，也將導(dǎo)致我們在使用 Swift 開發(fā)時的思考方式發(fā)生變化。以往的 Foundation 框架中類型的可變性是由不可變類型和它的可變類型版本 (比如NSData和NSMutableData) 來進(jìn)行區(qū)分的。而在 Swift 3 中，一般來說將只有作為結(jié)構(gòu)體的不可變類型 (比如Data)，對于這類結(jié)構(gòu)體的改變，將會是更安全的基于寫時復(fù)制的行為，而不再是原來可變對象那樣的危險的內(nèi)存操作。這在很多時候除了保證數(shù)據(jù)共享時的安全性以外，內(nèi)部的引用特性也保證了調(diào)用速度。實(shí)際上，因?yàn)闇p少了不必要的復(fù)制 (比如根據(jù)一個不可變對象創(chuàng)建相應(yīng)的可變對象)，實(shí)際上通過 Swift 3 的 API 使用 Foundation 的速度將比原來更快！
