手淘 App 如何落地 Swift ？一邊探索實踐，一邊「打怪升級」

嘉賓|姜沂（傾寒）

出品|阿里巴巴新零售淘系技術部

做者簡介：姜沂（花名：傾寒），阿里巴巴淘系技術部 iOS 端架構高級無線開發工程師，曾在鏈家網、美團點評從事 iOS 相關開發，目前就任於淘寶-淘系技術部。在鏈家網架構組主要工做有：組件化工程、構建合理開發鏈路、基礎庫開發和客戶端穩定性相關工做。在美團點評架構組所作工做主要有響應式架構設計落地、性能優化和基礎庫開發。目前在淘寶客戶端架構組，具體負責的工做有基礎庫開發、性能優化、淘寶灰度能力、開發工具升級，以及 Swift 語言落地。

前言

自從 2014 年蘋果發佈 Swift 至今，歷經屢次迭代，Swift 終於迎來了 ABI 穩定，SwiftUI 的發佈也引發無數 Apple 平臺開發者的歡呼。

多年來廣受關注而又備受爭議的 Swift，終於開始被不少大型 App 堅決地採用。

在這其中，淘寶 App 就是一個典型：從 Swift 2.0 時代的淺嘗輒止，到去年 3 月 ABI 穩定後充分調研並正式採用，這其間經歷了什麼樣的考量過程？淘寶 App 落地 Swift 的最關鍵環節有哪些？如何解決落地 Swift 過程當中的挑戰？

爲什麼要堅決地走 Swift 之路？

對於淘寶 App 來講，對 Swift 一點都不陌生。姜沂介紹：淘寶 App 早在 Swift 2.0 時代就曾經引入過 Swift，但受限於 Swift 2.0 時代語法的不穩定，以及較大的包大小壓力，彼時引入 Swift 實際上是一種負擔。

直到 2018 年末也就是 Swift 4.x 時代，蘋果宣佈 Swift 5.0 ABI 會穩定，這時候 Swift 的優勢才能被髮揮出來，而不足則會逐步減弱。

「咱們在 2019 年 6 月蘋果 WWDC 發佈 SwiftUI、Combine 等對於 Apple 平臺顛覆式的產品後，纔對 Swift 又燃起了信心，正式着手採用 Swift。」

不過據瞭解，那時候的淘寶所有是 Objective-C 代碼和一些跨平臺框架如 Weex ，其實沒有任何的 Swift 環境經驗，甚至有一些工程問題致使 Swift 代碼沒法直接引入淘寶工程。

對於採用 Swift 可能會遇到的困難，姜沂他們是有所準備的，畢竟在去年 3 月 ABI 穩定後，團隊成員分工對 Swift 進行了一次充分的調研：Swift 性能與開發效率、Swift 流行度、工程改造，方方面面都考慮到了。

「一開始咱們主要經歷了比較久的預研階段，在 2018 年 Swift 宣佈將要 ABI 穩定的時候，咱們就在持續關注 Swift 的進展，在此期間集團內部已經有零星 App 在使用 Swift。」

到了後來的充分調研階段，Swift 在性能與開發效率上的調研結果其實已經不言而喻，這也是業界達成的共識：一個熟悉 Swift 和 Objective-C 的工程師，開發效率主觀評價至少有 30% 以上的提高。

在比較重要的 Swift 流行度分析中，經淘寶 App 團隊的調研：國際區採用 Swift 的 App 佔據 80% 份額，而中國區只有 20%。另外有一個現象值得關注：GitHub 和一些開發者社區對於 Objective-C 的關注度劇烈降低：

一、知名 Objective-C 開源庫如 AFNetworking 已經將近 2 年沒有重大更新，距離最後一次 Bug Fix 也已經有 1 年時間，對比之下 Swift 社區則很活躍；

二、StackOverFlow 等社區對 Objective-C 的提問已經近乎停滯，淘寶 App 團隊成員近兩年找尋疑難問題的解答幾乎沒人關注；

三、WWCC17 後，蘋果全部 Sample Code 皆用 Swift 展現。

