美團點評金融平台Web前端技術體系

背景

随着美團點評金融業務的高速發展，前端研發數量從 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 / 建構時預渲染技術

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 做異常監控

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

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