背景

隨著美團點評金融業務的高速發展，前端研發數量從 2015 年的 1 個人，擴張到了現在橫跨北上兩地 8 個事業部的將近 150 人。業務新，團隊新，前端領域框架技術又層出不窮，各個業務的研發團隊在技術選擇上沒有明確的指導意見，致使業務與業務之間的技術差異越來越大，在技術工具研發上無法共建，在資源調度上成本也很高。

2017年下半年，金融平臺發起了技術棧統一行動，行動分為后端、iOS、Android及前端等四個方向，在前端方向我作為組織者和參與者與金融平臺 8 個事業部的前端技術代表進行討論。 通過對各方意見進行歸納整理，結合各團隊的情況，金融平臺對于技術棧的選型達成了共識。本文將介紹美團點評金融平臺前端的技術選型以及背后的思考。先從一些基本原則講起。

構建技術體系的基本原則

業務出發

選型要針對業務形態特點，注重業務場景匹配度

具有一定業務前瞻性（中期或中短期以避免過度設計，短期、中期、長期與迭代速度強相關）

金融業務的移動端項目占比超過 70%，尤其是 Hybrid 項目，團隊在整個移動端生態的設計上投入了大量的精力，例如 Vue 的選擇、EH 的設計、組件庫 Vix 的設計等。

同時由于業務的金融屬性，對于可用性的要求非常高。在可用性保障上我們還會有一些側重，例如 TypeScript 的使用，自動化流程測試框架 Freekite 的使用等。

團隊出發

考慮團隊規模，成員技術特點和偏好

考慮現有項目和技術遷移成本

金融大多數團隊都處于初創時期，因此團隊歷史包袱相對較少，接受新鮮事物的能力強，但快速搭建團隊中也會對技術棧有上手成本的要求。在整個技術體系的搭建當中，我們會優先考慮那些新的、上手成本低的技術。

以簡馭繁

我們主張使用簡單的技術手段解決復雜的問題，而不是用復雜的技術手段解決簡單的問題，例如 Hybrid 體驗問題的解決，常規的有 RN、Weex 等方案，在業界有豐富的實踐，但我們也會設計實現更簡單的解決方案 EH，讓問題的解決變得更聚焦于問題的本質。在首屏渲染速度優化方案上的選擇也是一樣，業界有很好的 SSR 技術，但我們也會實踐研發構建時預渲染技術，讓 TTFB（首字節時間）更快，讓系統流量負載更高，同時減少關鍵環節，讓整個系統可用性更強。

標準化

標準化指的就是盡可能讓上下游銜接形成標準，并在標準下構建效率和質量工具。

例如在組件庫 Vix 的研發上，我們與 UED 形成一致的、強同步的標準，從而大大減少界面搭建的時間消耗。后面會詳細介紹。

自動化

用技術去連接技術，用技術去簡化步驟，解決某個工具到使用者的“最后一公里”問題。

例如我們使用的自動化流程測試工具 Freekite，不用一行代碼即可以完成復雜的分支邏輯自動化測試與持續集成。我們使用的聯調平臺 Portm 可以將接口設計和前端 Mock 、后端單測、接口文檔有機的結合起來，將前后端的研發進度解耦，從而大大提升研發效率。

現有復用

顧名思義就是選型上盡量使用公司已有的系統和工具，從而更好的與團隊、業務結合。

例如全平臺監控工具 CAT，業務埋點工具靈犀等等。下面來看看我們技術體系的細節。

金融平臺 Web 前端技術體系

我們將從開發階段開始介紹，從視圖層、語言層、協作層，再到質量保障工具、體驗優化工具、安全技術等。接下來過渡到編譯部署階段，講一講編譯部署和上線工具。然后是線上監控和埋點工具。最后介紹一些各個團隊正在探索和實踐當中的技術。

視圖&組件框架

在移動端使用 Vue 生態，在桌面版上我們使用 React 生態 或者 Vue 生態。

Vue 的使用主要考慮以下幾點：