姜沂告訴記者：「咱們的初步結論就是：按照蘋果從來的強硬態度，若是咱們仍是堅守 Objective-C 陣營，若是將來蘋果強制推動 Swift，或者只更新 Pure Swift Framework，或者社區出現大技術更新、好比 HTTP3 網絡庫，會對咱們目前的社區研發環境形成比較大的衝擊。咱們極可能被動的付出較大成原本適應變化，好比須要本身造 Objective-C HTTP3 的網絡庫輪子。」

「簡單來講就是：咱們可能在將來一兩年內由於 Objective-C 而形成技術踏空，這一後果會對咱們的人員招聘、技術前瞻性、研發成本都會帶來較大風險與負擔。」

調研結果加之 Swift 隨後的進展，更讓淘寶 App 堅決了走 Swift 之路的決心： 在調研一個月後 WWDC19 更新了 SwiftUI、Combine 等 Pure Swift 框架，初步的驗證了以前的結論； 蘋果放開了 200M 蜂窩網絡下 IPA 包大小的限制， 同時 iOS12.2 如下系統須要內置包大小的設備佔比已經不足 10% 且會隨着時間的推移，存量愈來愈少； SwiftUI 的出現對 Native 研發生產力的指數級提高。

落地 Swift 過程當中要如何持續「打怪升級」？

淘寶 App 落地 Swift 分爲了 5 個階段，分別是技術調研、基礎設施建設、工具鏈升級、里程碑業務上線和社區培訓。

姜沂介紹：其中最大的挑戰應該是在基礎建設階段。「這一階段主要工做是重寫一個小模塊，用於發現工程中的歷史問題。其中咱們發現的一個比較大的問題是，因爲淘寶是一個迭代了將近 10 年的工程，蘋果在管理二進制庫的時候也經歷了 .a +.h 結構和 Framework 結構的調整，在逐步的迭代過程當中，大量的頭文件管理不太規範，致使 Swift 代碼沒法在項目中使用已有的 SDK，這部分理論上簡單，可是工做量巨大。」

在姜沂看來，此時公司對 Swift 的投入仍處於一個較初期階段，並不適合投入大量人力，由於 ROI 上並不划算。因此他們的解決辦法是：創建 Swift 愛好者社區，彙集幾十名愛好者，梳理技術文檔、方案思路、自動化腳本等，逐步去掉這些歷史包袱。

「此時 Swift 5.1 仍舊是 Beta 階段，這給了咱們充分的時間去作適配。最終用了三個月，幾十名愛好者每人只花費極少的時間就將這些歷史包袱解決掉了，這裏也要感謝下來自阿里巴巴集團的各位 Swift 愛好者的努力。」

在落地 Swift 過程當中，淘寶 App 嘗試實現了一套 Swift 版本 FaaS 的 Serverless 容器，給如今的迭代工做方式創造一些可能性。不過據姜沂介紹，目前只是用在了一些內部軟件中，還在積極探索階段。另外對於 SwiftUI ，淘寶 App 也 落地在了內部的 App 中，總結 SwiftUI 的優缺點，以及將來落地的可能性。

對於淘寶落地 Swift，姜沂稱之爲「巨型項目」，Swift 的落地也讓姜沂他們梳理出了一個巨型項目的流程方法論。據他介紹，實際上阿里集團內部也已經有多個 App 參考淘寶 App 的落地路線在落地本身的 Swift 模塊。這個過程真的須要一路持續「打怪升級」。

一兩年內中國 Swift 生態是否會有大改善？

在落地 Swift 的幾個月內，姜沂深入感覺到從不停地被各類同事諮詢敢不敢用 Swift，到他們本身主動要寫 Swift 代碼的一個轉變。「淘寶擁有近十年的迭代歷史，以及近千的 SDK 和數百不一樣 BU 的開發者，對於 Swift 初期探索性落地來講，模塊選型是一個難題，建議你們最好選擇一個能充分說明 Swift 可用性（大流量）的業務，而且這個業務還不能被外部過於依賴。緣由是底層的 SDK 過於複雜、對外部有不少依賴的話，推動風險和上線風險都會比較大。大流量的表明性業務能讓觀望的開發者提高信心，可是要作好充分的降級能力，不能損傷到業務。」

在落地 Swift 的過程當中，其實還有一個挑戰，就是國內 Swift 應用不普及帶給使用者的觀望情緒。對於這個問題，姜沂認爲要從兩個方面來看。

