手淘 App 如何落地 Swift ？一邊探索實踐，一邊“打怪更新”

嘉賓|姜沂（傾寒）

出品|InfoQ&阿裡巴巴新零售淘系技術部

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

前言

自從 2014 年蘋果釋出 Swift 至今，曆經多次疊代，Swift 終于迎來了 ABI 穩定，SwiftUI 的釋出也引起無數 Apple 平台開發者的歡呼。

多年來廣受關注而又備受争議的 Swift，終于開始被很多大型 App 堅定地采用。

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

近日阿裡巴巴淘系技術部 iOS 端架構進階無線開發工程師姜沂受 InfoQ 采訪邀約，他對以上問題進行詳細解答。

并且在即将到來的 GMTC2020 全球大前端技術大會上，他也将帶來《手淘航母級 App 戀上 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 應用不普及帶給使用者的觀望情緒。對于這個問題，姜沂認為要從兩個方面來看。

首先是業務視角：

1. 在業務需要快速疊代的時候，現有的 iOS 工程師主要以 Objective-C 為主，轉戰 Swift 需要一定的學習曲線，而且采用 Swift 效率是否一定有提高也有待考證；
2. Swift 隻能解決 iOS 側 Native 研發問題，對于高疊代效率的跨平台技術，收益不足。

其次是技術視角：

1. Swift 早期由于 ABI 不穩定，隻能将 Runtime 内置在 IPA 包裡面，占用約 3M 的下載下傳空間，蘋果還有 150 M 的蜂窩網絡下載下傳大小的限制，且對啟動性能有 150ms 的影響，在各家公司拼體驗的時代，這些都會對公司的業務造成負擔和損耗；
2. 由于文法不固定，每次更新都會造成源碼級别的 Break Change，對開發者也會造成負擔。淘寶、美團等巨型 App 都采用了二進制組建化研發子產品，Swift 隻能固定開發工具版本，對大型團隊是一種負擔和制約，反而極大的降低了研發效率。

不過姜沂認為未來一兩年内國内 Swift 生态還是會有巨大改善的，主要有以下幾個方面：

1. iOS 12.2 以上内置 Swift Runtime， 包大小随着存量舊版本作業系統更新後得到緩解；
2. iOS 12.2 以上也沒有啟動性能的影響；
3. Swift 文法不再大變，不會對開發者造成負擔；
4. 蘋果繼續強勢推進，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 工程師，我們選擇的技術最終要為我們的業務和商業服務。”

“擁有一把錘子可以敲一個釘子，擁有一個工具箱可以造一艘航母”。

關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~