vivo 前端三劍客發展歷程及原理揭秘
01、背景
隨著公司業務的不斷發展，異地協作成為一種常態，距離無疑給我們的溝通帶來了很多不便，尤其是給問題反饋及解決增加了更多的成本，在這過程中我們遇到了很多痛點：
痛點一：溝通效率低
開發和測試只能通過消息或者電話進行溝通，為了將問題描述清晰，雙方需要反復交流，有時還需提供錄屏、截圖以及抓包等信息，整個過程耗時長、效率低。
痛點二：復現難、定位難
經常會出現一些問題，開發在本地無法復現，需要使用特定的手機進行復現、解決。
痛點三：抓包協作難
分析問題時，經常需要抓包，但是目前主流的抓包工具都是1對1，對于異地實時抓包不是很方便，而且分享抓包內容也比較繁瑣，無法在線實時查看。
為解決這些問題，我們基于開源工具與自研技術棧，孵化出前端三劍客：
- 利劍一：錄制回放工具 - 讓溝通更簡單
- 利劍二：遠程調試工具 - 像本地調試一樣調試遠程機器
- 利劍三：WEB多人抓包代理工具 - 在線抓包，更簡單、更實時、更便捷
這是一套覆蓋問題復現、遠程調試、便捷抓包的一整套解決方案，助力開發人員快速、精準地分享解決問題。
02、利劍一：錄制回放工具
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來同步數據到主頁面中。
03、利劍二：遠程調試工具
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前端再將這些信息可視化呈現給開發者。
04、利劍三：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 性能問題
多人在線抓包時，報文數據量非常大，幾十萬甚至上百萬條，而且單條報文數據量也非常的大，包括：請求頭、響應頭、響應內容等等，所以如何快速查詢及展示就成了問題。
解決方案：
- 采用虛擬滾動列表，提升頁面流暢性。
- 優化報文結構，列表只返回固定的幾個字段，等點擊時再去查詢報文詳情。
- 優化后，即使上萬條報文也能很快返回，用戶操作也不會卡頓。
// 報文結構
[{
"id": "ccae12b0-a4f9-4379-98df-03360b6a3912",
"s": 200,
"m": "POST",
"u": "https://bbs.vivo.com.cn/",
"z": 649,
"b": 1742888674.46417,
"e": 1742888674.51759
},
...
]05、總結
整體回顧下，本文主要介紹了開發同學在項目中遇到的問題定位、溝通等痛點，通過對痛點的拆解和思考，孵化出三個在前端項目中提升效率的工具：
- 錄制回放：精準還原問題出現的場景，提供分析問題所需的必要數據（環境、日志、抓包、操作過程等），提升解決問題的效率。
- 遠程調試：遠程直連真機進行調試，快速解決特定機型的問題。
- 多人抓包：讓抓包變的更加便捷，在線即可完成，極大地提高了團隊在抓包調試工作中的協作效率。