• 體積小，復雜度低
  • 業務上移動端項目占比 70% 以上，Vue 的體積小，網絡性能角度相比 React 更適合移動端
  • 移動端一般巨型項目很少，從代碼結構上來講，使用 Vue 實現更符合我們的場景復雜度，React 更適合大型相對更復雜的 SPA
• 上手成本和遷移成本低
  • Vue 的學習和上手成本相對更低，團隊成員對于 Vue 的認可度和熱情也比較高
• 組件內雙向綁定、數據依賴收集
  • 組件內支持雙向綁定，更方便的去進行組件內的數據響應與交互
  • 獨有的數據依賴收集模式使其默認的數據響應和渲染效率都要比 React 高一些

React 的使用主要考慮以下原因：

• 有一部分現有后臺項目采用 React 技術棧，迭代和維護較少，老的項目如果沒有足夠的遷移價值則不額外投入資源
• 保留很小的一部分 React 技術生態也可以一定程度上保持一些技術多樣性

組件庫

組件庫是前端領域一個重要的技術單元，為效率、質量、體驗服務。

效率是為了能夠抽象業務研發中業務組件的共同點去避免重復勞動；質量是如果一個組件經過了測試和質量迭代，那么正確的使用不應該出現質量問題；體驗方面組件庫可以去統一交互的體驗，讓組件的表現更一致。

上述三點中，組件庫貢獻最大的是效率。

談到組件庫如何對效率做貢獻，首先想到的是什么樣的組件庫才能夠盡可能的提升我們的研發效率，我認為這里我們需要注意的一點是“控制變量”，因為變化產生了額外的工作量和時間成本，如果這個產品和上個產品完全一樣，我們直接復制一份就好了，沒必要開發。在我們的前端業務研發當中，變量是什么？是交互和視覺設計，每個產品之間有不同，也有相同。我們控制變量就應該去控制設計。因此我們與金融 UED（設計部門） 溝通制定了一個視覺組件標準，共同創建了視覺組件庫：Vix。

Vix 是一個移動端組件庫，其特點是完全遵守與金融 UED 制定的視覺組件標準并保持同步，在 UED 側有完善的新組件設計提審及審核流程，在業務前端研發側有強同步的約束。

Vix 的結構分為基礎組件、復雜組件和業務組件三層，基礎組件例如輸入框、按鈕等；復雜組件包括組合搜索、日期選擇等；業務組件例如支付密碼輸入框、賬單、賬單詳情等。

再上升一層則是一些包含后端服務的前后端組件，我們稱為“微服務”，是一種更高層次的業務服務抽象，在更高的維度優化效率和服務體驗一致性，例如支付密碼驗證服務，找回支付密碼服務等。Vix 包含的是前三層，其結構如下圖：

在以往的實踐過程當中，C端業務使用開源組件庫會和設計有很大差異，需要做大量的改造工作才能使用，然而可能還要為各種各樣改造過程中所產生的問題負責，同時開源組件庫的業務不相關性限制了業務產品的設計或實現。在 Vix 中，由于標準統一，我們的研發效率大大提升，同時質量也更加可控。

大多數移動端產品研發過程中至少 40% 以上的精力是在做界面的繪制。有了 Vix 后我們達到了：

• 效率大大提升：在界面繪制上相比沒有組件庫至少能夠減少 90% 的工作量
• 直接組裝無需改動：一個新產品沒有新組件出現的情況下，我們甚至可以使用交互稿直接開發而不需要等待視覺稿，因為視覺稿即使畫出來也是使用視覺組件庫去實現的樣子，極大的減少了項目研發的時間成本
• 標準更新僅需升級版本：當視覺標準更新的時候例如列表頁兩邊的邊距減小了，各個業務線的產品只需要重新發布一下就能夠展示成最新的標準，極大的減少了標準更新時所需的時間成本

PC 端面向用戶和商戶的大多都是較為獨立的產品，標準化的意義并不大，前端在 PC 端的研發精力主要投入在內部系統上，在內部系統前端研發上有四個特點：

