Swift 5.3的進化:語法、標準庫、調試能力大幅提高

歸納

Swift 從 5.0 的 ABI 穩定到5.1 的模塊穩定,Swift 終於不是《Swift 入門到重學》了。本次 WWDC2020,Swift 5.3 正式發佈,Swift 依舊朝着安全、高效、易讀的方向持續發力,不斷的在改進語法,加強代碼的表達能力和易用性。由於 Swift 的模塊穩定,SPM 如今也支持了二進制模塊的分發,逐漸完善的社區生態也在不斷拓寬 Swift 能夠涉足的領域,而不只僅是在 Apple 平臺之上。git

下圖展現了 WWDC2020 中 Swift 相關內容的腦圖,但願能夠幫助你們快速瞭解。github

image.png

( WWDC 2020精彩內容思否專欄:https://segmentfault.com/blog...  編程

本篇內容來自於阿里巴巴淘系技術部,無線開發工程師星志。
更多精彩內容可關注【淘系技術】公衆號。)swift

語言環境的完善和拓展

一門完善編程語言有三個最基本的要素:語法、標準庫、調試能力。語法設計決定了語言的編程範式;標準庫決定了語言的基本能力;調試能力決定了開發者的體驗和語言的穩定性。

蘋果在 Swift 的迭代過程當中不斷的強化這幾點,咱們能夠來看看 Swift 又獲得了哪些提高。segmentfault

語法特性

Swift 的語法設計核心仍是 OOP,可是這不妨礙 Swift 的語法在支持 POP 和函數式編程甚至 DSL 獲得的強化。Swift 也由於 SDL 特性的加入,開始逐漸的適應聲明式編程的方向發展,好比後文提到的 @main 等等。安全

Multiple trailing closure

image.png

這個改進解決了當函數最後幾個參數爲閉包的狀況下,致使的括號嵌套的問題,API 更加簡潔也更加具備表達性。SwiftUI 利用這個語言特性,也變得更加簡潔易懂。ruby

KeyPath as Function

image

如今 KeyPath 能夠當作函數來使用了。這個語法糖解決的問題當咱們使用相似 map 同樣的函數時,只須要取出對應數據模型中的某一個屬性,爲此咱們不得不寫相似 map { $0.property } 的代碼,有了這個語法糖,事情就能夠簡化成了 map(\.property)閉包

Type-based program entry point (@main)

引入了新的修飾符 @main,能夠標記在帶有 public static func main() 函數實現的全部類型,不管 main 函數時從拓展來得仍是繼承來的。添加這個特性的意義在與維持聲明式的語義,將聲明式語義進行到底。YES!app


Increase availability of implicit self in closures

之前咱們寫逃逸閉包時若是捕獲了 self,咱們須要在跟 self 有關的地方寫上 self. 以警示咱們注意循環引用。編程語言

image.png

若是在閉包的捕獲列表中顯示聲明捕獲 self,在閉包中對 self 相關的訪問能夠省略。若是是在不可變的函數中訪問,self 能夠直接省略(爲了 SwiftUI)。

image.png

其實這一點改進有用可是覆蓋面並非很廣,由於在實際的應用中,咱們都是儘可能先弱引用 self 後再強引用 self,來保證 self 的可訪問性。在以下場景就得不到此項優化:

image

Multi-pattern catch clauses

這種寫法能夠自動實現錯誤匹配,進入到對應的錯誤處理中,而不須要使用 switch,加強語言的可讀性。

image.png

Enum enhancements

自動符合 Comparable

編譯器如今能夠自動爲你生成 Comparable 的相關方法,實現 Enum 的比較。

image.png

Enum case 能夠用來適配 protocol

這個特性看引用場景須要吧,官方給了一個比較好的例子。具體相關內容能夠參考 SE-0280。

image.png

DSL 新增對 switch 的支持

如今能夠在 SwiftUI 等 Swift DSL 中使用 switch-case 來進行模式匹配,以前只有對 if-else 的支持。某種程度上也是爲 SwiftUI 而生的能力。

image.png

標準庫

