作者：禹霖

原文地址： tech.meituan.com/2018/03/16/…

背景

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

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

構建技術體系的基本原則

業務出發

1. 選型要針對業務形態特點，注重業務場景匹配度
2. 具有一定業務前瞻性（中期或中短期以避免過度設計，短期、中期、長期與迭代速度強相關）

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

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

團隊出發

1. 考慮團隊規模，成員技術特點和偏好
2. 考慮現有專案和技術遷移成本

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

以簡馭繁

我們主張使用簡單的技術手段解決複雜的問題，而不是用複雜的技術手段解決簡單的問題，例如 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 不存在此類問題而網頁存在，經過研究我們發現有以下兩個主要區別：

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

關於第一個區別大家可能存在一些困惑，這裡我們舉個例子，下圖就是 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 在跳轉前執行完渲染部分的程式碼。

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

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

我們思考這個裡面的技術瓶頸是什麼？

1. 無法在跳轉到 B 之前執行 B 的載入和渲染
2. 無法獲取 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 和構建時預渲染技術都是為首幀速度優化服務的，首幀速度優化的核心有兩點：

1. TTFB（time to first byte) 首位元組時間
2. 在首個請求的響應當中返回首幀繪製所需要的 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 實習機會，尋找實習機會的同學也可以將簡歷發到我的郵箱中。

一行程式碼，億萬生活。

• 網站首頁
• 文章存檔
• 關於我們