• 無產品，要求高：幾乎沒有產品經理跟進，以完成功能需求為主，但功能流程一定要完善，最好能支持手機端使用
• 無設計：幾乎沒有設計跟進，面對內部用戶設計收益不高
• 無測試：幾乎沒有測試跟進，收益不高，功能驗證通過即可
• 要快：大多數是配合用戶端產品的管理系統迭代，也可能是新系統的搭建，對研發速度都有要求，往往這方面的估時較短

因此在內部系統的研發上有四點要求：

• 組件設計合理，組件數量大而全，最好支持移動端使用
• 組件庫本身要有不錯的設計，用戶量雖少，但活躍度超高，界面體驗需要保障
• 組件庫本身的質量要高，要從工具層面保障質量減少出錯
• 組件庫要能夠快速拼裝出功能

PC 端組件庫由于設計沒有要求，不存在來自設計的“變量”，所以選擇很多。

React Cells 也是美團點評內部的一個組件庫，金融在使用 React 生態的后臺系統研發中使用 React Cells 作為組件庫，其具有如下幾個特點可以滿足我們的需求：

• 無狀態化的組件設計
• 主題可定制
• 跨平臺（PC、Mobile）
• 搭積木式的使用方式
• 內部組件庫專人快速支持

在 Vue 生態實現的 PC 端內部系統中，我們使用 Element-UI 作為組件庫，組件數量很多，質量也很高，在 Vue 生態中是排名靠前的開源組件庫，這里不多贅述。

語言

針對ES6，本文不再進行過多闡述。對于 TypeScript 的使用是從2015年底開始，當時我們的移動端 Web 版收銀臺要做質量和可用性保障（詳情參考之前的文章《前端可用性保障實踐》），在 JS 層面我們遇到的最多的運行時問題就是 something is undefined，也就是空指針問題。另外就是由于銀行卡支付過程的業務邏輯非常復雜，代碼層面可控性差，擴展性也很差。這時候想到的就是使用強類型語言來管理我們的項目，強類型語言可以幫助我們做兩個事情：

• 在開發期間或編譯期間進行強類型檢查
• 使用類型系統讓代碼可控性、擴展性更強，協作更方便

當時我們面臨兩個選擇，一個是微軟的 TypeScript ，一個是 Facebook 的 Flow。選擇 TypeScript 是因為以下幾點：

• RoadMap 清晰，方向以貼合 ECMAScript 為核心，在其之上構建類型系統，傳言 ES8 也會增加類型系統
• TypeScript 是 JavaScript 的超集，其作用只在開發階段發揮，其生成的代碼不包含任何類型代碼，但由類型系統保障
• IDE 支持極好，除了自家的 VSCode 集成度超高，用戶增長飛速，TypeScript 還支持市面上幾乎所有主流 IDE
• 社區龐大，周邊工具豐富
• 當時已經有幾個大型的開源項目在使用，例如 Angular 和 Express
• 研發團隊活力和積極性都很高，很多開源生態均快速推進集成

而不選擇 Flow 的原因主要包括以下幾點：

• 當時 Flow 還是以注釋為主，單文件非強制型編碼，導致其類型檢查系統無法發揮最大效用，也無法全面保障質量。后來 Flow 也改成了 TypeScript 類似的方式，但個人認為為時已晚
• 集成度不高，IDE 支持落后
• 當時社區很小，除了 Facebook 自家的項目在使用，大型的開源項目用戶很少

TypeScript 包括 類型守護、聯合類型、類型推導、嚴格非空檢查等功能。

舉個例子如圖所示：

參數 s 是可能為空的，在 TypeScript 里，如果不做非空檢查就會報錯，做了非空檢查通過 TypeScript 的類型推導就能夠通過。

通過使用 TypeScript 我們可以找出前端項目中 99% 的引用問題，由于我們的整個前端框架全部支持 TypeScript，有效的避免了空指針這種運行時低級錯誤的存在。

在 TypeScript 的使用上金融支付也是公司第一個在線上使用 TypeScript 的業務線，2015年底我們還制定了 TypeScript 代碼規范。

