閒魚前端技術體系的背後——魔魚（良心推薦，從思路到實踐）

閒魚經過近八年的發展，前端技術在整個研發體系中有著舉足輕重的地位，前端有 迭代速度快 ， 動態化能力強 ， 跨端適配成本低 等顯著優勢。閒魚前端一直使用淘系提供的基礎技術和平臺工具，但隨著業務的不斷髮展，逐漸無法滿足複雜、個性化的業務和技術環境。

工欲善其事，必先利其器， 擁有自己的上層研發體系勢在必行，於是從去年下半年開始，前端開始著手代號為「魔魚」的技術體系建設。

魔魚

目前魔魚包含 產研平臺 、 研發模式 和 閘道器建設 三大部分。

產研平臺

閒魚原有的研發流程是在集團提供的 工程研發平臺 上進行的。大致流程如下：

1. 1.  在研發平臺創 建應用，同步建立Git倉庫；

2. 2.  在研發平臺建立 迭代，同步建立Git分支；

3. 3. 獲取分支程式碼進行本地研發；

4. 4. 提交分支程式碼， 研發平臺 進行日常/預發構建部署，H5應用構建產物為 CSS/JS/HTML ，把HTML文件部署到Web伺服器，生成Url進行測試；

5. 5. 完成測試， 研發平臺 進行正式釋出，給出最終投放Url，並且結束迭代；

可以看到原有的研發流程主要依賴於集團 研發平臺 提供的基本能力，由於平臺定位問題，功能相對單一，很多問題還是需要團隊自己想辦法解決：

問題分析

腳手架及應用配置問題

研發 平臺提供應用建立引導，幫助初始化應用工程Git倉庫和腳手架程式碼。但是這樣建立專案的缺點也非常明 顯：

1. 1. 只能用於初次建立應用，後續腳手架升級需要配合另外的升級命令或文件。如果在研發過程中對腳手架改動較大，也會對後續的升級造成一定的困難；

2. 2. 大部分情況下，初始化工程並不能直接投入使用，還需要經過一系列手動配置，配置過程對腳手架並不熟悉的新同學來說也是相當痛苦，配置錯誤會導致專案無法執行，甚至對產品質量和效能造成影響。

頁面管理問題

研發平臺只關注 研發流程，而對應用產物（頁面）的管理並不是它的強項。對於閒魚業務來說，研發構建釋出僅僅是開發同學要關心的，業務同學更關心頁面的管理及使用，所以衍生出了其他資料投放和管理配置平臺，這樣的問題是：頁面釋出和資料配置釋出割裂，經常因為兩邊釋出沒有同步，導致線上頁面和配置不一致造成故障。

解決方案

• •  統一模板管理 ： 魔魚平臺整合應用建立及升級功能，預定義工程模板、提供可變配置項，支援建立差異化的工程模 板，並且模板和配置後期可以在 魔魚平臺 進行配置調整及版本升級，徹底告別原生代碼維護應用框架的做法。

• •  整合配置管理 ： 魔魚平臺提供運營資料配置投放能力，從流程上管控資料配置投放和頁面釋出，保證線上資料的一 致性，實現一站式研發、配置能力。

• •  場景管理模式 ： 魔魚平臺提供了業務維度的管理模式，可以把不同應用構建的頁面進行圈選，統一管理這些 頁面的許可權、配置及釋出，大型活動和部分產品鏈路都比較適合用這種模式管理多個頁面集合。

• •  接管釋出流程 ：最終的文件釋出和配置資料釋出都在魔魚平臺進行，保證了釋出流程的一致性，也對定製化研發實現了流程閉環。

補充一個魔魚平臺整體能力圖：

研發模式

之前閒魚的H5業務只有兩種研發模式可選： 原始碼開發 和 模組搭建 。複雜邏輯業務和產品鏈路以原始碼開發為主；活動和一些二級導購頁面以模組搭建為主。隨著業務複雜度提高、對效能體驗要求的提升，需要擴充套件研發模式，升級技術方案。

問題分析

產品和運營結合

原始碼開發的頁面一般以產品屬性為主，運營很少能介入這類頁面的配置和搭建。這類頁面如果要配合某些大促活動增加一些運營屬性，需要額外的開發工作，並且當活動結束後，還要把這部分程式碼刪除，否則容易產生冗餘業務邏輯。

搭建的靈活性與體驗效能的平衡

閒魚一直在使用集團提供的 通用搭建平臺，它基 於一套標準的模組研發管理模式，並且提供整頁搭建的能力，但是這個平臺並不是為閒魚量身定製的，很多功能對於閒魚來說過渡設計，並且由於閒魚自建商品招選體系，導致在資料投放層面無法跟 搭建平臺 很好地融合，每個模組需要內建資料的獲取和處理邏輯，當頁面模組數量一多，頁面的體驗效能會受到較大影響，而且內建業務資料邏輯的模組也很難複用。

解決方案

原始碼/搭建融合方案

這套方案彌補原有技術能力不足的問題，融合 純原始碼 、 原始碼搭建 和 純搭建 ，開發同學也不再需要做二選一的選擇題。

