vivo 前端三劍客發展歷程及原理揭秘

異地協作模式，給開發和測試間的問題溝通及定位帶來了諸多挑戰。本文從前端開發視角出發，闡述在這過程中遇到的痛點，探索解決的思路，并在過程中成功孵化出技術工具“前端三劍客”，文章深入解析了“前端三劍客”技術的實現原理及應用場景。

作者： vivo 互聯網前端團隊- Han Xuejian、Zhang Hao

異地協作模式，給開發和測試間的問題溝通及定位帶來了諸多挑戰。本文從前端開發視角出發，闡述在這過程中遇到的痛點，探索解決的思路，并在過程中成功孵化出技術工具“前端三劍客”，文章深入解析了“前端三劍客”技術的實現原理及應用場景。

1分鐘看圖掌握核心觀點??

一、背景

隨著公司業務的不斷發展，異地協作成為一種常態，距離無疑給我們的溝通帶來了很多不便，尤其是給問題反饋及解決增加了更多的成本，在這過程中我們遇到了很多痛點：

痛點一：溝通效率低

開發和測試只能通過消息或者電話進行溝通，為了將問題描述清晰，雙方需要反復交流，有時還需提供錄屏、截圖以及抓包等信息，整個過程耗時長、效率低。

痛點二：復現難、定位難

經常會出現一些問題，開發在本地無法復現，需要使用特定的手機進行復現、解決。

痛點三：抓包協作難

分析問題時，經常需要抓包，但是目前主流的抓包工具都是1對1，對于異地實時抓包不是很方便，而且分享抓包內容也比較繁瑣，無法在線實時查看。

為解決這些問題，我們基于開源工具與自研技術棧，孵化出前端三劍客：

利劍一：錄制回放工具 - 讓溝通更簡單
利劍二：遠程調試工具 - 像本地調試一樣調試遠程機器
利劍三：WEB多人抓包代理工具 - 在線抓包，更簡單、更實時、更便捷

這是一套覆蓋問題復現、遠程調試、便捷抓包的一整套解決方案，助力開發人員快速、精準地分享解決問題。

二、利劍一：錄制回放工具

2.1 工具介紹

對于前端開發而言，和測試溝通問題時，問的最多的幾個問題：

你是怎么操作的？
控制臺有什么報錯嗎？
抓個包給我看下接口請求數據吧？

總結歸納起來就是以下三點：

基于以上的述求，我們基于開源框架rrweb，實現了從前臺接入管理、后臺回放管理及權限管控的一站式錄制回放平臺，接入簡單，一鍵便可錄制宿主信息、操作過程、接口信息、日志信息等數據。

錄制過程

接入錄制回放工具后，頁面會出現一個懸浮球，用于開啟和提交錄制信息，錄制完成后，會生成在線回放地址。錄制過程如下圖所示：

回放過程

錄制成功后，后臺管理系統中便能查詢到該條錄制信息，點擊回放，可以看到該問題的操作過程，以及瀏覽器信息、接口信息、日志信息等數據，如下圖所示：

整個操作的流程如下圖：

2.2 接入方式

我們提供了一個在線sdk，用戶只需引入該js文件，進行初始化即可使用：

2.3 實現原理

記錄頁面 DOM 變化

錄制過程：

在初始化時使用document.cloneNode(true) 方獲取頁面的全量 DOM 快照，之后通過 Mutation-

Observer 監聽器監控頁面的各種變化，如 DOM 的增刪改、鼠標移動、滾動以及頁面大小調整等，當這些變化發生時，會將變化信息序列化為 JSON 格式的數據并存儲起來。

回放過程：讀取記錄的 JSON 數據，解析出頁面的初始快照以及各個操作事件的時間序列，根據初始快照重建頁面的 DOM 樹，然后按照事件的時間順序逐步應用每個操作事件。

接口錄制

通過對全局XMLHttpRequest進行重寫進行接口的攔截處理。

日志錄制

通過對全局console.log進行重寫

2.4 遇到的問題

問題1：跨頁面錄制

我們是通過在index.html中引入sdk，對于單頁應用，切換路由時，錄制可以連貫的銜接上，但是當遇到多頁面的應用時，切換頁面，會重新加載sdk，這樣數據就會丟失，無法進行銜接，所以我們需要在切換頁面時將錄制數據存在本地，進入下一個頁面時，獲取這些數據進行合并，如下圖：

問題2：iframe頁面無法錄制

對于很多后臺的項目，可能存在很多iframe嵌入的子項目，如果iframe中的內容與父頁面不在同一個域下，為了能夠正常錄制iframe中的內容，需要進行跨域處理，在iframe的頁面中也嵌入sdk，并設置相應的跨域屬性，記錄數據，并通過iframe.content-

Window.postMessage來同步數據到主頁面中。

三、利劍二：遠程調試工具

3.1 工具介紹