協作解耦

在日常開發當中，前后端聯調經常遇到一些環境問題或者接口設計的問題，導致前后端當中一方等待另外一方，這種情況在效率上影響非常大。協作解耦指的就是讓前后端的研發工作不互相依賴，從而優化研發效率。

上圖表示的就是協作耦合所造成的效率問題，字母 A 代表項目 A，在前后端研發過程中，前端可能因為后端問題而無法繼續開發，反之亦然。

2015年的時候我還在技術工程部，那個時候組內同學一起想到了一個方法去解決這個問題。最初的想法就是“我們能不能通過接口設計一方面生成提供給前端研發使用的假數據，另一方面生成后端的單測。”

這個想法最終落地就是 **Vane **這個工具，現在叫 Portm。

它可以在一個項目的接口設計時切入，前后端使用這個平臺進行接口設計，同時寫入各種邏輯 Case 的輸入輸出，它可以直接生成三個東西：

• 標準化的接口文檔
• 提供給前端使用的標準化假數據
• 提供給后端使用的單測

在項目研發過程中，前端面向假數據開發不必擔心遇到后端環境問題；后端面向單測開發不必擔心自己跑通了前端跑不通。當雙方都能跑通的時候進行集成聯調，這個時候前后端集成度會非常高，先完成的一方可以直接進入下一個項目，從部門角度來講，大大優化了產品迭代研發的效率。

下圖表示的是優化后的效果，可以看到前后端已經無需互相等待了。

自動化測試

針對自動化測試，美團點評開發了一款工具叫 Freekite ，它的作用是從用戶使用角度驗證界面業務流程的正確性，解決了為實現模擬用戶點擊而帶來的諸多問題及 Case 管理的復雜度問題。

Web自動化流程測試除了可以驗證 Case 的正確性以外，最重要的功能就是要有一個異常強大的 Case 管理模塊。業界目前并沒有理想的工具能夠支撐我們的場景。“Freekite” 在 Case 驗證功能的基礎上，有一個強大的可視化 Case 管理模塊，支持復雜的 Case 細分。除了界面操作的細分外，可以全量 Mock 或部分 Mock 后端的數據響應，根據響應拆分出不同的 Case 分支。除此之外，還包含智能自動化斷言功能，斷言基本不需要人工參與。

Case 錄完以后遇到界面改版的情況不好處理，Freekite 還支持單獨節點的重新錄制，也就完美的解決了 Case 的維護問題，大幅度減少工作量優化效率。緊接著我們會在項目中增加 Freekite 的持續集成，在項目的每一個階段進行流程上的自動化回歸驗證，業務邏輯覆蓋率的問題就基本解決了。下圖為 Freekite 可視化 Case 管理的一個應用示例。

Hybird 體驗技術

不同的角度對用戶體驗有不同的分拆方法，從前端角度講，我把用戶體驗分為以下兩個方向：

前端主要在“交互體驗” 中的功能體驗和界面體驗上尋求優化。

Titans 是美團點評解決 Hybrid 功能體驗的一個集團范圍的解決方案，它為 Hybrid 模式的產品封裝 Native 的能力供 Web 調用，其能力包括幾個大的方向：

• 基礎API：版本判斷、配置與環境判斷、獲取權限、訂閱與廣播等
• 用戶信息：獲取用戶設備信息、風控信息、網絡信息、登錄及推出登錄等
• 地理位置：獲取經緯度、城市信息、定位城市信息等
• 基礎業務功能：打開一個新的 WebView、關閉當前 WebView 打開一個新的 WebView 、關閉 WebView 等
• 分享：彈出分享、分享設置、分享渠道等
• 本地存儲：存儲信息到 Native ，讀取信息等
• 多媒體：選擇圖片、預覽、上傳圖片、掃描二維碼等
• 系統提示：發送短信、獲取聯系人、震動、鎖屏等

