解密國內BAT等大廠前端技術體系-美團點評之下篇（長文建議收藏）

引言

在上篇中，我已經介紹了美團點評的業務狀況、大前端的技術體系，其中大前端的技術全景圖以下：

 

 

 

上篇重點介紹了工程化和代碼質量的部分，工程化涵蓋了客戶端持續集成平臺-MCI、全端監控平臺-CAT、移動端集成日誌庫-Logan和全棧前端框架-Era。代碼質量部分重點介紹了ESLint在大規模項目中落地實踐和移動端靜態分析工具-Hades。

在這篇文章中，咱們將繼續介紹大前端技術體系中的跨平臺、UI組件庫和前端框架。

跨平臺

跨平臺動態化方案

跨平臺、動態化始終是移動互聯網時代永恆的話題，在性能體驗和研發效率之間不斷尋找平衡，誕生了一批批跨平臺動態化方案。

 

 

 

 

將業界主流的跨平臺方案整理一下，大體分爲四個類別：

• 佈局動態化：主要依賴是客戶端的渲染能力，經過約定佈局配置的數據結構（例如JSON），能夠後端動態下發佈局內容，客戶端解析而後進行渲染，從而實現必定能力上的佈局動態化。
• 虛擬運行環境：類RN、Flutter的解決方案，RN/Weex是經過JS來編寫前端代碼，而後經過Virtual Dom轉換成Native界面元素進行渲染，達到了研發效率和性能渲染的平衡。Flutter在RN的理念上又邁出一步，將底層渲染引擎用C/C++本身實現，從而減小JS/Native之間通訊成本，並且統一了iOS、Android雙平臺的組件渲染樣式。
• 業務插件化：在Android系統中，經過特有的插件化能力，實現動態更新的能力，可是不能支持iOS，所以多用於Android系統中Hot fix。
• Web容器加強：本質都仍是經過WebView來渲染、執行頁面功能，經過JSBridge來補強實現原生能力。能夠經過本地離線包減小資源文件的遠程加載，從而提升用戶體驗。

在跨平臺、動態化方案中並不存在銀彈，每一個方案都存在必定的取捨，下圖就總結了各個方案在用戶體驗、穩定性、上線實時性、開發效率和遷移效率五個方面的對比總結：

 

 

 

每種方案都有優勢和缺點，因此每種方案的適用場景是不同的。

• 佈局動態化：穩定性要求高，性能要求高，適合高流量的運營頁面
• 虛擬運行環境：可用於新業務探索，或者對於性能要求不高，業務迭代迅速的業務型功能
• 業務插件化：Android熱更新，或者老業務的遷移
• Web容器加強：短時間的活動、營銷類頁面，對於性能交互要求不高，使用週期不長的業務

美團的動態化方案

美團點評針對多種業務形態和各個業務的階段，沉澱了多種跨平臺解決方案，總結以下圖：

 

 

每種技術方案都須要周邊的配套設施來支持，從底層依次是運行環境、輔助工具和業務接口，因此在每種技術選型上都須要慎重，尤爲對於中小型公司，結合自身業務尋找合適的技術框架來知足業務開發最爲重要，而不要僅僅爲了追求最新、最炫而盲目採納新技術。

MRN

MRN-Meituan Reative Native，顧名思義能夠知道這是美團基於RN框架進行封裝優化的一個跨端動態化框架，下圖能夠看到MRN的整個周邊設施建設：

 

 

須要涵蓋完整的研發週期，例如發佈系統中須要可以有打包MRN的能力、對MRN代碼進行發佈和代碼檢查；須要配套的開發工具，提供將原生代碼轉換成MRN的工具；在業務開發中，首先要對MRN框架進行大量優化，對其性能進行優化，核心包進行拆包優化大小，抹平雙平臺的差別，同時也須要沉澱大量業務的MRN組件和原生能力的橋接；線上運維部分須要包括對異常錯誤、性能、穩定性等方面的監控。

Picasso

Picasso是大衆點評移動研發團隊自研的高性能跨平臺動態化框架，通過三年多的孕育和發展，目前在美團多個事業羣已經實現了大規模的應用。

 

 

Picasso應用程序開發者使用基於通用編程語言的佈局DSL代碼編寫佈局邏輯。佈局邏輯根據給定的屏幕寬高和業務數據，計算出精準適配屏幕和業務數據的佈局信息、視圖結構信息和文本、圖片URL等必要的業務渲染信息，咱們稱這些視圖渲染信息爲PModel。PModel做爲Picasso佈局渲染的中間結果，和最終渲染出的視圖結構一一對應；Picasso渲染引擎根據PModel的信息，遞歸構建出Native視圖樹，並完成業務渲染信息的填充，從而完成Picasso渲染過程。須要指出的是，渲染引擎不作適配計算，使用佈局DSL表達佈局需求的同時完成佈局計算，即所謂「表達即計算」。

 

 

 

 