技術方案底層邏輯還是依賴集團的模組體系，這樣可以最大限度地利用已有元件物料，同時在模組配置上，引入插槽（Slot）的自定義型別，結合編輯器，實現模組靈活搭建，並且可以巢狀，讓模組組合更加靈活。

基於模板的研發模式

以前應用構建的最終產物是  HTML/JS/CSS ，現在產研平臺接管了應用建立和配置管理等工作，文件具有動態化能力，最終產物是  XTPL/JS/CSS/Schema ：

• • 其中 XTPL 是動態文件模板，線上頁面基於它例項化之後可以被CDN快取；

• •  Schema 是對投放配置資料格式的描述，在平臺編輯器解析這份描述檔案，渲染出配置表單。

這種研發模式，除了上文提到了平臺可以接管頁面框架配置以外，還可以基於頁面模板建立多個頁面例項，實現一碼多頁，並且每個頁面又具有獨立的搭投能力，應用的靈活性有了大幅提升。

閘道器建設

在導購和營銷活動、大促場景下，頁面資料基於運營配置，資料模型之間又有相互依賴關係，比如運營配置了一組選品id，需要發起二次請求來獲取這組選品id下對應的商品資料。

在搭建場景下，模組相對獨立，有完整的資料獲取及消費邏輯，當多個模組搭建成一個頁面之後，每個模組獨立處理資料獲取和渲染邏輯，導致模組渲染時機不可預期，大量並行的請求也會導致請求阻塞。

問題分析

首屏效能差

由於存在序列資料獲取的邏輯，頁面渲染時機延後，導致首屏渲染時間較長。解決這類方案一般有以下幾種：

1. 1.  服務端膠水層 ：由服務端把頁面依賴的資料合併成一個介面返回，這種僅適合相對穩定的產品業務，對於搭建場景就不可用，而且這類介面沒有複用性，由服務端維護膠水層也並不是一個明智的選擇；

2. 2.  前端使用SSR直出文檔 ：這種方式相當於由前端接管膠水邏輯，一方面需要基建支援，另一方面無法做頁面快取，對於訪問量大的頁面，對SSR服務的壓力考驗也比較大，比較費資源。一些對體驗要求高的核心產品頁面，SSR確實是一種提升體驗效能的王炸，但它還不能作為一個通用技術方案覆蓋所有業務場景。

3. 3.  實現一個輕量的閘道器 ：處理資料依賴分析、召回、補全、裁切等輕邏輯，這個方案適用於處理通用資料模型，比如商品、內容、使用者等，不適用於單一產品資料模型。

元件模組複用率低

由於模組需要負責資料獲取邏輯，資料跟業務的耦合度較高，導致開發了很多UI相同，資料依賴不同的模組。這對UI元件複用和維護都不友好。

解決方案

前端資料閘道器

為了解決首屏資料載入效能問題，針對 導購 、 營銷 場景，我們採用上面提到的 實現一個輕量的閘道器 的方案，順便聯合服務端，對現有閒魚通用資料模型進行梳理及標準化制定。

動態模板渲染

針對上文提到的動態模板搭建的研發模式，我們接入集團提供的 動態模板渲染引擎 ，當運營在魔魚平臺編輯器完成頁面搭建、配置和釋出之後，不需要前端介入開發就可以實現模組JS/CSS資源的動態注入，實現文件的動態配置渲染。

補充一個文件和資料消費鏈路圖：

魔魚現狀

將魔魚率先應用到標準資料模型場景

• • 閒魚業務畢竟是電商App，前端支援的業務中，導購和營銷場景比較多，比如「閒魚優品」、「手機數碼」；

• • 閒魚也在不斷探索內容場景，比如「會玩」、「圈子」；

無論 商品 和 內容 都是相對容易標準化的資料模型，通過資料閘道器接入後可以快速得到資料效能優化的收益；同時這類業務也是運營參與比較多，利用魔魚的研發、搭投一體化的體驗，提高研發效率和運營配置效率及體驗。

業務遷移效能對比

以手機數碼頻道為例。這個頻道在遷移之前，首頁主要資料介面有2個，並且是序列依賴關係；遷移到魔魚之後使用平臺數據配置投放，利用閘道器的資料召回能力，把資料介面合併成1個。

上線後資料：

• • 首次內容繪製(FCP)：  673ms -->  1s 這個資料的延長，主要是閘道器處理原來2個介面的依賴和召回邏輯。

• • 跨端首屏(sfsp)：  2502ms -->  1918ms 這個資料的縮短，就是因為省下了端上資料依賴和請求處理的時間。

直觀效果對比：

改版前	改版後

未來規劃

1. 1. 魔魚作為前端統一研發體系，不光可以支援H5的研發，後面還可以支援端外小程式、高效能容器的業務開發，提供豐富的研發模板型別，配合元件物料實現頁面快速建立；

2. 2. 前端跟服務端緊密結合，除了進行標準化資料模型定義之外，還會接入更豐富的投放配置能力，比如人群定投、AB實驗等動態投放策略；

3. 3. 跟招商、權益、測試、埋點/監控等平臺進行資料互通和工作流關聯，降低多平臺之間的流程操作成本。

4. 4. 基於Schema的描述模型和配置編輯器可以作為衍生產品，給閒魚其他的中後臺系統使用，統一閒魚的資料投放方案。