業務可以在 Titans 的基礎上構建豐富的 Hybrid 應用，既能享受無需發版即可更新迭代的優勢，又可以使用 Native 的大多數功能。

在解決了功能體驗后，接下來我們再說界面體驗的問題。

談到界面體驗我們不得不重新講起 Hybrid，個人認為在解決功能體驗的前提下 Hybrid 存在以下主要的優勢和劣勢：

• 優勢
  • 迭代速度快，隨時發版
  • 資源節省，減少重復開發（Android & iOS）
  • 跨平臺，可瀏覽器運行
• 劣勢
  • 加載速度慢、白屏
  • 界面體驗差，交互不一致

針對 Hybrid 的劣勢，行業內現有的解決方案有很多，典型的有 Facebook 的 React Native 和阿里的 Weex，除去其它因素，只講技術本身，它們有幾個共同點：

• JS/CSS 編碼或類 JS/CSS 編碼
• Virtual DOM
• JavaScriptCore / jsc.so 解析
• Native 呈現

由此可見行業內解決此類問題的關鍵套路就是使用 Native 來呈現。

那么回到問題本身，為什么 Native 不存在此類問題而網頁存在，經過研究我們發現有以下兩個主要區別：

Apple、Google 這類大廠在界面體驗上有深厚的研究，他們把界面體驗所需要注意的那些點做成了開發模式的約束，放到了開發過程中，使用 IDE 和框架等工具去限制和引導，從而幫助開發者把界面體驗做好。Web 是一種開放標準，它更為靈活，對界面體驗沒有嚴苛的限制，由開發者自由發揮

資源存放在本地和在遠端的加載速度區別

關于第一個區別大家可能存在一些困惑，這里我們舉個例子，下圖就是 Native 為什么沒有白屏的根本原因：

如圖所示，Native 從視圖 A 跳轉到視圖 B，當用戶點擊 A 中的按鈕觸發跳轉到 B 的動作時，B 的代碼會開始執行，只有當 B 已經加載完成后，系統才會讓 A 跳轉到 B，在 iOS 中的生命周期是 viewWillAppear，在此之前 viewDidLoad 已經執行完畢，Android 也是相似的生命周期。再加上 Native APP 的資源是本地化的，Native APP 有更多的運算資源和系統級別優化，它可以把這個加載過程時間縮短到接近瞬間。而把界面繪制和加載代碼寫到 viewWillAppear 之前是這些廠商指導我們去這樣做的，并且提供了相應的系統級別支持。這時候我們思考一個問題，如果 Native 代碼將界面繪制的代碼寫到 viewDidAppear 中會發生什么？答案是也會出現白屏。

由此可見，并不是純 Native 一定體驗好，如果你不按照廠商的指導要求做，體驗一樣不好。

當我們想清楚原因后我們就開始做了一個界面體驗技術，名字叫 Enhanced Hybrid (增強混合)，簡稱 EH。

EH 的核心是“解決 Hybrid 與 Native 體驗差異的技術瓶頸”。它包括兩個部分，第一個部分是一個 Native SDK，有目前我們積累的所有解決體驗差異技術瓶頸的功能，第二個部分是界面體驗指南，也就是如何讓我們的 Web 頁面變的界面體驗更好。

舉個例子，在剛剛的白屏例子中，我們可以看到一個重要的信息，A 跳轉到 B 的時候，當 A 中點擊執行跳轉動作時第二個界面就已經開始執行了，在 B 執行完渲染部分之前系統不會執行 A 到 B 的實際界面跳轉動作。這個操作在 Web 中是不可行的，我們無法在 Web 中讓 B 在跳轉前執行完渲染部分的代碼。

那么無白屏的前提條件是什么？

無白屏的前提條件是渲染完成，或者至少渲染到一個用戶跳轉過來有東西，不會給人突兀的感覺。

我們思考這個里面的技術瓶頸是什么？

無法在跳轉到 B 之前執行 B 的加載和渲染

無法獲取 B 的渲染完成進度