業界對於動態化方案的期待一直是「接近原生性能」，可是Picasso卻作到了等同於原生的渲染效率，在複雜業務場景能夠達成超越原生技術基本實踐的效果。就目前Picasso在美團移動團隊實踐來看，同一個頁面使用Picasso技術實現會得到更好的性能表現。

Picasso實現高性能的基礎是宿主端高效的原生渲染，但實現「青出於藍而勝於藍」的效果卻有些反直覺，在這背後是有理論上的必然性的：

• Picasso的錨點佈局讓佈局表達和佈局計算同時發生。避免了冗餘反覆的佈局計算過程。
• Picasso的佈局理念使視圖層級扁平。全部的視圖都各自獨立，沒有爲了佈局邏輯表達所產生的冗餘層級。
• Picasso設計支持了預計算的過程。本來須要在主線程進行計算的部分過程能夠在後臺線程進行。

詳細能夠查看參考資料[1]。

UI組件庫

beeshell - RN組件庫

爲了進一步下降開發成本、提高產品迭代的效率，美團開始推廣使用 RN 技術。隨之而來，相關業務方開始提出對 RN 組件庫的訴求。2018 年 11 月，公司內部發起了 RN 組件庫建設，旨在提供全公司共用的組件庫。鑑於咱們團隊在開源 beeshell 1.0時，積累了豐富的經驗，因而就加入到了公司級 RN 組件庫的項目共建中。完成組件庫開發後，咱們決定將共建的成果貢獻出來，並以 beeshell 升級 2.0 的形式進行開源，共計開源 38（33 個組件與 5 個工具）個功能。在服務社區的同時，也但願藉助社區的力量，進一步完善組件庫。

beeshell 2.0 效果圖以下：

 

 

  

總體架構以下：

 

 

組件庫由 1.0 的一個項目演變成 2.0 的三個項目（版本），造成組件庫體系。具體包含：公司通用版本MTD、外賣定製版本Roo和開源版本beeshell。

beeshell組件庫使用了分層的架構風格，分紅了接口層、組件層、工具層以及三端適配：

• 接口層。彙總全部組件，統一輸出，使用所有引入的方式，方便組件使用。另外，爲了不引入過多無用組件，引發資源包過大，也支持組件的按需引入。

• 組件層。細分爲原子、分子、擴展組件。 與 beeshell 1.0 相比，咱們對組件在更細的粒度上進行拆分。同時，層次劃分也更加精細、明確。如上圖 F 所示：基礎組件細分爲分子、原子組件。這樣，組件的繼承、組合方式更加靈活，可以最大化代碼複用。並且，原子、分子、擴展組件，各層次組件各司其職，「關注度分離」，兼顧通用性和易用性。

• 工具層。與 beeshell 1.0 相比，工具更加完備。不但新增了樹形結構處理器、校驗器等；並且工具的獨立性更強，與組件徹底解耦，與組件配合實現功能。 這樣，一方面，使得組件實現更加簡潔，提高了組件的可維護性；另外一方面，能夠將工具提供給用戶，方便用戶開發，提高組件庫的功能性、易用性。並且，工具與組件的解耦遵循「關注度分離」的原則。 三端適配。RN 在總體上實現了跨平臺，iOS、Android、Web 三端使用一套代碼，可是在一些細節方面，例如：特殊 API 的支持、相對位置計算等，各個平臺有較大差別。爲了更好的支持三端，保證跨平臺穩定性，還須要在這一層作不少適配工做。

除此以外，整個組件庫體系，還具有如下特色：更加完善的測試方案；豐富的代碼示例；使用 TypeScript（如下簡稱 TS）語言進行開發，充分利用 TS 的類型定義與檢查；針對每一個組件都有詳細的文檔說明。

詳細能夠查看參考資料[2]。

Vix - Web UI組件庫

Vix是金融BU沉澱了Web前端組件庫，適用於美團金融的業務場景，基於Vue框架，服務了超過60個業務產品。

 

爲了打造高效組件庫須要具有如下三個特色：

• UI 風格一致：只有 UI 風格與視覺側保持一致，高還原視覺稿，才能快速完成界面開發。
• 可複用性強：只有可複用性強，才能覆蓋更多場景，得到更多收益。
• 簡潔易上手：只有簡潔易上手，才能讓更多人使用，創造更大的價值。

在組件庫建設過程當中經歷了三個階段：產生期，發展期，優化期。

