閒魚正在悄悄放棄 Flutter 嗎?

語言: CN / TW / HK

採訪嘉賓 | 於佳(宗心)

編輯 | Tina

閒魚在 2017 年引入 Flutter,當時的 Flutter 還遠未成熟,行業內也沒有把 Flutter 放入已有工程體系進行開發的先例。

之後這支不到 15 人的閒魚團隊從工程架構、混合棧呼叫、打包構建、協同模式上都做了一些創新,保證了 Flutter 能融入到閒魚已有的客戶端工程體系內。在 2017 年到 2019 年期間,閒魚也不斷的修正 Bug 提高 Flutter 的穩定性並同步給 Google,並在實踐中沉澱出一套自己的混合技術方案,開源了 Flutter Boost 引擎。

2019 年,閒魚開始大規模落地,推進 Flutter 在閒魚的應用。2020 年,閒魚線上的主鏈路幾乎已經完全擁抱 Flutter。這兩年,Flutter 也逐漸在其他企業裡落地,但同時也不斷有質疑的聲音發出。甚至有傳言表示“閒魚的新業務已經放棄 Flutter”、“相信閒魚遇到了很大的難題”......

那麼,作為 Flutter 先驅和探路者,閒魚在過去幾年的摸索過程中是否有走彎路?閒魚現在到底面臨著什麼樣的挑戰?是否會放棄 Flutter?新業務選擇了什麼技術?對應的技術選型原則是什麼?針對這些疑問,閒魚技術團隊客戶端負責人於佳(宗心)逐一給了我們解答。

國內第一個引進 Flutter 的團隊

InfoQ:閒魚當時引進 Flutter 時主要是為了解決什麼問題?

於佳(宗心):閒魚在 17 年調研的時候,客戶端團隊只有不到 15 人,而閒魚的業務場景可以稱得上是一個 “小淘寶”,相對比較複雜。這種場景下我們首先需要解決的是多端人力共享的問題。多端人力帶來的好處不只是可以一人開發雙端,也代表著更好的研發資源調配靈活性(這意味著團隊的 iOS:Android 的比例不再需要 1:1,而市面上 Android 的工程師基數遠大於 iOS)。

另外我們希望這個技術是貼合移動端研發技術棧的,而非前端技術棧,本身對於 RN 和 Weex 來說,工具鏈和研發習慣還是有比較大的差異的。最後我們希望這個技術的體驗可以做到接近原生,AOT 下的 Flutter 基本滿足我們當時的要求,在實際測試過程中,同樣未深度優化的詳情頁面,Flutter 在低端機的表現比 Native 更好。因此當時基於這三個條件選擇了 Flutter。

2018 年的嘗試投入過程中,整個基建和探索帶來了一定的成本。2019 年,團隊開始正式大量使用 Flutter 進行研發,目前整個團隊 70% 的 commit 來自 Dart,可以說基本完成了我們當初的期望。在實際的研發過程中,基本可以完成一個需求一個客戶端投入的目標。

InfoQ:很多人質疑 Dart 語言,認為這個語言獨特小眾,還存在比如說多層巢狀的問題,您們怎麼看待新語言的應用?

於佳(宗心):語言是我們選擇技術方案的其中一個因素,但是相對比較弱的因素。

我們會從幾個角度去看:

  • 語言的背景,從我們的角度來看 Dart 是大廠研發的,也有比較久的歷史。

  • 語言的學習成本,從語法糖和學習曲線上來看,Dart 成本都比較低,首先 Android 同學的上手率很快。另外熟悉 swift 的 iOS 同學,上手也很快。現代語言的特性有很多是相通的。這部分是它的優勢。

  • 語言帶來的其他優勢,如編譯產物支援 AOT 和 JIT,比較靈活。AOT 有明顯的效能優勢。

  • 語言的未來的趨勢。Dart 在 2020 年第四季度 Github Pull Request 的排名已經到了全網第 13 位,超過了 Kotlin(15 位),Swift(16 位),Objective-C(18 位)。作為移動技術領域的新語言成長性還是非常不錯的。