當我們想清楚這個技術瓶頸以后動手解決了這兩個問題。首先，B 的渲染完成并不是一個絕對的狀態，而是由研發自己知道自己控制的，研發可以在到達這個狀態的時候把狀態主動通知出去。第二我們費了一些周折，在兩個平臺中可以通過一些技術去控制 A 等待一個通知，再讓 B 展示出來，最終結合起來的方案如下圖所示：

單獨使用此技術會遇到在 A 等待時間長的問題，再輔以“離線化技術”便可以完美解決。（離線化技術會在后面詳細講）

EH 目前所有的功能包含：

• Open：打開無白屏 WebView
• TransPage：SPA 使用 Native 導航，讓 SPA 的視圖切換在不做任何特殊開發的情況下，具有和 Native 一樣的交互表現，例如 iOS 中的左滑后退
• TabsEntry：讓 App 底部 Tab 可以動態配置，Hybrid Tab 表現效果可以和 Native 一樣
• Modal WebView：讓 Hybrid 應用可以在當前頁打開一個彈出式的 WebView ，從而在短暫操作后可以回到原來的流程當中
• Config：讓 Hybrid 界面高度可定制化，例如分開的上下 Bounce 設置，ScrollView 的設置，導航的設置等
• ActionSheet：彈出一個 Native 的 ActionSheet 從而使其蒙層可以蓋住導航

目前還有更多黑科技功能在逐漸增加中，上述技術當中前三個已經成功申請專利。

很多人會存有疑問，為什么我們不使用 React Native 或者 Weex，而是自己做一個體驗技術？

使用此類技術存在這么幾個問題：

• 平臺化而非插件化：使用此類技術后，你的整體前端業務代碼就要全部構建在這個平臺之上，如果平臺出現問題或者架構更新，轉型成本是完全重寫一套業務代碼。而采用插件化方案，加了體驗會更好，沒有也可以降級，這樣轉型的成本會少很多

• 技術棧捆綁：每一個技術都有捆綁的一個生態，在用 RN 的時候你必須使用 React ，在用 Weex 的時候必修使用 Vue，轉型成本同樣高，且限制了業務選型

• 解決問題被動：當系統更新或技術本身出現質量問題的時候，業務的研發團隊幾乎沒有能力去解決，只能等待技術官方研發團隊或開源社區去解決，這會使我們的業務很被動

EH 本身不捆綁任何技術，即使你不使用任何的框架也可以完整使用 EH 的功能。

體驗 EH 功能可以在應用商店中下載 “美團錢包”，在首頁中點擊手機充值、生活繳費或“優惠” Tab 中的內容。

SSR / 構建時預渲染技術

Server Side Rendering 這里就不多贅述了，大家都了解。構建時預渲染技術是我們特殊研發的一個技術。它的特點是從首幀速度優化角度來講，理論上比 SSR 更快更穩定。

構建時預渲染技術主要實現方式是：在編譯完成后，啟動一個 Web Server 來運行整個網站，再開啟多個無頭瀏覽器（Headless Chrome，PhantomJS 等無頭瀏覽器技術）去請求所有項目的路由，當被請求的網頁渲染到第一個有意義的渲染時（FMP 參考 Google 的衡量體系）主動拋出一個事件，該事件由無頭瀏覽器截獲，無頭瀏覽器截獲后將此時的頁面 HTML 內容保存下來生成一個 HTML。最終發布這個 HTML。此 HTML 中包含 FMP 所需要的所有 CSS 及 DOM 結構。

事實上 SSR 和構建時預渲染技術都是為首幀速度優化服務的，首幀速度優化的核心有兩點：

TTFB（time to first byte) 首字節時間

在首個請求的響應當中返回首幀繪制所需要的 CSS 及 DOM 結構。

為什么說構建時預渲染會比 SSR 快呢？

SSR 目前前端領域主流實現方式是使用 Node 作為中間層，負責數據的獲取和界面的拼裝，其 Node 層可能后面對接著一個或多個數據來源（業務系統），它的響應速度受限于最慢的那個數據來源。而構建時預渲染劣勢是不包含數據，但優勢是其首幀事件完全不依賴任何數據來源，從 Nginx 層直接返回，響應速度更快，同時流量負載更高。