產生期主要是萌生了組件庫的想法，主要是爲了解決組件複用和標準化的問題，同時當時開源項目定製化成本高，沒法知足需求。

 

 

 

 

在這個階段，不一樣的業務、設計團隊共同合做，制定視覺規範，從而沉澱通用的組件庫，這樣不一樣業務的開發同窗就可以採用組件庫實現標準統一的業務樣式。

發展期：Vix 如何打造可復⽤用性強的組件體系?

 

 

  

經過對功能點的梳理抽象出一個個原子單元組件，保證每一個單個組件職責單一，組件對外接口一致。而後能夠經過對組件進行組合，而且賦予業務邏輯造成業務組件。

優化期：Vix 如何讓開發者使⽤用簡潔易易上⼿手?

 

 

 

優化期主要讓開發同窗可以更加方便的使用Vix，因而從文檔完善、提供示例、命名規範方面下降理解成本，經過引入簡單、配置簡單下降使用成本。

前端框架

mpvue - Vue小程序框架

mpvue 是一款使用 Vue.js 開發微信小程序的前端框架。使用此框架，開發者將獲得完整的 Vue.js 開發體驗，同時爲 H5 和小程序提供了代碼複用的能力。若是想將 H5 項目改造爲小程序，或開發小程序後但願將其轉換爲 H5，mpvue 將是十分契合的一種解決方案。

 

 

 

Vue.js 視圖層渲染由 render 方法完成，同時在內存中維護着一份虛擬 DOM，mpvue 無需使用 Vue.js 完成視圖層渲染，所以咱們改造了 render 方法，禁止視圖層渲染。熟悉源代碼的讀者，都知道 Vue runtime 有多個平臺的實現，除了咱們常見的 Web 平臺，還有 Weex。從如今開始，咱們增長了新的平臺 mpvue。

生命週期關聯：生命週期和數據同步是 mpvue 框架的靈魂，Vue.js 和小程序的數據彼此隔離，各自有不一樣的更新機制。mpvue 從生命週期和事件回調函數切入，在 Vue.js 觸發數據更新時實現數據同步。小程序經過視圖層呈現給用戶、經過事件響應用戶交互，Vue.js 在後臺維護着數據變動和邏輯。

能夠看到，數據更新發端於小程序，處理自 Vue.js，Vue.js 數據變動後再同步到小程序。爲實現數據同步，mpvue 修改了 Vue.js runtime 實現，在 Vue.js 的生命週期中增長了更新小程序數據的邏輯。

詳細能夠查看參考資料[3]

Thunder - 資源離線化

 

 

 

Thunder 是一個漸進式資源緩存與離線化方案。它經過瀏覽器本地存儲(localStorage/IndexedDB)緩存資源，而且基於 service-worker 提供了離線化能力。Thunder 的接入方式簡單，不會侵入你的業務代碼，僅需簡單的配置，便可讓你的 Webpack 項目享受高速資源加載。

• 漸進式 web 資源離線化: localStorage/IndexedDB 提供 JS 、CSS 離線化，ServiceWorker 全站離線化
• 增量更新：進一步利用緩存，下降資源版本更新成本
• 資源異常自動 CDN 降級: 提供頁面資源加載穩定性
• CDN 劫持自動降級: JS 內容檢查校驗和，不符合自動切換降級 CDN
• 極速頁面加載性能: SDK gzip 後 8 KB, 結合離線化和增長更新，提高現代 web 應用加載體驗
• 接入簡單快捷：使用 webpack 插件便可接入，不侵入業務

EH - 加強型Hybrid框架

EH - Enhanced Hybrid框架是美團金融研發的針對Hybrid業務場景的加強型框架。Hybrid實現雖然在研發效率上有很大優點，但同時也存在大量的用戶體驗問題。 

 

 

頁面白屏問題，沒法作到原生頁面在切換時候的流暢度。白屏問題的本質緣由在於原生頁面切換到Web頁面時候，Web頁面這時候還未加載渲染完成，所以會致使白屏問題。解決方案就是在當前原生頁面中經過一個不可見的webview將頁面進行加載，當webview頁面徹底加載完成後通知原生頁面而後進行跳轉。

 

  

離線化技術，經過資源離線化，線上增量更新，實現頁面的加載性能提高，接近於原生的渲染體驗。

交互一致性，因爲SPA的前端系統在頁面交互上難以作到原生一致的體驗，例如左滑回退操做等等，EH TransPage經過使用Native導航結合SPA頁面實現，在交互體驗上和原生保持一致。

一體化配置，前端頁面在Webview中缺少對外部宿主的有效控制，例如導航欄樣式、狀態欄文字顏色等等，EH Config提供一套接口可讓前端頁面靈活進行配置，實現視覺一致性。

