背景

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

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

構(gòu)建技術(shù)體系的基本原則

業(yè)務(wù)出發(fā)

選型要針對業(yè)務(wù)形態(tài)特點，注重業(yè)務(wù)場景匹配度

具有一定業(yè)務(wù)前瞻性（中期或中短期以避免過度設(shè)計，短期、中期、長期與迭代速度強相關(guān)）

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

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

團隊出發(fā)

考慮團隊規(guī)模，成員技術(shù)特點和偏好

考慮現(xiàn)有項目和技術(shù)遷移成本

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

以簡馭繁

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

標準化

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

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

自動化

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

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

現(xiàn)有復(fù)用

顧名思義就是選型上盡量使用公司已有的系統(tǒng)和工具，從而更好的與團隊、業(yè)務(wù)結(jié)合。

例如全平臺監(jiān)控工具 CAT，業(yè)務(wù)埋點工具靈犀等等。下面來看看我們技術(shù)體系的細節(jié)。

金融平臺 Web 前端技術(shù)體系

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

視圖&組件框架

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

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

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

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

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

組件庫

組件庫是前端領(lǐng)域一個重要的技術(shù)單元，為效率、質(zhì)量、體驗服務(wù)。

效率是為了能夠抽象業(yè)務(wù)研發(fā)中業(yè)務(wù)組件的共同點去避免重復(fù)勞動；質(zhì)量是如果一個組件經(jīng)過了測試和質(zhì)量迭代，那么正確的使用不應(yīng)該出現(xiàn)質(zhì)量問題；體驗方面組件庫可以去統(tǒng)一交互的體驗，讓組件的表現(xiàn)更一致。

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

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

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

Vix 的結(jié)構(gòu)分為基礎(chǔ)組件、復(fù)雜組件和業(yè)務(wù)組件三層，基礎(chǔ)組件例如輸入框、按鈕等；復(fù)雜組件包括組合搜索、日期選擇等；業(yè)務(wù)組件例如支付密碼輸入框、賬單、賬單詳情等。

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

在以往的實踐過程當(dāng)中，C端業(yè)務(wù)使用開源組件庫會和設(shè)計有很大差異，需要做大量的改造工作才能使用，然而可能還要為各種各樣改造過程中所產(chǎn)生的問題負責(zé)，同時開源組件庫的業(yè)務(wù)不相關(guān)性限制了業(yè)務(wù)產(chǎn)品的設(shè)計或?qū)崿F(xiàn)。在 Vix 中，由于標準統(tǒng)一，我們的研發(fā)效率大大提升，同時質(zhì)量也更加可控。

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

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

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

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

因此在內(nèi)部系統(tǒng)的研發(fā)上有四點要求：

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

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

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

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

在 Vue 生態(tài)實現(xiàn)的 PC 端內(nèi)部系統(tǒng)中，我們使用 Element-UI 作為組件庫，組件數(shù)量很多，質(zhì)量也很高，在 Vue 生態(tài)中是排名靠前的開源組件庫，這里不多贅述。

語言

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

• 在開發(fā)期間或編譯期間進行強類型檢查
• 使用類型系統(tǒng)讓代碼可控性、擴展性更強，協(xié)作更方便

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

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

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

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

TypeScript 包括 類型守護、聯(lián)合類型、類型推導(dǎo)、嚴格非空檢查等功能。

舉個例子如圖所示：

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

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

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

協(xié)作解耦

在日常開發(fā)當(dāng)中，前后端聯(lián)調(diào)經(jīng)常遇到一些環(huán)境問題或者接口設(shè)計的問題，導(dǎo)致前后端當(dāng)中一方等待另外一方，這種情況在效率上影響非常大。協(xié)作解耦指的就是讓前后端的研發(fā)工作不互相依賴，從而優(yōu)化研發(fā)效率。

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

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

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

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

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

在項目研發(fā)過程中，前端面向假數(shù)據(jù)開發(fā)不必擔(dān)心遇到后端環(huán)境問題；后端面向單測開發(fā)不必擔(dān)心自己跑通了前端跑不通。當(dāng)雙方都能跑通的時候進行集成聯(lián)調(diào)，這個時候前后端集成度會非常高，先完成的一方可以直接進入下一個項目，從部門角度來講，大大優(yōu)化了產(chǎn)品迭代研發(fā)的效率。

下圖表示的是優(yōu)化后的效果，可以看到前后端已經(jīng)無需互相等待了。

自動化測試

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

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

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

Hybird 體驗技術(shù)

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

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

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

• 基礎(chǔ)API：版本判斷、配置與環(huán)境判斷、獲取權(quán)限、訂閱與廣播等
• 用戶信息：獲取用戶設(shè)備信息、風(fēng)控信息、網(wǎng)絡(luò)信息、登錄及推出登錄等
• 地理位置：獲取經(jīng)緯度、城市信息、定位城市信息等
• 基礎(chǔ)業(yè)務(wù)功能：打開一個新的 WebView、關(guān)閉當(dāng)前 WebView 打開一個新的 WebView 、關(guān)閉 WebView 等
• 分享：彈出分享、分享設(shè)置、分享渠道等
• 本地存儲：存儲信息到 Native ，讀取信息等
• 多媒體：選擇圖片、預(yù)覽、上傳圖片、掃描二維碼等
• 系統(tǒng)提示：發(fā)送短信、獲取聯(lián)系人、震動、鎖屏等