為什么說構建時預渲染會比 SSR 更穩定？

SSR 在 Nginx 層后面還需要一層 Node（典型架構）做支撐 ，而構建時預渲染從 Nginx 層直接返回，其關鍵鏈路上少了一環需要保障穩定性的服務，所以穩定性更強。

金融服務平臺在 SSR 和構建時預渲染上都有很多項目在運行，在 SSR 的優化上也有豐富的經驗去保障速度和穩定性，在選型上的考量主要是首幀對數據的依賴程度。

離線化技術

離線化技術可以將網頁的網絡加載時間變為 0，在離線化的選型上美團點評內部有很多選擇，我們也在不同的方向進行嘗試。其中我們的選擇包括：

• 標準技術：
  • Application Cache：實現上各個平臺各個瀏覽器有一些差異，即使把“無法更新的坑”踩過還是會有很多“無法離線”的坑，PASS
  • Service Workers：Service Workers 是團隊一直跟進的技術，目前在測試已經接近正式發布，只是在 iOS 上還無法大范圍使用，長期看好，暫時 PASS
• 借助 Native 能力的自有技術：
  • 美團平臺技術團隊的類 Service Workers 的被動離線化技術
  • 美團旅行技術團隊的離線包技術

留下來的只剩下兩個自有技術，這兩個技術的最大區別是，是否解決了首次加載問題？離線化方案的首次加載問題是一個很難的技術領域，我認為其最核心的問題是何時加載，提前加載會不會用戶在很長一段時間內都不會用到導致浪費流量？使用包含首次加載優化的離線化技術的項目多了會不會造成加載擁塞？是不是需要分析用戶行為數據去更精準的進行離線包的提前加載？這當中存在太多不確定性，不過我相信我們的技術團隊一定能夠想出優美的解決方案去解決這個問題。

另外基于 Native 能力的離線化技術還存在一些來自平臺的限制，如 iOS 的 WKWebView 不支持請求攔截，而請求攔截是離線化的關鍵技術，這個原因導致在 WKWebView 上無法實現離線化。

WKWebView 的優勢是：運行和渲染速度更快，與 Safari 內核一致 Apple 重點迭代跟進問題；劣勢是：啟動速度慢，無法攔截請求進而使用自有的離線化技術。

權衡離線化所帶來的巨大優勢和 WKWebView 的速度優勢，我們選擇繼續使用 UIWebView。（曾經在 iOS 11 發布前業界一度認為 Apple 會在 iOS 11 中支持 WKWebView 的請求攔截）

字符級增量更新方案

字符級增量更新方案是一個前端領域研究了很久的課題，智能支付團隊近期在這一領域有了突破性進展，這個技術方案可以通過字符級增量更新減少文件傳輸大小，節省流量、提高頁面成功率和加載速度。其中增量計算能力由美團平臺的靜態資源托管方案 Build Service 支持。主要應用在掃碼付項目上。

掃碼付項目是美團金融智能支付團隊面向 C 端消費者推出的一款 H5 融合支付類的產品，消費者在商家消費之后，可使用多種 App 進行掃碼支付，同時可對商家進行評價，支持美團、大眾點評、微信、支付寶、美團錢包等多種 App，目前業務日均 PV 千萬級。

字符級增量更新方案的詳細介紹，請參考之前的文章美團金融掃碼付靜態資源加載優化實踐。

監控系統

美團點評內部前端監控系統包括：

• Sentry：異常監控
• Performance：性能監控
• CAT：網絡監控

在技術棧統一前，我們團隊這三個監控工具在同時使用，然而監控系統上前端和后端不同的是前端對代碼尺寸有要求，接入的監控系統多會對項目的加載速度有影響。綜合多方面因素，我們在本次技術棧統一中選擇了CAT來作為我們主要的監控系統。主要是它包含前兩者的功能。