對於像多層巢狀的問題,可以通過進一步抽象一些控制元件類或方法解決,並不是特別大的問題。

InfoQ:閒魚引入 Flutter 之後做了哪些關鍵創新?在使用 Flutter 上有哪些收益?

於佳(宗心):閒魚在這部分創新非常多,並在內部申請了非常多專利。

  • 我們的開源專案 Flutter Boost 徹底改變了 Flutter 官方的一些 RoadMap。目前 Add2ExistApp 是行業最主流的研發方式。混合開發一方面幫助了業務更平滑的遷移到了新的技術棧,另一方面可以更好的利用已有的 Native 能力,大幅減少了重複開發的工作。

  • 針對音影片的外接紋理方案,也是目前行業大廠常見的解決方案,在外接紋理方案下,Native 和 Flutter 側的快取管理得到了統一,在效能上也有一定的提升。

  • Flutter APM,基於 Flutter 技術棧的效能穩定性資料採集和加工方案,目前在集團內部也是跟多個 BU 一起共建,為大的 AliFlutter 組織提供服務。

  • Flutter 相關的動態模版方案,Flutter DX,相容集團的已有的 Native 模版,保證了業務的平滑遷移,併為 Flutter 提供了部分業務動態性。

  • 其他還有很多,包括內部的高效能長列表容器 PowerScrollView,動畫框架 Fish-Lottie,遊戲引擎 Candy,我們現在還有一些新的方向在沉澱,在基於 Flutter 的研發流程和研發工具上也有投入,未來大家如果感興趣可以去 InfoQ 組織的行業大會與我們交流。

閒魚有想過放棄 Flutter 嗎?

InfoQ:最近一兩年,您們在 Flutter 開發上,遇到的最大挑戰是什麼?跟最初使用 Flutter 時的挑戰一樣嗎?

於佳(宗心):早先幾年閒魚作為整個行業的先驅,主要的挑戰是整個技術生態太差,都需要自己做。另外就是前期引擎的穩定性有比較大的問題。

最近幾年隨著整個技術的深度使用,以及閒魚這兩年業務快速發展背後,越來越多的體驗問題被大家提及,因此我們從去年開始進行了整個產品的大改版,同時客戶端的目標就是全面優化,打造更好的使用者端產品體驗。

因此在生態逐漸完善後,我們的挑戰是,怎麼通過 Flutter 來實現更加精細化的使用者體驗。去年,這部分確實花了我們比較多的精力。基於這個命題,我們在記憶體和卡頓上內部也開發了較多的基於 Flutter 的檢測工具,在記憶體優化和卡頓優化上也有一些比較具體的方法,但不得不說,所有的細節優化都是比較耗人力的,不管是 Native 還是 Flutter 都要投入相當的精力,所以我們目前也面向全行業進行客戶端的招聘,希望有志在 Flutter 領域進行探索的同學聯絡我。

InfoQ:在混合研發體系下,閒魚還進行了引擎定製,那麼官方提供的方案主要問題是什麼?對於一般小企業來說,混合開發複雜度會不會太高?

於佳(宗心):閒魚在前期有不少修改引擎的動作,我針對當時有一些 自己的反思,一方面是確實因為 Flutter 不太完善,另一方面在 18 年左右,我們自己引擎的理解也不夠深刻,很多時候可以通過更上層的方案解決,這也間接導致了我們的很多引擎定製修改難以合入主幹。

所以這部分我想說的是,目前官方的方案可以解決 90% 的問題,如果一定要說定製,目前在效能側還是有一些問題的。比如閒魚目前首頁還是 native 沒有使用 Flutter,就是因為替換以後啟動載入體驗不佳,另外在長列表側大家一直詬病的卡頓問題,我們有嘗試通過上層框架解決了一部分,接下來可能還需要底層引擎幫忙優化。另外一些包括雙端字型不一致的問題,還有輸入框體驗不一致的問題,都需要官方進行長期的優化。

