Swift 5 時代的機遇與挑戰到底在哪裏？

本文是知名 ios 開發者 NSHipster中文譯者-劉鎮夫（小魚），在雲棲大會上爲你們帶來的分享，本文主要介紹幾點，第1、Swift 5 表明什麼？第2、Swift 5 在社區中應用的狀況和咱們真實開發環境中是什麼樣的過程和現狀？第3、在實際開發中咱們應該怎樣面對 Swift 5 的決定性因素？第4、基於上面三個話題的討論結果來看在新時代下，有什麼新的路線和發展方向值得咱們去探索。

0一、Swift 5 帶來了什麼？

▐ 穩定的 ABI

Swift 5 帶來了什麼？最重要的一點是穩定的 ABI ，5.1 版本後，咱們能夠用不一樣Swift 支持的第三方框架，最終編譯成同一個 APP ，這是成熟語言的標誌，只有這樣才能讓不一樣的框架和代碼爲你所用，你們使用時也不會有那麼多的顧慮。

▐ 共享 Runtime 庫

除 ABI 外 Swift 5 也帶來了共享 Runtime 庫，上圖中 66.6MB 和 30.1 MB 都是之前的現狀，Swift 出來後再配合新的編譯工具，如今這些庫都可以共享，會顯著減小咱們的包體大小，由於共享的 Runtime 讓使用時間減小 5% 左右，用戶在下載和使用時，代碼構建量會減小 10% 左右，開啓「optimize for size」構建量會減小 15% ，這是你們採用三方 Swift 5 的一個關鍵性因素。

▐ Objective-C 混編調用效率更高

如今大部分都是自建的，當不在純 Swift 環境下開發時，這裏面寫出來的一些數據，是開發過程當中不可避免的一個問題， Swift 5 更新後，在第一程度調動方面有 1.6 倍的提升，在 NSString 方面有 15 倍的提升。

▐ Swift Package Manager

隨着 Swift 5 的發佈，咱們還能看見一些新工具產生，這在 IDE 和 Xcode 裏能夠直接看到，哪些地址有高依賴？引用了哪些庫？相對之前沒有官方的支持，好處很是明顯，之前使用時，第一次縮影下要下載大量的內容，這是很是痛苦的一點。Swift Package Manager 雖然沒有這樣的問題，但他的步驟也比較複雜，不是簡單一個包的名字安裝上去就能夠，蘋果新出的 Swift 5 manger 相對於官方的指導意見，同時支持後臺直接登陸一些帳號，包括企業本身的項目管理地址，這個至關於node 的環境，有 npm 的環境，是官方推薦的包管理工具，整個過程變的很是簡單，他是能夠和第三方工具並用的，切上來以後也不用擔憂沒有支持的問題。

▐ Swift UI

SwiftUI 你們應該比較瞭解，簡單來講就是用上圖只有五行左右的核心代碼去完成右側頁面的簡單操做過程，估計你們都已經玩過，下面也會展開講一下這個功能上能夠探索的一些新路線。

0二、Swift 在實際研發中的使用狀況

相對來講，如今國內實際研發中有真正用到 Swift 的同窗較少，可是 Swift 自己的發展已經沒有幾年前滯後的狀況，如今的發展是飛速的。

▐ Swift 發展進程

Swift 在 2010 年開始立項，第一個版本是 2014 年 9 月的 1.0 版本，2.0 版本在2015 年 4 月 ，這裏面變成了基本的調動速度，後面是每年發佈大的更新，全部基本的類型都是 Swift 本身不用調動的，如今是一個重要的時間點，能夠看到 Swift 的前景廣闊，不用再依賴別的語言實現，2019 年 6 月發佈的 Swift 5 ，讓他成爲現代化的成熟語言爲咱們所用。

▐ 社區表現對比

Swift Kanban，我收集的數據有 11159 個，有 6474 個標記已經被處理，剩下的不清楚對話是怎麼產生，經過這個數據能夠看到官方一直在很是努力的推動開發以及與開發者交流，能夠看到天天官方的狀況，大概 3 到 4 個小時就會有官方來回復開發者告訴你們最新的 bug 。