CAT（詳情可以參考《深度剖析開源分布式監控CAT》 一文）是一個美團點評的全端基礎監控組件，在后端為各業務線提供全面的監控服務和決策支持，提供系統的性能指標、健康狀況、基礎告警等功能。在前端覆蓋美團點評所有APP，提供近實時的多維數據分析、立體式監控、告警等功能。提供了近實時的多維數據分析，立體式監控功能。

CAT很大的優勢是它是一個實時系統，從數據生成到服務端處理結束是秒級別，秒級定義是 48 分鐘 40 秒時基本上能看到 48 分鐘 38 秒的數據，整體報表的統計粒度是分鐘級；第二個優勢，數據是接近全量統計，目前大約5%的高QPS 項目是采樣統計。

協議

目前我們使用的協議均為 HTTP/2，支付是金融最早使用 HTTP/2 的部門，由于支付業務的特殊性，在一開始我們就是使用的 HTTPS ，進而很早就使用上了 SPDY。

在15年 HTTP/2 標準化的時候我們直接更新集群使用上了 HTTP/2，在 SPDY 和 HTTP/2 這種具有多路復用功能的協議上我們的前端架構全部做的都是按需加載的方式，大大減小了由“減少請求數” 所帶來的流量冗余。最大化利用了 HTTP 本身的緩存機制，通過減小客戶端大小的方式大大提升了網絡加載性能。

安全方面

安全方面在前端我們使用：

• HSTS： 防 SSLStrip 攻擊的標準解決方案
• CSP： 防跨站腳本攻擊的標準解決方案

同時在核心接口上我們有一個自研的網頁請求簽名方案，來在一定程度上保障請求是從我們的客戶端中正常發出的。

總結

以上是對金融平臺前端技術體系的介紹和個人的一些思考，最后說一下采用此技術體系所達到的一些效果。

效率

• 由于 Vix 和設計部門統一標準，在界面構建過程中可以減少至少 80% 的時間，而這部分恰巧占整體研發時間的 60% 以上
• 聯調部分我們有 Portm 進行協作解耦，可以減少聯調時間一半以上，一般一個項目聯調部分占整體研發時間的 20% 左右
• 另外我們還有非常強大的腳手架 fe-bone ，它可以幫我們快速創建項目，節省創建項目時間 95% 以上。由于這個部分業務屬性較強，未在統一技術體系中提及

使用這幾項技術的一個直接感受是人效大幅提升，一個前端同學可以并行 2～4 個項目，同時對接 4～10 個后端研發。

體驗

在使用 Titans 解決功能體驗，使用 EH 解決界面體驗的情況下，加上構建時預渲染和離線化技術的加持，我們可以做出專業前端都看不出來是 Hybrid 的高體驗 Hybrid 應用。

質量

在質量方面我們有：

• Lint 工具保障代碼風格和質量
• TypeScript 做類型檢查及類型推導
• Mocha 保障基礎工具可用性
• Freekite 保障業務流程可用性
• CAT 做異常監控

在整個質量體系架構的演進過程中，其實不只是這些工具來保障質量和可用性，還會有很多流程規范去保障，在可用性保障上感興趣可以參考這篇文章：《前端可用性保障實踐》。

在這些實踐中我們很好的保障了產品的穩定運行。同時也歡迎大家在前端可用性保障上多探討。

作者簡介

• 陳禹霖，美團點評技術專家，目前負責金融平臺錢包、支付、閃付前端團隊。

招聘信息

最后，金融平臺的技術體系還是在不斷快速演進中，而前端領域也是一個快速演進的領域，我們需要更多的優秀人才加入，感興趣的小伙伴可以將簡歷發送到我所在的錢包團隊，郵箱：chenyulin02[at]meituan.com，或將簡歷投送到金融平臺（詳見：美團點評招聘官網）。同時團隊提供大量 Web 前端、Android、iOS、Java 實習機會，尋找實習機會的同學也可以將簡歷發到我的郵箱中。

總結

以上是生活随笔為你收集整理的美团点评金融平台Web前端技术体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。