其實這裏說標準庫是廣義的標準庫,其中包括了開發者隨語言分發的標準庫,如標準 I/O 庫等,運行時環境,編譯環境,一方庫等等。蘋果今年在這部分下足了功夫,由於標準庫、各類各樣的一方三方庫纔是展示一門語言能力的地方,不然再好的語法也不會有人用,語言終究仍是工具,能解決問題纔是關鍵。

Swift 5.3 在代碼尺寸和運行時都有不小的提高。Swift Package Manager(SPM)增長對二進制和資源的支持,深度集成 Xcode,親兒子的優點逐漸顯示了出來。Swift 原本設計的初衷原本就是一門 General Purpose 的語言,今年蘋果正式宣佈 Swift 支持了 Apple platform,Ubuntu/CentOS/Amazon Linux,不久的未來也會支持 Windows,正式成爲一門優秀的跨平臺語言。

標準庫更新

  • Float16 的支持,具備更好的運算性能
  • Apple Archive 一種功能相似 zip 的壓縮文件,蘋果就是用這種格式來更新系統
  • Swift System 對操做系統基礎 API 的包裝,讓 API 更健壯易用
  • OSLog 推薦使用的 logging system

從這些更新能夠看出,蘋果對 Swift 的底層操做很是關心,Swift System 的出現讓使用 Swift 底層開發者脫離 OS C API 的折磨,得到更一致更健壯的代碼體驗。

新的一方庫

Code Size and Runtime

在使用 UIKit 的狀況下,Swift 4.1 時生成的二進制代碼已經從 OC 的兩倍還多,可是在 Swift 5.3 中,這個差距已經縮小到小於 1.5 倍了。也就是說以前大量使用 Swift app 會自動獲得二進制大小的優化,而對於擔心 Swift 會形成包大小問題的 App,如今已經不算是很大的問題了。由於只須要付出能夠接受的代價,就能得到 Swift 帶來的安全性能和開發體驗。

image.png

若是 App 使用了純 SwiftUI,二進制代碼甚至能夠縮小 43% 之多。可見蘋果優化 Swift 的功底之深,並且這些優化,只須要重新編譯一次便可享受,何樂而不爲。

image.png

由於 Swift 更緊湊的值類型,運行時的內存,分配相同的對象所需的空間天然比 OC 更小。Swift 5.3 相較 5.1,運行時的必要額外信息存儲要少很是多,甚至作到了比 OC 還要少,大大減少了 Swift 的運行時內存。這對低內存的設備是很是有幫助的,同時,更少的系統內存意味着更多的用戶內存。而這一切,只須要從新編譯便可。

image.png

Swift 底層的不斷優化也讓其成爲一門高效的語言,下降運行時的要求,就能夠提高其應用的場景。

Swift Package Manager

SPM 做爲 Swift 生態很是重要的一環,也迎來了更新。

  • SPM 支持二進制包分發
  • SPM 支持了資源的打包

這兩點更新已經代表了 SPM 的能力已經足夠完善了。目前具備必定規模 App 的內部模塊都開始使用 Cocoapods 作二進制組件化的集成,這樣能夠明確對代碼解耦,提升打包的效率。在這樣的背景之下,SPM 對這兩點關鍵特性的支持已經能夠覆蓋住大型 App 需求了,並且 SPM 不僅僅只跟 Swift 玩,C Family 它均可以支持。

在 SPM 與 Cocoapods 的對比中,親兒子 SPM 跟 Xcode 深刻整合,Xcode 能夠直接打開編輯 swift package,Xcode 由於 SPM 設計了對應的操做界面,下降了開發和使用的門檻。成熟的工具鏈也讓聯調 Swift Package 垂手可得。而 Cocoapods 由社區維護,每一次 Xcode 更新其響應也不算很及時,在針對大型 App 時由於 Podfile 與 podspec 的分離致使了許多不一致,使用 ruby 還有必定的門檻。

如今也許是擁抱 SPM 的好時機。

跨平臺

如今官方支持的操做系統列表以下:

  • Apple platform
  • Ubuntu 16.04, 18.04, 20.04
  • CentOS 8
  • Amazon Linux 2
  • Windows (coming soon)

真正作到的跨平臺,而且 Swift 官方支持 AWS Lambda。AWS Lambda Runtime 已經開源,支持了 AWS 的 FaaS 編程,進一步的拓寬了 Swift 涉足的領域。