對比來講，一個開發的官方社區維護不太好的語言作不到這樣的響應速度，官方的態度是很是快速的修復這些問題，你們也不用擔憂在開發過程遇到什麼問題，上圖是我在網上收集到的一些數據，Y軸是 Pull Request 數量，藍色的線是 Objective-C ，橙色的線是 Swift 。

從 2016 年開始，Swift 的數據已經超過了 Y 軸，如今有一種取而代之的快速發展趨勢，這個說明社區中更多的開發者習慣把精力放在 Swift 上，而不是放在 Objective-C 上，這對你們的 APP 也是一個相關的提醒。若是你堅持只用 Objective-C ，那麼你可能會面臨一個風險——你所依賴的第三方開發庫已經不肯意去維護他們。

上圖是兩個在社區中最著名的第三方庫，一個是 AFN ，一個是 Swift 上作的，左邊是 Objective-C 上作的，這都是一個開發團隊同一套開發團隊庫，就目前情況來講，他們在 stars 上面的數量是差很少的，關注度和使用量也是差很少的狀況，可是 opening issues 上面的 afn 已經積累了 322 個未處理，ALAM 只有 32 個，這裏面有各類各樣的問題，官方無論 issues 的同時， Alamofire 只有 9 個沒有處理，而 AFN 有 83 個沒處理，最後一次 Swift 版本其實前一面就有新的確定的出現，而 Objective-C 要往前推 6 個月纔有一個 commit ，最後一個版本須要往前推一年半才能夠找到。

舉個實際的例子，好比你們都是作 HTTP 請求的，3.0 協議已經發出，若是將來的開發者更願意把精力放在 Swift 上面，如今 SSL Certificate Verify 的驗證，是能夠把證書鏈從上至下所有驗證一遍，這在 Alamofire 裏已經支持的很是好，你們在此領域目前是缺失的，因此目前而言的現狀是有一些不能帶來了，這是老框架不能作到的，我的建議，若是你們想轉到 Swift ，能夠儘快實行，以免在將來時間點，你所依賴的第三方很是重要的開發框架有嚴重問題時，可能會跟不上進度。

▐ Objective-C 的發展史

爲了打消你們對 Swift 應用前景的疑慮，Objective-C 1981 年開始建立，至今已有 20、30 年的時間，1988 年喬布斯建立了 iOS 並買下受權，這個語言用了 20 多年的時間才成爲蘋果平臺的一個專屬主流的語言，Swift 只用了 5 年的時間就達到如今的結果。2007 年 Objective-C 2.0 操做的版本，也就是如今手動管理內存的版本 2007 年發佈，如今你們都在使用這個版本，至今至關於過了30 多年的時間，才處理了他在系統上的地位。

Objective-C 的發展歷史也不是沒有問題，他出來時比 Swift 的問題更多，在 2005 年纔有垃圾回收機制，而且是沒有命名空間的，你們都知道系統的數據是 NS 開頭，若是寫一個很大的數據就沒有辦法編譯了，沒有運算副重在，他出來時做爲 C 語言的擴展機制，因此剛出來時面臨的問題要比 Swift 如今面臨的問題要多的多，但蘋果仍是吸取了他做爲主流的開發語言，這裏面不但有技術性的一些挑戰和考量，也有在整個生態中開發環境的開發者對於語言喜愛的一個考量。當時有五大平臺，Java 在蘋果生態裏能夠繼續開發，可是最後蘋果仍是選擇了 Objective-C ，一個重要的緣由是，在蘋果生態內部通過 20 多年的內部工程師的使用，更喜歡這個語言所帶來的感受，並非 Java 很差纔沒有選擇，而是社區的人的喜愛，你們在選擇的時候，要考慮一下團隊的狀況，和你們對新語言的興趣和努力方向在哪裏，而不是要不要接受新的語言使用新的框架，以肯定在將來的狀況下不會做出錯誤的決定。

0三、項目引入 Swift 的考量因素

迴歸到實際問題，項目開發中到底要不要引入 Swift 的考量因素？我主要將其分爲五大模塊，目標、成本、過程、結果和反饋。