目前我們主要還是希望跟隨主幹分支,儘量不修改 Flutter 的程式碼,閒魚團隊會儲備一些引擎側的專家,同時也會依靠集團 AliFlutter 的生態做事情。在整個 AliFlutter 的組織裡不同的 BU 擅長的也不同,如 UC 同學更擅長引擎定製,閒魚團隊有大量的上層應用框架,淘寶團隊提供基於構建相關的基礎設施。這樣在大型公司中通過內部開源社群的方式就可以解決大部分的問題,放心開發了。

對於中小企業來說,要明確下大家面臨的場景,如果前期快速迭代跑起來,對細節問題可以有一部分妥協,選擇 Flutter 是一個比較明確的路徑。今天大家所處的環境比閒魚當年所處的環境要完善的多。推薦使用 Flutter Boost 進行混合開發,在部分場景下遇到問題無法快速響應時,也可以通過混合工程使用 native 進行兜底。複雜度方面,單純引入混合棧能力,整體複雜度一般。

InfoQ:有傳言,閒魚有新業務沒采用 Flutter,這給很多人造成了閒魚放棄 Flutter 的觀念,那麼您們在新業務的技術選型上,考慮了哪些因素?

於佳(宗心):作為技術決策者,是應該避免自己被某一個技術綁架而在落地過程中產生謬誤的。Flutter 和其他技術一樣,最終是為了幫助團隊實現業務價值,同時它也只是移動端的一種技術,捧殺和謾罵都是不合適的。這也是我特別不想在公眾面前迴應這個事情的原因,因為 技術本身要看適用場景。

從目前閒魚的人員規模和業務規模來看。對於架構設計,我的理念是儘量追求一致性和架構的簡潔。

整個客戶端組織未來從語言的方向來看是 Dart First,儘量減少雙端的研發投入。而對其他容器的選擇,主要以 H5 為主,在未來的路徑上儘量減少其他容器的接入,讓前端開發也迴歸到標準路線來。

這裡有兩個好處:

  1. 組織成本最低,組織成本包括了同學們的學習成本、協同成本等等,多技術棧和容器多會帶來額外的成本,這是我不願意看到的。

  2. 架構的一致性對研發效能和質量都有幫助。舉個例子,隨著業務複雜性加大,多容器帶來的記憶體飆升和包大小的問題是非常致命的,而且幾乎是無解的,這就需要架構師作出決策,幹掉什麼留下什麼。回到研發效能上,配套的工具,流程一定是圍繞一類容器和語言來擴充套件的,如果方案特別多,每個方向都需要做額外的配套設施,成本收益很低,研發的幸福感也很低。

從這個設計的角度出發,我們會有幾個明確的選擇

  • 在預設場景下使用 Flutter 作為首選的方案;

  • 在投放活動、前臺導購、非常不確定的新業務、以及管理後臺等使用 H5 作為首選實現方案;

  • 在極少場景下,比如已有完整的 SDK 附帶 UI 的支援如直播,以及未來中臺的拍攝功能 SDK 也是自帶 UI 的部分,如要切換,Native 成本最低,選擇 Native。另外目前 Flutter 在首頁載入還有一定的效能問題,因此還在使用 Native。從長遠發展來看,未來到一定程度可能隨改版直接改為 Flutter。

關於未來發展

InfoQ:使用 Flutter 多年後,現在回過頭去看,您認為哪些公司哪些場景適合 Flutter?