遠程調試工具是基于開源工具chii進行二次封裝，相較于vConsole,chii讓跨設備、跨網絡的Web應用調試變得簡單便捷。通過遠程連接的方式，像本地數據線連接手機一樣，在本地的chrome Devtools中進行問題定位，實現和在chrome://inspect中一樣的設備調試效果。遠程調試工具很好的解決了開發因為本地無法復現，需要測試同學手上特定機器才能復現的問題，同時可以在遠程看到頁面實時運行的日志、接口等信息，大大提升問題定位效率。

下面是整個操作步驟：

第一步：如下圖，點擊頁面中的懸浮球，出現遠程調試按鈕，點擊可以開啟遠程調試。

第二步：在管理平臺的遠程列表中可以看到所有連接的設備。

第三步：遠程查看，點擊上一步驟中的inspect按鈕，可以進入如下調試頁面。

第四步：雙向操作同步

在手機執行操作，遠程界面同步發生變化，實時顯示請求和日志，同樣如果遠程修改樣式或者執行操作，手機端也會同步執行相同操作。

3.2 接入方式

3.3 實現原理

遠程調試工具主要包括三個部分：客戶端，中轉服務，遠程調試端(devtools)。

它們的運轉模式如下圖：

第一步：啟動一個node服務作為中轉服務器，然后創建webSocket服務用來連接客戶端和遠程調試端。

第二步：在客戶端需要調試的網頁中注入target.js 腳本，該腳本會創建 WebSocket 連接，通過訂閱發布來監聽DOM、Log、Network、Css、Storage、Debug等相關操作指令。

第三步：遠程調試界面通過CDP（Chrome DevTools Protocol）協議來和服務進行通信，當執行控制模板某項操作時，比如點擊DevTools中的“Elements”面板來檢查頁面元素，DevTools會通過CDP向服務發送一個命令，請求DOM樹信息，服務接收到這個命令后，通過渲染進程查詢具體的DOM信息，并將結果返回給DevTools，DevTools前端再將這些信息可視化呈現給開發者。

四、利劍三：WEB多人抓包代理工具

4.1 工具介紹

工作中經常需要抓包、代理等操作，主流的抓包工具有：Charles、Fiddler等，這些工具都必須安裝客戶端，且都是1對1的，對多人協助不是很友好。比如：開發需要獲取測試同學的的抓包信息分析問題時，目前都是測試同學把報文導出來，發給開發，開發再去導入到工具里面進行分析。

在此背景下，我們就在思考，能否實現一個在線的抓包、代理平臺，讓大家使用方便、分享方便，降低門檻。于是就有了這款工具的誕生，工具是基于mitmproxy進行了二次開發，容器化部署了一套在線代理服務，只需通過瀏覽器就能實現抓包、代理等操作。

該在線抓包工具具備如下優勢：

簡單： 無需安裝客戶端，有瀏覽器就能使用，易上手。
方便： 直接在瀏覽器中進行抓包，而且可通過鏈接分享給他人。
易用： 支持斷點、修改報文，集成了錄制回放工具、遠程調試工具，且支持開發、測試、線上環境任意切換。

4.2 使用簡介

設置代理

用戶可以通過手機安裝的App掃描頁面上二維碼，建立連接，也可以直接在手機WIFI代理設置中輸入固定的代理IP和端口號。

抓包、代理

代理成功后，自動跳轉到抓包頁面，頁面中會顯示當前設備，也支持新增設備，可以同時對多個設備進行抓包、代理。并且支持對報文的篡改及環境的代理。

工具注入

我們還在抓包工具中集成了上面的錄制回放工具和遠程調試工具，只需要打開開關，便會去識別入口html，動態注入工具的sdk，并進行初始化，這樣用戶再次刷新頁面時，頁面中便會出現工具的懸浮球。

環境切換

工作中還涉及到一個場景，在產品和UI驗收時，由于驗收環境都是在測試環境，需要配置host，對于產品和UI同學來講，環境的配置其實是比較陌生的，為了方便驗收，我們提供了一鍵切換環境的能力。用戶只需要在頁面上選擇自己的項目，然后開啟對應的環境，這樣手機環境便能切換過來。

4.3 實現原理

在mitmproxy基礎上，根據設備ip對攔截的請求進行分類，當用戶查看抓包數據時，通過ip進行過濾，這樣就可以只看到自己ip的抓包數據。

4.4 問題解決

4.4.1 如何實現1對N

既然是在線抓包服務，那每個人肯定都是獨立的，不能相互影響，如何讓1個代理服務支持多人操作就成了問題。

解決方案：

用戶連接代理后，代理服務器可以獲取到用戶的IP地址，根據IP地址分別進行分發及報文存儲。
前臺查詢時，終端ip地址作為入參，便只會查詢當前ip相關的抓包信息。
前臺修改報文、環境等信息時，代理服務器會根據ip分別存儲修改后的信息。

4.4.2 性能問題

多人在線抓包時，報文數據量非常大，幾十萬甚至上百萬條，而且單條報文數據量也非常的大，包括：請求頭、響應頭、響應內容等等，所以如何快速查詢及展示就成了問題。