首先看目標是什麼？爲何要考慮在項目中是否引入 Swift 的新語言？但願你們不是單純爲了使用新語言而用，是要節省開發效率、仍是提高運行效率、或者是要減小包的大小，仍是讓整個團隊的技術跟上新的潮流去作一個提高？都是有一個目標，這也也會產生一個成本，這裏面的考量是爲了達成新的目標，這個成本是否值得付出？以及是否會形成一些 APP 不穩定的狀況，這裏會有一些負面的影響，而你可否在實際開發和實際交付的過程去承擔？

如何把新的語言、新的框架應用到業務的 APP 裏面去？分模塊開發仍是分頁面開發？都是要考慮的過程，這對於APP開發的風險仍是比較大的，業界也有一些比較失敗的案例，他們在使用 Swift 後又所有換回來了，這都是你們不想看到的，好比在引入 Swift 做爲其中幾個模塊的開發，是否真正產生了你想要的結果？是否是真的節省時間了？

若是你的 APP 過於複雜，裏面有互相嵌套的地方，那可能不太適合大家團隊的現狀，因此不要以爲引入以後，在交付上面就是適合的，反饋過程也很重要，由於 APP 開發是持續的過程，不是交付這一版就結束了，仍然要考慮下一個迭代中是否要用新語言作開發，或已經開發的模塊適不適用新語言去作擴展。

舉個例子，我實際參與的項目第一是某區塊鏈客戶端，在密碼選用時選了 Swift 作實踐，其餘的基礎層面用了 Objective-C，緣由很是簡單這兩部分在應用中隔離的比較好，和諧的比較開，互相沒有太多攙雜在一塊兒的地方，而且有一個好處：Swift 編譯出來的包在逆向工廠和反編譯中目前是屬於比較困難的狀態，因此他很是適合密碼和區塊鏈頂層的應用，可以保證 APP 安全的運行在客戶的手機上。

日程管理類的 APP ，須要記錄你要作的事，所涉及到的文本類會較多，爲了不 Swift 處理方面出現問題，因此保留了 Objective-C 的實踐，各類細碎的頁面較多，團隊內部有人想要嘗試新語言時，會建議他在新的頁面上嘗試這個語言，核心部分依舊保留 Objective-C，而且在對應的 ReactiveCocoa 上用 Swift 對應的 2.0 版本。

總的來講若是企業有新的項目區，建議用新的語言，在新項目上有技術的實踐，在新項目中把功能訓練的比較完善，去解決一些問題，我的項目仍是徹底使用 Swift 去開發，這樣會提升我的能力，當你真正去大項目中部署這個問題時，在大部分問題已經預見事後，不至於一籌莫展。

0四、新的機遇與挑戰

隨着 Swift 5 語言慢慢發生，咱們能夠看到一些新的變化，第一是 Project Catalyst 一鍵生成酷炫的功能，第二是 SwiftUI，第三是 Combine ，這是蘋果官方發出的消息隊列機制，第四隨着 Swift 4.0 版本發出的 Swift for Tensorflow ，在 AI 方面都搞一些涉獵，這是社區對這個方面的側重，目的是用這些新的功能去吸引最頂尖的開發者去加入。

Dropbox結合 Swift ，是作文件同步的，他不像 Telegram 在重寫 Swift 的客戶端時所說的緣由那麼簡單，所謂都重寫，緣由很簡單，重寫後用電量明顯減小，之前一些隱藏的 bug 解決以後，都不見了，徹底沒有考慮性能，他有一個 C++ 的代碼，在各類平臺均可以用同一套客戶端去作這件事，如今放棄了 C++ 去作原商代碼的開發，目的很簡單，不少移動工程師對學習 C++ 毫無興趣，以及他們在移動端互相配合的過程當中產生了極大的問題，這樣就致使了優秀的開發者想用 Swift 開發時已經沒有太多的用武之地，由於核心功能都不是這個語言寫的，最後致使不少優秀的工程離開了這個團隊。

擁抱新技術也是挑戰，在應用 Swift 的開發以後必定會遇到一些原來沒有的問題，高效率的問題可能也會遇到，我以爲優秀的開發者就是這樣，當你擁抱新技術的時候、新的挑戰所帶來的問題你也可以承擔，也可以把他解決，這纔是正確的態度。

