前端遠程調試

原文刊登在個人github

調試是開發過程很重要的過程，而隨着移動端的普及，移動開發也愈來愈多，而且因爲移動端的諸多限制，使得調試相對PC複雜不少。所以遠程調試就顯得很是重要了。 近幾年，瀏覽器廠商也紛紛推出本身的遠程調試工具，好比Opera Mobile 推出的Opera Dragonfly，iOS Safari 能夠開啓Web檢查器在 Mac OS X系統中實現遠程調試。Android 4.0+系統的 Chrome for Android能夠配合 ADB（Android Debug Bridge）實現桌面遠程調試，桌面版Chrome 32+已經支持免安裝ADB便可實現遠程調試移動設備頁面/WebView 。國內的UC瀏覽器開發者版也推出了本身的遠程調試工具RemoteInspector。除了瀏覽器廠商以外，也涌現出許多第三方開發的遠程調試工具，諸如支持全平臺調試的Weinre等。

本文主要介紹遠程調試是什麼，基本原理是什麼，有哪些狀況，以及如何根據不一樣的狀況選擇恰當優雅的調試方式。

本地調試

遠程調試是相對於本地調試來說的，那麼理解本地調試對於理解遠程調試是很重要的。 本地調試指的是直接調試運行在本地的APP。常見的就是調試本地PC（很簡單）。 好比我在本地運行了一個webpack-dev-server，端口號爲8080. 那麼訪問8080，而且打開瀏覽器的開發者工具，就能夠在本地進行調試了。再好比我要調試google的官網，那麼我只須要 訪問www.google.com， 一樣打開開發者工具就能夠進行本地調試了。

遠程調試

那麼遠程調試就是調試運行在遠程的APP。好比手機上訪問google，我須要在PC上調試手機上運行的google APP。 這個就叫作遠程調試。

遠程調試大概有三種類型：

• 調試遠程PC（本質上是一個debug server 和 一個debug target，其實下面兩種也是這種模型，ios中間會多一個協議轉化而已） 這種類型下的debug target就是pc, debug server 也是pc。

• 調試android webpage/webview（不少方式，但安卓4.4之後本質都是Chrome DevTools Protocol的擴展） 這種類型下的debug target就是android webview，debug server 是pc。

• 調試ios webpag/webview（可使用iOS WebKit Debug Proxy代理，而後問題便退化成上述兩種場景） 這種類型下的debug target就是ios webview， debug server 是pc。

chrome遠程調試

提到chrome的遠程調試，就不得不提chrome remote debug protocol。 它採用websocket來與頁面創建通訊通道，由發送給頁面的command和data組成。chrome的開發者工具是這個協議主要的使用者，第三方開發者也能夠調用這個協議來與頁面交互調試。簡而言之，有了它咱們就能夠和chrome中的頁面進行雙向通訊。

chrome 啓動的時候，默認是關閉了調試端口的，若是要對一個chrome PC 瀏覽器進行調試，那麼啓動的時候，能夠經過傳遞參數來開啓 Chrome 的調試開關：

sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
複製代碼

這個時候就能夠經過http://127.0.0.1:9222 查看全部遠程調試目標

http://127.0.0.1:9222/json 能夠查看特定的遠程調試目標信息，類型爲json數組。

[
  {
    "description": "",
    "devtoolsFrontendUrl": "/devtools/inspector.html?ws=127.0.0.1:9222/devtools/page/fefa.....-ffa",
    "id": "fefa.....-ffa",
    "title": "test",
    "type": "page",
    "url": "http://127.0.0.1:51004/view/:id",
    "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/page/fefa.....-ffa"
  }
]
複製代碼

其中id是一個惟一的標示，chrome dev protocol基本都依賴這個id。

好比關閉一個頁面：

http://localhost:9222/json/close/477810FF-323E-44C5-997C-89B7FAC7B158
複製代碼

再好比激活一個頁面：

http://localhost:9222/json/activate/477810FF-323E-44C5-997C-89B7FAC7B158
複製代碼

具體能夠查看官方信息。

webSocketDebuggerUrl是調試頁面須要用到的WebSocket鏈接的地址。

好比我須要清空瀏覽器緩存，就用websocket鏈接到該頁面以後調用send方法

const ws = new WebSocket('ws://127.0.0.1:9222/devtools/page/fefa.....-ffa')
ws.send('{"id": 1, "method": "Network.clearBrowserCache", "params": {}}')
複製代碼

還有不少相似的api，所以就能夠構造複雜的擴展

常見的遠程調試框架對比

明白了遠程調試的類型，那麼對於不一樣的類型應該採起什麼樣的手段是咱們最爲關心的問題。 在回答這個問題以前，咱們先來看下市面上的遠程調試框架，他們作了什麼事情，解決了什麼問題。

以下是我對比較常見的遠程調試框架的簡單對比。

後面虛線裏面的是除了抓包功能以外調試框架，能夠看出灰色部分是他們不支持的。 這時候就須要專門的抓包工具來代替。一般來講專門的抓包工具功能包括但不限於請求攔截和修改，https支持，重放和構造請求，(web)socket。