調試能力(開發者體驗)

調試和開發者體驗也是一門語言很是重要的一環,由於沒有人會寫出沒有錯誤的代碼,檢查錯誤的能力和工具對一門語言來講十分重要。蘋果也十分注重這一方面,在開發者體驗上下足了功夫。

更加智能的診斷信息

剛開始使用 Swift 的開發者可能常常會對 Xcode 的報錯信息不知所云,在引入 SwiftUI 後,這個問題尤其明顯。筆者第一次編寫 SwiftUI 時,只要 body 中某個地方出錯,報出來的錯誤都是不正確的,只能經過肉眼檢查和推斷才能明白本身的錯誤,十分痛苦。

如今蘋果重製了診斷能力,如今 Swift 的錯誤診斷比以前準確了許多,錯誤沒有亂報而且錯誤提示也變得很好理解,特別是 SwiftUI,很容易知道錯在哪了。在 Swift 中,編譯經過就是對正確性的一個很好的證實,除非你用不安全的方式讓編譯器閉嘴。

自動補全

通過強化的類型推斷系統,也加強了 Swift 的代碼補全能力。這個估計升級到 Xcode 12 就能夠順利體驗了。同時代碼縮進能力也獲得了增強。

LLDB

image.png

積極擁抱 Swift

看了這麼多年 WWDC,每次看時你們應該都有一種心態

只支持最新版本,咱們才支持 iOS X (低版本),這些東西跟我不要緊

感受 Swift 真香,可是現實只讓我使用 OC(嘆口氣)

什麼語言不是用,OC 這麼多年確定夠用了

危機

然而若是不及時作出改變,保持能用就行,在前進的路上,背上的擔子就會愈來愈重。當發現快走不動時,又回過頭來看 WWDC,就會發現,原來解決方案好久之前就已經給出來了,只是當時不以爲是個問題,這不支持那不合適,可是如今想拿出來使用的時候,面對背上那一團團的亂碼,卻又一籌莫展。

作出改變是痛苦的,可是當之前以爲癢就撓撓就解決了的事情,逐漸變成如今的痛點時,要作出改變也許會更痛苦。

Swift 的出現就是爲了替代而且超越 Objective-C 的語言,雖說蘋果由於歷史緣由還在使用 OC,可是種種跡象代表,蘋果正在作積極的工做,逐漸經過 Swift 下降 OC 在整個系統的比重。

社區也在積極的轉變,許多著名的第三方庫都已經遷移至 Swift,OC 版本已經再也不維護,例如 Lottie 已經在 Swift 版本上出現了 OC 版本不存在的特性,而且 OC 版本再也不維護。這種現象慢慢會愈來愈多。

改變

咱們也在積極探索 Swift 在手淘的落地,取得了 Swift 5.1 能模塊在手淘中正確運行起來的階段性成就。

如今時機已經成熟,語言特性,SPM,工具鏈,標準庫都已經足夠強大,是時候作出改變了。

Swift 雖然看起來很簡單,但其實它是一種下限低,上限高的語言,集團內部的 Swift 環境,須要你們來一塊兒維護。咱們將來也要增強 Swift 語言相關的培訓,讓開發者真正理解 Swift,上手 Swift,成爲一名 Swifter 而不是 OSwifter。

手淘客戶端團隊正在進行社招招聘,崗位有iOS Android客戶端開發工程師等,歡迎推薦。

簡歷投遞:junzhan.yzw@taobao.com

參考

  1. SwiftUI 背後那些事兒
  2. WWDC20 What's new in Swift
  3. WWDC19 What's new in Swift
  4. WWDC18 What's new in Swift
  5. WWDC17 What's new in Swift
  6. WWDC16 What's new in Swift)
  7. WWDC20 Swift packages: Resources and localization
  8. WWDC20 What's new in SwiftUI
  9. Swift 5 時代的機遇與挑戰到底在哪裏?
  10. Swift Evolution

( WWDC 2020精彩內容思否專欄:https://segmentfault.com/blog...  

本篇內容來自於阿里巴巴淘系技術部,無線開發工程師星志。 更多精彩內容可關注【淘系技術】公衆號。)

相關文章
相關標籤/搜索