業(yè)務(wù)可以在 Titans 的基礎(chǔ)上構(gòu)建豐富的 Hybrid 應(yīng)用，既能享受無需發(fā)版即可更新迭代的優(yōu)勢，又可以使用 Native 的大多數(shù)功能。

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

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

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

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

• JS/CSS 編碼或類 JS/CSS 編碼
• Virtual DOM
• JavaScriptCore / jsc.so 解析
• Native 呈現(xiàn)

由此可見行業(yè)內(nèi)解決此類問題的關(guān)鍵套路就是使用 Native 來呈現(xiàn)。

那么回到問題本身，為什么 Native 不存在此類問題而網(wǎng)頁存在，經(jīng)過研究我們發(fā)現(xiàn)有以下兩個主要區(qū)別：

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

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

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

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

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

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

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

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

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

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

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

無法在跳轉(zhuǎn)到 B 之前執(zhí)行 B 的加載和渲染

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

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

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

EH 目前所有的功能包含：

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

目前還有更多黑科技功能在逐漸增加中，上述技術(shù)當(dāng)中前三個已經(jīng)成功申請專利。

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

使用此類技術(shù)存在這么幾個問題：

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

• 技術(shù)棧捆綁：每一個技術(shù)都有捆綁的一個生態(tài)，在用 RN 的時候你必須使用 React ，在用 Weex 的時候必修使用 Vue，轉(zhuǎn)型成本同樣高，且限制了業(yè)務(wù)選型

• 解決問題被動：當(dāng)系統(tǒng)更新或技術(shù)本身出現(xiàn)質(zhì)量問題的時候，業(yè)務(wù)的研發(fā)團隊幾乎沒有能力去解決，只能等待技術(shù)官方研發(fā)團隊或開源社區(qū)去解決，這會使我們的業(yè)務(wù)很被動

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

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

SSR / 構(gòu)建時預(yù)渲染技術(shù)

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

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

事實上 SSR 和構(gòu)建時預(yù)渲染技術(shù)都是為首幀速度優(yōu)化服務(wù)的，首幀速度優(yōu)化的核心有兩點：

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

在首個請求的響應(yīng)當(dāng)中返回首幀繪制所需要的 CSS 及 DOM 結(jié)構(gòu)。

為什么說構(gòu)建時預(yù)渲染會比 SSR 快呢？

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

為什么說構(gòu)建時預(yù)渲染會比 SSR 更穩(wěn)定？

SSR 在 Nginx 層后面還需要一層 Node（典型架構(gòu)）做支撐 ，而構(gòu)建時預(yù)渲染從 Nginx 層直接返回，其關(guān)鍵鏈路上少了一環(huán)需要保障穩(wěn)定性的服務(wù)，所以穩(wěn)定性更強。

金融服務(wù)平臺在 SSR 和構(gòu)建時預(yù)渲染上都有很多項目在運行，在 SSR 的優(yōu)化上也有豐富的經(jīng)驗去保障速度和穩(wěn)定性，在選型上的考量主要是首幀對數(shù)據(jù)的依賴程度。

離線化技術(shù)

離線化技術(shù)可以將網(wǎng)頁的網(wǎng)絡(luò)加載時間變?yōu)?0，在離線化的選型上美團點評內(nèi)部有很多選擇，我們也在不同的方向進行嘗試。其中我們的選擇包括：

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

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

另外基于 Native 能力的離線化技術(shù)還存在一些來自平臺的限制，如 iOS 的 WKWebView 不支持請求攔截，而請求攔截是離線化的關(guān)鍵技術(shù)，這個原因?qū)е略?WKWebView 上無法實現(xiàn)離線化。

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

權(quán)衡離線化所帶來的巨大優(yōu)勢和 WKWebView 的速度優(yōu)勢，我們選擇繼續(xù)使用 UIWebView。（曾經(jīng)在 iOS 11 發(fā)布前業(yè)界一度認為 Apple 會在 iOS 11 中支持 WKWebView 的請求攔截）

字符級增量更新方案

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

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

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

監(jiān)控系統(tǒng)

美團點評內(nèi)部前端監(jiān)控系統(tǒng)包括：

• Sentry：異常監(jiān)控
• Performance：性能監(jiān)控
• CAT：網(wǎng)絡(luò)監(jiān)控

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

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

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

協(xié)議

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

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

安全方面

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

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

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

總結(jié)

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

效率

• 由于 Vix 和設(shè)計部門統(tǒng)一標準，在界面構(gòu)建過程中可以減少至少 80% 的時間，而這部分恰巧占整體研發(fā)時間的 60% 以上
• 聯(lián)調(diào)部分我們有 Portm 進行協(xié)作解耦，可以減少聯(lián)調(diào)時間一半以上，一般一個項目聯(lián)調(diào)部分占整體研發(fā)時間的 20% 左右
• 另外我們還有非常強大的腳手架 fe-bone ，它可以幫我們快速創(chuàng)建項目，節(jié)省創(chuàng)建項目時間 95% 以上。由于這個部分業(yè)務(wù)屬性較強，未在統(tǒng)一技術(shù)體系中提及

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

體驗

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

質(zhì)量

在質(zhì)量方面我們有：

• Lint 工具保障代碼風(fēng)格和質(zhì)量
• TypeScript 做類型檢查及類型推導(dǎo)
• Mocha 保障基礎(chǔ)工具可用性
• Freekite 保障業(yè)務(wù)流程可用性
• CAT 做異常監(jiān)控

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

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

作者簡介

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

招聘信息

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。