抓包工具的原理很是簡單，本質上它就是一個正向代理，全部的請求通過它，就能夠將其記錄下來，甚至能夠重放構造請求等。

對於抓包工具，步驟基本就是三部曲。

第一步：手機和PC保持在同一網絡下（好比同時連到一個Wi-Fi下）

第二步：設置手機的HTTP代理，代理IP地址設置爲PC的IP地址，端口爲代理的啓動端口。

Android設置代理步驟：設置 - WLAN - 長按選中網絡 - 修改網絡 - 高級 - 代理設置 - 手動 iOS設置代理步驟：設置 - 無線局域網 - 選中網絡 - HTTP代理手動

對於https請求須要多一步：

第三步：手機安裝證書。

對於第二步，咱們能夠經過鏈接USB的方式，而後設置端口轉發和虛擬主機映射，創建tcp鏈接，這樣就ip就能夠設置爲localhost，之後ip變更，代理設置也沒必要變更，可是卻須要鏈接USB，可謂各有千秋。

遠程調試服務

經過使用上面提到的框架(或者是本身寫的擁有上面基本功能的框架), 咱們已經能夠很方便地進行調試了。 可是事實上大多數公司都是開發者在本地進行調試。這就形成了不少問題，好比

• 若是手機在不一樣的開發者電腦調試，就須要在一個手機安裝多個證書。
• 開發者須要本身配置代理配置文件，共享須要手動導出導入相對麻煩。
• 若是開發者本地的ip發生變更，那麼就須要修改手機的代理ip(不使用usb走虛擬主機映射的狀況) ......

針對以上等問題，若是搭建一個遠程的調試服務（產品），那麼問題就能夠很好的解決。

理想的情況是，手機僅僅須要配置一次（安裝證書，設置代理等），之後調試的時候就能夠直接查看該手機的請求以及控制檯，元素等等，而且直接指定映射到任何電腦 進行pc端調試。不一樣開發者之間能夠方便的共享配置（好比有一個集團或公司的共有配置）。

拿搭建一個whistle的服務爲例。

下載項目並啓動:

npm install whistle -g --registry=https://registry.npm.taobao.org

w2 start
複製代碼

設置代理：

好比設置手機的代理爲x.x.x.x:8899

> x.x.x.x 爲部署服務的ip地址，8899爲默認端口，若修改了，則對應修改成修改後的端口號

dashboard

訪問http://x.x.x.x:8899/,會看到以下的頁面：    

   咱們能夠在network查看遠程的網絡請求，能夠經過其內置的weinre查看元素，控制檯等    能夠看到咱們配置了三套配置，分別爲默認配置，項目一和項目二。

簡單介紹下配置作了什麼。    前兩個就是簡單地將請求映射到本地。    第三條配置會攔截www.duiba.com.cn 的請求，並在html中注入一端weinre腳本。攔截成功就能夠經過訪問http://x.x.x.x:8899/weinre/client/#sword 訪問對應的開發者工具進行調試。  

  其餘功能：

Network：主要用來查看請求信息，構造請求，頁面 console 打印的日誌及拋出的js錯誤等

Rules：配置操做規則

Plugins：安裝的插件信息，及啓用或禁用插件

Weinre：設置的weinre列表

HTTPS：設置是否攔截HTTPS請求，及下載whistle根證書

咱們能夠進一步安裝證書支持https攔截，配置帳號系統，日誌映射等等, 部署一個其餘的遠程調試框架的基本思想和步驟基本是同樣的。

通過上面的步驟咱們已經獲得了一個集中式的調試服務器，咱們不須要在本地配置複雜的環境和配置了， 而且足夠靈活，咱們能夠查看全部請求，隨意更改請求，而且直接代理到本地盡心調試。

實際狀況咱們還會遇到不少其餘問題，經過擴展框架的功能豐富功能是很是有必要的，這個時候框架的擴展性就很重要了。

調試的輔助手段

經過上面的方式咱們已經創建了調試的準備環境。可是真正調試應用，發現問題，解決問題。還須要 其餘信息來輔助。下面來說解一些調試的輔助手段。

用戶軌跡

有時候咱們須要知道用戶的瀏覽軌跡，從而方便定位問題。 瀏覽軌跡的粒度能夠本身決定，能夠是組件級，也能夠是頁面級。

應用數據

獲取足夠的信息對於調試是很是重要的。尤爲是數據驅動（data driven）的應用， 知道了數據，基本上就能夠還原現場，定位問題。

好比咱們使用vuex或者redux這樣的狀態管理框架，一種方式是將中央的store掛載到window上。 這樣咱們就能夠經過訪問window的屬性獲取到全局的store。 若是使用其餘的狀態管理框架或者自制的狀態管理，也能夠採起相似的方式。

然而咱們也可使用現成的工具，好比使用react-dev-tools調試react應用。 好比使用redux-dev-tools調試使用redux的應用等等。

其餘調試信息

好比用戶的id，客戶端數據，登錄的session信息等等對於調試有所幫助的，均可以將其收集起來。

參考

https://www.jianshu.com/p/19c18c924f91

https://aotu.io/notes/2017/02/24/Mobile-debug/index.html

歡迎關注個人公衆號，不定時更新。