開發者所需要知道的 iOS 11 SDK 新特性

作為 iOS 開發者,整理了一下在可能需要關注的地方。

新增框架

新加入 SDK 的大的框架有兩個,分別是負責簡化和集成機器學習的 Core ML 和用來創建增強現實 (AR) 應用的 ARKit。

Core ML

自從 AlphaGo 出現以來,深度學習毫無疑問成了行業熱點。而 Google 也在去年就轉變 Mobile-first 到 AI-first 的戰略??梢哉f一線的互聯網企業幾乎都在押寶 AI,目前看來機器學習,特別是深度學習是最有希望的一條道路。

如果你不是很熟悉機器學習的話,我想我可以在這里“僭越”地做一些簡介。你可以先把機器學習的模型看作一個黑盒函數,你給定一些輸入 (可能是一段文字,或者一張圖片),這個函數會給出特定的輸出 (比如這段文字中的人名地名,或者圖片中出現的商店名牌等)。一開始這個模型可能非常粗糙,完全不能給出正確的結果,但是你可以使用大量已有的數據和正確的結果,來對模型進行訓練,甚至改進。在所使用的模型足夠優化,以及訓練量足夠大的情況下,這個黑盒模型將不僅對訓練數據有較高的準確率,也往往能對未知的實際輸入給出正確的返回。這樣的模型就是一個訓練好的可以實際使用的模型。

對機器學習模型的訓練是一項很重的工作,Core ML所扮演的角色更多的是將已經訓練好的模型轉換為 iOS 可以理解的形式,并且將新的數據“喂給”模型,獲取輸出。抽象問題和創建模型雖然并不難,但是對模型的改進和訓練可以說是值得研究一輩子的事情,這篇文章的讀者可能也不太會對此感冒。好在 Apple 提供了一系列的工具用來將各類機器學習模型轉換為 Core ML 可以理解的形式。籍此,你就可以輕松地在你的 iOS app 里使用前人訓練出的模型。這在以前可能會需要你自己去尋找模型,然后寫一些 C++ 的代碼來跨平臺調用,而且難以利用 iOS 設備的 GPU 性能和 Metal (除非你自己寫一些 shader 來進行矩陣運算)。Core ML 將使用模型的門檻降低了很多。

Core ML 在背后驅動了 iOS 的視覺識別的Vision框架和 Foundation 中的語義分析相關 API。普通開發者可以從這些高層的 API 中直接獲益,比如人臉圖片或者文字識別等。這部分內容在以前版本的 SDK 中也存在,不過在 iOS 11 SDK 中它們被集中到了新的框架中,并將一些更具體和底層的控制開放出來。比如你可以使用 Vision 中的高層接口,但是同時指定底層所使用的模型。這給 iOS 的計算機視覺帶來了新的可能。

Google 或者 Samsung 在 Android AI 上的努力,大多是在自帶的應用中集成服務。相比起來,Apple 基于對自己生態和硬件的控制,將更多的選擇權交給了第三方開發者。

ARKit

Keynote 上的 AR 的演示可以說是唯一的亮點了。iOS SDK 11 中 Apple 給開發者,特別是 AR 相關的開發者帶來了一個很棒的禮物,那就是 ARKit。AR 可以說并非什么新技術,像是 Pokémon Go 這樣的游戲也驗證了 AR 在游戲上的潛力。不過除了 IP 和新鮮感之外,個人認為 Pokémon Go 并沒有資格代表 AR 技術的潛力?,F場的演示像我們展示了一種可能,粗略看來,ARKit 利用單鏡頭和陀螺儀,在對平面的識別和虛擬物體的穩定上做得相當出色。幾乎可以肯定,那么不做最早,只做最好的 Apple 似乎在這一刻回到了舞臺上

ARKit 極大降低了普通開發者玩 AR 的門檻,也是 Apple 現階段用來抗衡 VR 的選項。可以暢想一下更多類似 Pokémon Go 的 AR 游戲 (結合實境的虛擬寵物什么的大概是最容易想到的) 能在 ARKit 和 SceneKit 的幫助下面世,甚至在 iPad Pro 現有技能上做像是 AR 電影這樣能全方位展示的多媒體可能也不再是單純的夢想。

而與之相應的,是一套并不很復雜的 API。涉及的 View 幾乎是作為 SceneKit 的延伸,再加上在真實世界的定為也已經由系統幫助處理,開發者需要做的大抵就是將虛擬物體放在屏幕的合適位置,并讓物體之間互動。而利用 Core ML 來對相機內的實際物體進行識別和交互,可以說也讓各類特效的相機或者攝影 app 充滿了想像空間。

Xcode

編輯器和編譯器

速度就是生命,而開發者的生命都浪費在了等待編譯上。Swift 自問世以來就備受好評,但是緩慢的編譯速度,時有時無的語法提示,無法進行重構等工具鏈上的欠缺成為了最重要的黑點。Xcode 9 中編輯器進行了重寫,支持了對 Swift 代碼的重構 (雖然還很基礎),將 VCS 提到了更重要的位置,并添加了 GitHub 集成,可以進行同局域網的無線部署和調試。

