手淘App如何落地Swift?一邊探索實踐,一邊“打怪升級”

自從 2014 年蘋果發佈 Swift 至今,歷經多次迭代,Swift 終於迎來了 ABI 穩定,SwiftUI 的發佈也引起無數 Apple 平臺開發者的歡呼。多年來廣受關注而又備受爭議的 Swift,終於開始被很多大型 App 堅定地採用。在這其中,淘寶 App 就是一個典型:從 Swift 2.0 時代的淺嘗輒止,到去年 3 月 ABI 穩定後充分調研並正式採用,這其間經歷了什麼樣的考量過程?淘寶 App 落地 Swift 的最關鍵環節有哪些?如何解決落地 Swift 過程中的挑戰?近日 InfoQ 記者採訪到阿里巴巴淘系技術部 iOS 端架構高級無線開發工程師姜沂,請他對以上問題進行詳細解答。在即將到來的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 的關注度劇烈下降:

  1. 知名 Objective-C 開源庫如 AFNetworking 已經將近 2 年沒有重大更新,距離最後一次 Bug Fix 也已經有 1 年時間,對比之下 Swift 社區則很活躍;
  2. StackOverFlow 等社區對 Objective-C 的提問已經近乎停滯,淘寶 App 團隊成員近兩年找尋疑難問題的解答幾乎沒人關注;
  3. WWCC17 後,蘋果所有 Sample Code 皆用 Swift 展示。

姜沂告訴記者:“我們的初步結論就是:按照蘋果歷來的強硬態度,如果我們還是堅守 Objective-C 陣營,如果未來蘋果強制推進Swift,或者只更新 Pure Swift Framework,或者社區出現大技術更新、比如 HTTP3 網絡庫,會對我們目前的社區研發環境造成比較大的衝擊。我們很可能被動的付出較大成本來適應變化,比如需要自己造 Objective-C HTTP3 的網絡庫輪子。”

“簡單來說就是:我們可能在未來一兩年內因爲 Objective-C 而造成技術踏空,這一後果會對我們的人員招聘、技術前瞻性、研發成本都會帶來較大風險與負擔。”

調研結果加之 Swift 隨後的進展,更讓淘寶 App 堅定了走 Swift 之路的決心:

  1. 在調研一個月後 WWDC19 更新了 SwiftUI、Combine 等 Pure Swift 框架,初步的驗證了之前的結論;
  2. 蘋果放開了 200M 蜂窩網絡下 IPA 包大小的限制, 同時iOS12.2 以下系統需要內置包大小的設備佔比已經不足10% 且會隨着時間的推移,存量越來越少;
  3. 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 工程師,我們選擇的技術最終要爲我們的業務和商業服務。”

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

嘉賓介紹:

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

活動推薦:

最近幾年,很多新的語言憑藉更現代的語言特性、更高的開發效率,以及背後大廠的支持,應用越來越廣泛。

GMTC全球大前端技術大會(北京站)設置“編程語言”專題。本專題將關注新語言(比如:TypeScript、Swift、Kotlin 和 Dart 等)在具體業務開發中的選型思考,以及替代遺留項目時的典型解決方案。

疫情期間,大會也會爲大家送上3月福利,大會門票限時5折起,還有極客時間企業版年卡免費送!活動截止3月31日,眼看已經過半,還沒有參與的你抓緊嘍!

聯繫票務經理魚丸:13269078023(同微信)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章