於佳(宗心):目前看起來有幾個典型場景比較適合:

  • 中臺戰略下的小前臺產品,從大公司的組織裡看阿里、頭條、美團都有相對完善的 Flutter 組織或內部技術社群可以提供一些基礎服務,保證了基於 Flutter 基礎設施在前期投入過程中的成本均攤,在未來落地過程中,業務團隊可以更加專注於業務研發,而更少的擔心過程中填坑的成本。

  • 中小型企業的初創 App,在人力成本資源都不夠的情況下,希望先跑通流程上線驗證的團隊,可以嘗試使用 Flutter 進行研發,在我自己實際的面試和行業交流過程中,這一類情況也比較典型。這種方式可以避免前期成本過度投入,在人員調配上也更加靈活。

  • 另外這個觀點還沒有驗證,但是邏輯上應該可行。未來面向企業內部流程工具,政府部門的部分工具屬性較強的 App,可以嘗試使用 Flutter。因為目前我瞭解的情況來看,在企業這邊的應用來看,整體 ToB(美團商家端)和 ToD(比如餓了麼騎手端)的場景的 App 特別多。橫向比較來看,場景比較類似,也就是說更多中長尾應用有可能是 Flutter 技術的主要場景。

InfoQ:您認為未來 Flutter 急需改善的地方是什麼?

於佳(宗心):從 Flutter 2.0 釋出後我跟一些一線開發者交流的感受來看,Flutter 還是需要推進跨端效能和細節體驗的優化。去年一年在大的戰略方向上(跨終端),Flutter 做的不錯,在 PC 和 Web 側都有建樹,跟車企以及作業系統廠商合作都有一定進展。但迴歸到產品體驗和開發者體驗上,還有不少路要走,很多時候對於一個嚴苛的業務方來說,小到字型和控制元件的體驗都會成為最後不選擇這門技術的原因。這部分希望整個開源社群在新的一年能有一些進步。我們 AliFlutter 組織內部,以 UC 核心團隊為首的同學們,在這方面就有非常多的沉澱以及 PR,在內部引擎制定上有很多體驗的提升。未來在 AliFlutter 組織內,我們也會除了完善整個公司的基建外,進一步關注細節體驗,沉澱一些最佳實踐給到其他的開發同學。大家會在2個月內看到我們最新出版的書籍,歡迎交流。

InfoQ:Flutter2.0 來了,那麼 Flutter 會成為主流選擇嗎?

於佳(宗心):可以講一下我對 Flutter 未來的判斷。一方面在未來作業系統有可能走向分裂,多終端的場景下,Flutter 會有比較不錯的發展,跨平臺本身的對企業來說在成本側是有很大的訴求的,尤其是網際網路公司。但是從歷史的經驗來看,Flutter 只是渲染引擎,即使今天的遊戲開發,在遊戲引擎和配套工具完善的情況下,有部分的功能模組(比如社群 / 直播的功能)依然還是混合的框架,所以混合開發最後一定是一直存在的。能不能成為未來整個移動研發的主流這件事情上看,我無法給出答案,但可以肯定的是,在生態更加完善後,會在一定的歷史階段成為客戶端研發的另一種常見的技術選擇。

嘉賓介紹:

於佳,花名 宗心,閒魚技術團隊客戶端負責人。2012 年應屆畢業加入阿里巴巴,經歷集團無線化轉型的重要時期,參與過集團多款重量級 App 以及移動中介軟體的設計與開發,多年客戶端老兵。2014 年參與了手機淘寶的 iOS 客戶端的架構升級,該架構首次完成了對百人團隊並行開發的支援,同年主導了手機天貓客戶端基礎架構以及交易鏈路向手淘架構的歸一,為手機淘寶作為未來集團無線中臺奠定了堅實的基礎。2015 年加入閒魚客戶端團隊負責端架構和團隊建設,工作期間完成了基於 Flutter 混合架構的閒魚客戶端的整體架構設計,在工程體系上完善了針對 Flutter 的持續整合以及高可用體系的支撐,同時推進了閒魚主鏈路業務的 Flutter 化。未來將持續關注終端技術的演變及發展趨勢。