新的編譯系統是使用 Swift 重寫的,在進行了一些對比以后,編譯速度確實有了不小的提升。雖然不知道是不是由于換成了 Swift 4,不過正在做的公司項目的總編譯時間從原來的三分半縮短到了兩分鐘半左右,可以說相當明顯了。

Xcode 9 中的索引系統也使用了新的引擎,據稱在大型項目中搜索最高可以達到 50 倍的速度。不過可能由于筆者所參加的項目不夠大,這一點體會不太明顯。項目里的 Swift 代碼依然面臨失色的情況。這可能是索引系統和編譯系統沒有能很好協同造成的,畢竟還是 beta 版本的軟件,也許應該多給 Xcode 團隊一些時間 (雖然可能到最后也就這樣了)。

由于 Swift 4 編譯器也提供了 Swift 3 的兼容 (在 Build Setting 中設置 Swift 版本即可),所以如果沒有什么意外的話,我可能會在之后的日常開發中使用 Xcode 9 beta,然后在打包和發布時再切回 Xcode 8 了。畢竟每次完整編譯節省一分半鐘的時間,還是一件很誘人的事情。

這次的 beta 版本質量出人意料地好,也許是因為這一兩年來都是小幅革新式的改良,讓 Apple 的軟件團隊有相對充足的時間進行開發的結果?總之,Xcode 9 beta 現在已經能很好地工作了。

Named Color

這是個人很喜歡的一個變化?,F在你可以在 xcassets 里添加顏色,然后在代碼或者 IB 中引用這個顏色了。大概是這樣的:

像是使用 IB 來構建 UI 的時候,一個很頭疼的事情就是設計師表示我們要不換個主題色。你很可能需要到處尋找這個顏色進行替換。但是現在你只需要在 xcassets 里改一下,就能反應到 IB 中的所有地方了。

其他值得注意的變更

剩下的都是些小變化了,簡單瀏覽了下,把我覺得值得一提的列舉出來,并附上參考的鏈接。

拖拽- 很標準的一套 iOS API,不出意外地,iOS 系統幫助我們處理了絕大部分工作,開發者幾乎只需要處理結果。UITextView 和 UITextField 原生支持拖拽,UICollectionView 和 UITableView 的拖拽有一系列專用的 delegate 來表明拖拽的發生和結束。而你也可以對任意 UIView 子類定義拖拽行為。和 mac 上的拖拽不同,iOS 的拖拽充分尊重了多點觸控的屏幕,所以可能你需要對一次多個的拖拽行為做些特別處理。

FileProvider 和 FileProviderUI- 提供一套類似 Files app 的界面,讓你可以獲取用戶設備上或者云端的文件。相信會成為以后文檔相關類 app 的標配。

不再支持 32 位 app - 雖然在 beta 1 中依然可以運行 32 位 app,但是 Apple 明確指出了將在后續的 iOS 11 beta 中取消支持。所以如果你想讓自己的程序運行在 iOS 11 的設備上,進行 64 位的重新編譯是必須步驟。

DeviceCheck- 每天要用廣告 ID 追蹤用戶的開發者現在有了更好地選擇 (當然前提是用來做正經事兒)。DeviceCheck 允許你通過你的服務器與 Apple 服務器通訊,并為單個設備設置兩個 bit 的數據。簡單說,你在設備上用 DeviceCheck API 生成一個 token,然后將這個 token 發給自己的服務器,再由自己的服務器與 Apple 的 API 進行通訊,來更新或者查詢該設備的值。這兩個 bit 的數據用來追蹤用戶比如是否已經領取獎勵這類信息。

PDFKit- 這是一個在 macOS 上已經長期存在的框架,但卻在 iOS 上姍姍來遲。你可以使用這個框架顯示和操作 pdf 文件。

IdentityLookup- 可以自己開發一個 app extension 來攔截系統 SMS 和 MMS 的信息。系統的信息 app 在接到未知的人的短信時,會詢問所有開啟的過濾擴展,如果擴展表示該消息應當被攔截,那么這則信息將不會傳遞給你。擴展有機會訪問到事先指定的 server 來進行判斷 (所以說你可以光明正大地獲取用戶短信內容了,不過當然考慮到隱私,這些訪問都是匿名加密的,Apple 也禁止這類擴展在 container 里進行寫入)。

Core NFC- 在 iPhone 7 和 iPhone 7 Plus 上提供基礎的近場通訊讀取功能??雌饋砗?promising,只要你有合適的 NFC 標簽,手機就可以進行讀取。但是考慮到無法后臺常駐,實用性就打了折扣。不過筆者不是很熟這塊,也許能有更合適的場景也未可知。

Auto Fill- 從 iCloud Keychain 中獲取密碼,然后自動填充的功能現在開放給第三方開發者了。UITextInputTraits 的 textContentType 中添加了 username 和 password,對適合的 text view 或者 text field 的 content type 進行配置,就可以在要求輸入用戶名密碼時獲取鍵盤上方的自動填充,幫助用戶快速登錄。


文章轉載于:http://www.cocoachina.com/ios/20170607/19457.html

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,698評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,202評論 3 426
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,742評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,580評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,297評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,688評論 1 327
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,693評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,875評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,438評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,183評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,384評論 1 372
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,931評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,612評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,022評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,297評論 1 292
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,093評論 3 397
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,330評論 2 377

推薦閱讀更多精彩內容