有的同窗可能說 Objective-C 並非阻止咱們使用 Swift 的最重要的緣由，咱們的應用全是動態內容分發，或者一些常見的框架，即便 Swift 再好可能也沒辦法去處理那些動態頁面的交付，這個問題不在於 JavaScript 和 Swift ，他們的執行效率沒有原生的那麼快，好處是這些動態內容的交付有了一個可交付的結果，若是你的 APP 裏要求動態內容、動態頁面、動態佈局，實際上是很難實現這麼高的切合度的。

基於 Swift 目前的發展示狀，Swift UI 之因此可以這麼簡潔、高效的開發，是基於 Function Builde 的開發，如今看到的 Swift 實際上是能夠作簡化的，包括一些名字都是能夠簡化掉的，一些單行的 return 均可以不用寫了，我以爲將來有一個方向就是你能夠把 Swift UI 寫成右面那種形式，咱們能夠和 Function Builder 作對比，包括他的邏輯可讓你去作一些相關的 DSL 的書寫。

左邊的 DSL 能夠經過社區目前正在研發的 Builder ，他的語法和表現形式變的更加簡潔和方便，若是全部的 UI 層面和邏輯層面的代碼都可以寫的像左邊這樣的話，差別就不是特別大，在全部平臺動態裏內容分發也不會有太大的問題，上圖是我在開源社區翻的到的一個可能的實踐，這我的基於 Function Builder 作了 HTML ，由左邊這種形式直接轉化成頁面，當你收到服務器語言時，直接將其繪製出來附着上去，對咱們來講仍是有進一步的研發和衆多可能性，對比目前這些動態環境來講，動態內容形成的環境，像左邊幾個大多數是用 JS 作基礎語言去作編寫的，運行時依賴 JS 的用戶，用這個框架去作一次解釋和翻譯才能完成最後的結果。

▐ 跨平臺解決方案

有人說咱們的這個是跨平臺的，若是你們仔細觀察右面的形式，會發現他很是像 Swift 5 的 DSL，因此安裝新的開發框架有 Jetpack Compose 的一個東西，像 Swift UI DSL 同樣，能夠完成一樣語法的簡便形式，這樣你們要達成統一時，在雙平臺均可以用原生語言去實現，而再也不依賴 DSL 的翻譯，整個研發和運行效率都會大大的提高。

將來新的挑戰和機遇是咱們都用本身平臺的語言，不依賴 JS 去解析，很是建議 DSL ，動態內容由服務端分發，十分簡潔。APP 前端的一些界面在使用 Swift ，生成前的 Swift 前端最方便的方式是什麼？就是後端也是用Swift 寫的。Swift 用 Swift ServerSide 生成的前端也是 Swift 這個語言生成的 DSL 能夠給移動開發者用，也能夠給安卓開發者用，做爲一個很是酷的 APP，例如換臉，可能會依賴 tensorflow，AI相關的部分也是用 Swift 5 寫的，因此我以爲前景是你們只會去學Swift 的語言，把這種語言用好大家就能夠成爲前平臺的開發者上市。

0五、總結

穩定的 ABI ，是咱們最基本的運營，保護運行狀態相對穩定、成熟，對咱們來講很是重要，接下來是 Runtime ，和 Objective-C 混編調用效率更高，能夠保證你們在使用的時候不會遇到太多的問題，後面是社區的支持和開發者對 Swift 的喜好，還有以 DSL 爲基礎的動態方向上的預想，這件事情在官方社區裏已經提到最高日程，你們能夠去社區關注一下，剛纔的設想圖也並非徹底幻想出來的，而是會在短期內得以實現。

One More Thing

淘系技術部依託淘系豐富的業務形態和海量的用戶數據，咱們持續以技術驅動產品和商業創新，不斷探索和衍生顛覆型互聯網新技術，以更加智能、友好、普惠的科技深度重塑產業和用戶體驗，打造新商業。咱們不斷吸引用戶增加、機器學習、視覺算法、音視頻通訊、數字媒體、移動技術、端側智能等領域全球頂尖專業人才加入，讓科技引領面向將來的商業創新和進步。

請投遞簡歷至郵箱：ruoqi.zlj@taobao.com

---

本文做者：劉鎮夫（小魚）

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。