閒魚正在悄悄放棄 Flutter 嗎？

採訪嘉賓 | 於佳（宗心）

編輯 | 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 化。將來將持續關注終端技術的演變及發展趨勢。