下圖是EH的總體架構圖：

 

技術團隊的前端體系

美團點評是一個多業務形態的平臺，各個業務發展階段和技術訴求都不盡相同，所以前端技術在美團點評各個團隊中百花齊放，誕生了衆多的解決方案。下面我分享一下幾個表明性團隊的前端技術體系。

金融團隊

 

  

上文中已經介紹過Vix組件庫和EH的Hybrid加強框架，這張圖更加完整的展示了金融團隊前端技術體系的全景，從開發、編譯、部署到線上運行等環節。

詳細能夠查看參考資料[4]

 

酒旅團隊

以上是酒旅前端團隊的技術體系結構圖，咱們有兩種共存的項目類型（靜態化項目和服務端項目），靜態化項目是經過CDN進行承載，使用Vue進行功能開發，同時藉助移動端樣式組件庫提高開發效率，經過離線包機制和KNB (Native Bridge)加強頁面在容器內的表達能力，最後經過AWP（自建的靜態化發佈系統）能夠高效的進行上線部署。

服務端項目不一樣的是使用NodeServer進行承載，前端經過AngularJS/VueJS進行功能開發，同時配合NGUI（AngularJS樣式組件庫）快速進行頁面搭建，Node端框架選用的是Express，服務的部署經過OPS（內部的運維發佈系統）完成。

人機識別服務是咱們在前端角度設計和開發的一套安全機制，它包含前端SDK和基於Node實現的驗證服務，能夠用於接口的防抓取、防止接口被第三方非法調用等場景。目前線上接入的業務平均攔截率在30%左右，接口TOP90的響應時間在9ms之內。

構建工具棧中咱們經過Yeoman開發了團隊的腳手架，開發者能夠經過腳手架快速的進行項目搭建和組件開發，經過Gulp和Webpack進行項目的構建和打包，NPM做爲團隊統一的包管理工具，Sass做爲CSS的預編譯工具提高CSS代碼的可維護性，Babel做爲ES6的編譯工具，ESLint做爲團隊的代碼檢查工具保證代碼的規範一致，而且接入了Sonar。同時藉助一些開源的自動化測試工具提高開發階段的代碼質量。

監控體系中Sentry用於線上錯誤信息的收集和監控，Perf平臺用於Web端性能數據的收集，靈犀用於業務的統計和埋點，Falcon一方面用於Server的監控報警，一方面用於業務監控和報警（好比火車票的搶票失敗率和接口調用狀況），PM25是咱們自建的一套針對NodeServer進程粒度的開源的監控報警系統，用於確保線上Node服務的穩定性。

詳細能夠查看參考資料[5]

寫在最後

美團點評這幾年業務不斷擴張發展，基礎架構團隊不斷沉澱基礎能力夯實平臺能力，各個業務團隊也是各顯神通，不斷積累框架並在公司內外部進行推廣使用。

本文重點介紹了工程化、代碼質量、跨平臺動態化、組件庫和前端框架等方面，同時也列舉了金融和酒旅團隊的前端技術體系建設狀況。但願可以讓你對於美團點評的前端技術體系有個大概的瞭解，固然這些僅僅基於公開資料整理而成，僅僅是整個技術體系的冰山一角。

最後，美團點評在大量招前端資深/專家工程師，若是有興趣近距離接觸美團點評大前端技術框架，歡迎私信給我進行內推。

參考資料

[1]Picasso開啓大前端的將來：mp.weixin.qq.com/s/lqyo7YzQ_…

[2]開源React Native組件庫beeshell 2.0發佈：mp.weixin.qq.com/s/5XgNTQdBm…

[3]用Vue.js開發微信小程序-開源框架mpvue解析：mp.weixin.qq.com/s/fY3HMV__w…

[4]美團點評金融平臺Web前端技術體系：tech.meituan.com/2018/03/16/…

[5]美團點評酒旅前端的技術體系：tech.meituan.com/2017/05/12/…

推薦閱讀

解密國內BAT等大廠前端技術體系-美團點評之上篇（長文建議收藏）

解密國內BAT等大廠前端技術體系-阿里篇（長文建議收藏）

解密國內BAT等大廠前端技術體系-百度篇（長文建議收藏）

解密國內BAT等大廠前端技術體系-騰訊篇（長文建議收藏）

解密國內BAT等大廠前端技術體系-攜程篇（長文建議收藏）

 

『奶爸碼農』從事互聯網研發工做10+年，經歷IBM、SAP、陸金所、攜程等國內外IT公司，目前在美團負責餐飲相關大前端技術團隊，按期分享關於大前端技術、投資理財、我的成長的思考與總結。