首先是業務視角：

一、在業務須要快速迭代的時候，現有的 iOS 工程師主要以 Objective-C 爲主，轉戰 Swift 須要必定的學習曲線，並且採用 Swift 效率是否必定有提升也有待考證；

二、Swift 只能解決 iOS 側 Native 研發問題，對於高迭代效率的跨平臺技術，收益不足。

其次是技術視角：

一、Swift 早期因爲 ABI 不穩定，只能將 Runtime 內置在 IPA 包裏面，佔用約 3M 的下載空間，蘋果還有 150 M 的蜂窩網絡下載大小的限制，且對啓動性能有 150ms 的影響，在各家公司拼體驗的時代，這些都會對公司的業務形成負擔和損耗；

二、因爲語法不固定，每次升級都會形成源碼級別的 Break Change，對開發者也會形成負擔。淘寶、美團等巨型 App 都採用了二進制組建化研發模塊，Swift 只能固定開發工具版本，對大型團隊是一種負擔和制約，反而極大的下降了研發效率。

不過姜沂認爲將來一兩年內國內 Swift 生態仍是會有巨大改善的，主要有如下幾個方面：

一、iOS 12.2 以上內置 Swift Runtime， 包大小隨着存量舊版本操做系統升級後獲得緩解；

二、iOS 12.2 以上也沒有啓動性能的影響；

三、Swift 語法再也不大變，不會對開發者形成負擔；

四、蘋果繼續強勢推動，Swift 社區熱度持續提高。

對此他舉了一個很生動的例子：相信生產力大幅提升後，沒有人會聽任好用的工具不用而去用一把快要鏽掉的錘子（Objective-C ）。

咱們選擇的技術最終要爲業務和商業服務

最後，姜沂介紹了他近期比較關注的大前端領域技術——SwiftUI 和 Flutter 。

對於 Flutter，在姜沂看來：在近年來的移動開發領域，開發者和業務訴求一直在研發成本、靈活性、性能體驗間來回偏移，本質上是由於不一樣業務在不一樣階段有不一樣的訴求，有時候須要較快速的試錯能力和研發效率，有時候又須要較高的性能。隨着 Hybrid RN/Weex 的出現，你們基本上有一種固化的判斷：若是我要動態性和靈活性的話，我選擇 RN/Weex；若是我要體驗的話，我選擇 Native。

但這並非說 Native 開發者就不想擁有高動態性，也不是說他們就沒有跨平臺減小研發成本的訴求，因此 Flutter 的出現讓你們有了一種嶄新的思路：原來 Native 也能夠作到跨端的同時有很是高的性能。

對於 Swift，姜沂着重說起了 SwiftUI。「iOS 開發多年來在佈局技術上一直遠遠落後於前端和安卓，可是 SwiftUI 的出現讓 Apple 平臺開發者又充滿了但願。不過我在落地一些內部 APP 的時候也發現了一些 SwiftUI 的不足，如框架成熟度不夠，某天寫的代碼忽然操做系統升級後就發現極大的佈局不兼容問題；並且 SwiftUI 必須內置在操做系統中，又不能解決跨 Android 端的開發問題，這讓我對 SwiftUI 充滿了期待與擔心。」

不過姜沂我的的見解是，不管是 Weex、小程序，仍是 Flutter、SwiftUI，他們解決的問題是不同的，本質更不一樣。到底哪一個更優其實沒有標準答案，不一樣的業務場景和業務所處的時間點，形成選擇會不同。「咱們是工程師，並非 Swift 或者 Flutter 工程師，咱們選擇的技術最終要爲咱們的業務和商業服務。」

「擁有一把錘子能夠敲一個釘子，擁有一個工具箱能夠造一艘航母」。

最後：淘寶基礎平臺團隊正在舉行 2020 春季實習生和社招招聘，崗位有 iOS Android客戶端開發工程師、Java研發工程師、C/C++研發工程師、算法工程師、數據開發工程師。 歡迎投遞簡歷至(君展)：📮 junzhan.yzw@taobao.com 若是你想更詳細瞭解淘寶基礎平臺團隊，歡迎觀看團隊介紹視頻更多淘寶基礎平臺團隊的技術分享，可關注淘寶技術微信公衆號AlibabaMTT