手機端調試利器 - 總結與實踐

一些調試工具

提及手機端調試，相比你們都不陌生。

因爲手機瀏覽器沒有像PC端瀏覽器同樣有開發調試工具，因此通常手機端的調試都要藉助於電腦，如今的調試方式一般有如下幾種。

1. 直接在chrome, firefox等開啓模擬器調試
   簡單直接，還能模擬網絡等，可是仍然沒法100%還原手機的真實狀況。

2. 實現一套pc調試面板
   採用這種實現方式有weinre，weinre很早前就比較流行了，使用也比較普遍，運行後會在PC上生成一個像chrome開發工具同樣的調試器。能對手機進行遠程調試，能操做DOM，打印console輸出等。

3. 經過與遠程服務器通訊，傳遞打印消息
   比較流行的有jsconsole，它是在遠程部署一個服務器，並生成一個具備惟一標識遠程文件給本地調用，本地嵌入該文件後，會在頁面上生成一個iframe。經過使用postMessage實現本地與遠程調試器的通訊。調試的時候能夠在遠程頁面上打印console輸出。

4. 直接將調試信息輸出在手機屏幕上
   這種實現方式的也比較多，如js-mobile-console，還有微信的vConsole。

5. 安裝各類虛擬機sdk, 在電腦上進行手機調試。

6. chrome上能夠設置遠程調試功能，手機使用數據線鏈接電腦。

優缺點分析

以上這些方法在開發中都嘗試過了，各有各的優缺點。

1. chrome模擬器最爲方便，然而模擬器和真是機器仍是常常有不少差異的，有時候模擬器運行正常，到真機上就懵逼了。

2. weinre安裝和開啓會比較繁瑣，PC和手機同時調試的時候須要關注兩個調試面板，效率不是很高。

3. jsconsole這種調試沒有提供DOM的操做，只是單純的進行log輸出，然而實際使用中須要使用到DOM操做的比較少，大部分的工做均可以經過模擬器來完成，若是手機上顯示稍有不一樣，只要更改代碼，自動刷新查看效果就能夠了，真正須要的功能是打印出手機上值。而我的認爲jsconsole的缺點就是須要跟遠程地址通訊，打印速度受到必定影響，在須要測試scroll等的輸出時會打印不及時。並且須要另外開啓一個tab查看打印信息。

4. 直接將信息輸出到屏幕上應該是最簡單粗暴的方法，可是須要在手機這麼小的屏幕上打印信息，信息會擋住操做元素不說，就是查看複雜數據結構的log也很不方便。我的認爲這種不太實用。

5. 電腦上安裝手機虛擬機就很少說了，雖能比較真實模擬手機，可是安裝繁瑣，操做不方便，沒法模擬真實的手勢操做。

6. chrome的遠程調試弊端也比較明顯，致使使用的人並很少。首先是須要鏈接數據線，其次是設置比較繁瑣，並且還限制了android手機。對於IOS的調試則可能要使用Safari的另外一套工具。

通常開發中手機的遠程調試不是強需求，除非遇到一些手機上的奇葩bug, 好比瀏覽器引擎對js的實現方式差別，須要打印真實數據，chrome模擬器均可以解決90%的問題。

可是每當遇到這種問題時，我仍是會糾結到底使用哪一個工具來作調試。緣由很簡單，我只是想把手機的信息打印到電腦瀏覽器上，不想打斷PC端的調試，不想開啓其餘附屬功能，僅此而已。所以我本身寫了一個手機端打印的命令行工具，功能和實現都比較簡單。

小而簡單的工具 m-console

m-console 靈感來自livereload，livereload的實現應該是經過WebSocket來進行瀏覽器跟本地的通訊。頁面中引入一個客戶端版本的livereload.js文件，當本地文件修改被watch進程捕獲後，會通知livereload的WebSocket服務器，服務器通知客戶端文件已更新，瀏覽器中引入的文件監聽到此次更新，則調用window.location.reload實現瀏覽器刷新。

那麼，顯然咱們能用Websocket來作遠程調試，通知手機端通知瀏覽器打印log。

原理以下：

1. 開啓一個WebSocket做爲服務端。

2. 在瀏覽器中引入一個腳本用於鏈接服務端。

3. 當判斷在手機端訪問時，重寫console方法，發送log到服務端。

4. 服務端接收到手機發來的消息，把消息廣播給全部客戶端。

5. 客戶端監聽服務端，將消息打印出來。

具體實現可查看代碼，該命令行工具備如下特色：

1. 直接將信息打印到PC瀏覽器的調試工具的console面板，沒必要開啓另外的打印頁面。

2. 支持全部console類型，支持js報錯打印。

3. 本地開啓服務器，打印速度比較快。

4. 使用簡單，只需一個命令。