Debugging is a very important process in the development process. With the popularity of mobile terminals, there are more and more mobile development, and due to the many limitations of mobile terminals, debugging is much more complicated than PC. Therefore, remote debugging is very important. In recent years, browser manufacturers have also launched their own remote debugging tools, such as Opera Dragonfly launched by Opera Mobile, and iOS Safari can open the Web inspector to realize remote debugging in Mac OS X system. Chrome for Android with Android 4.0+ system can cooperate with ADB (Android Debug Bridge) to realize desktop remote debugging. Desktop version of Chrome 32+ already supports remote debugging of mobile device page/WebView without installing ADB. The domestic UC browser developer version also launched its own remote debugging tool RemoteInspector. In addition to browser manufacturers, there are also many remote debugging tools developed by third parties, such as Weinre, which supports full-platform debugging.
This article mainly introduces what remote debugging is, what the basic principles are, what situations exist, and how to choose an appropriate and elegant debugging method according to different situations.
local debugging
Remote debugging is relative to local debugging, so understanding local debugging is important for understanding remote debugging. Local debugging refers to directly debugging the APP running locally. Common is to debug the local PC (very easy). For example, if I run a webpack-dev-server locally, the port number is 8080. Then I access 8080 and open the developer tools of the browser to debug locally. For another example, if I want to debug the official website of google, then I only need to visit www.google.com, and also open the developer tools to debug locally.
Remote debugging
Then remote debugging is to debug the APP running on the remote. For example, to access google on the mobile phone, I need to debug the google APP running on the mobile phone on the PC. This is called remote debugging.
There are roughly three types of remote debugging:
-
Debug a remote PC (essentially a debug server and a debug target, in fact, the following two models are also of this type, and there will be an additional protocol conversion in ios) The debug target under this type is the pc, and the debug server is also the pc.
-
Debug android webpage/webview (many ways, but Android 4.4 and later are essentially extensions of Chrome DevTools Protocol) The debug target under this type is android webview, and the debug server is pc.
-
Debug ios webpag/webview (you can use the iOS WebKit Debug Proxy proxy, and then the problem degenerates into the above two scenarios) The debug target under this type is ios webview, and the debug server is pc.
chrome remote debugging
When it comes to remote debugging of chrome , we have to mention chrome remote debug protocol . It uses websocket to establish a communication channel with the page, which consists of command and data sent to the page. Chrome's developer tools are the main users of this protocol, and third-party developers can also call this protocol to interact with the page for debugging. In short, with it we can have two-way communication with the page in chrome.
When chrome starts, the debugging port is closed by default. If you want to debug a chrome PC browser, you can turn on the debugging switch of Chrome by passing parameters when starting:
sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
At this time, you can view all remote debugging targets through http://127.0.0.1:9222
http://127.0.0.1:9222/json You can view specific remote debugging target information, the type is a json array.
[
{
"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"
}
]
The id is a unique identifier, and the chrome dev protocol basically relies on this id.
For example to close a page:
http://localhost:9222/json/close/477810FF-323E-44C5-997C-89B7FAC7B158
Another example is to activate a page:
http://localhost:9222/json/activate/477810FF-323E-44C5-997C-89B7FAC7B158
For details, please check the official information.
webSocketDebuggerUrl is the address of the WebSocket connection that the debugging page needs to use.
For example, if I need to clear the browser cache, I use websocket to connect to the page and call the send method
const ws = new WebSocket('ws://127.0.0.1:9222/devtools/page/fefa.....-ffa')
ws.send('{"id": 1, "method": "Network.clearBrowserCache", "params": {}}')
There are many similar APIs, so it is possible to construct complex extensions
Comparison of common remote debugging frameworks
After understanding the types of remote debugging, what kind of measures should be taken for different types is our most concerned issue. Before answering this question, let's take a look at the remote debugging frameworks on the market, what they do and what problems they solve.
The following is my simple comparison of the more common remote debugging frameworks.
The dotted line in the back is the debugging framework in addition to the packet capture function. It can be seen that the gray part is not supported by them. At this time, a special packet capture tool is needed to replace it. Generally speaking, specialized packet capture tool functions include but are not limited to request interception and modification, https support, replay and construction of requests, (web)socket.
The principle of the packet capture tool is very simple. In essence, it is a forward proxy. All requests can be recorded after passing through it, and can even be replayed to construct requests.
For a packet capture tool, the steps are basically a trilogy.
Step 1: Keep the phone and PC under the same network (for example, connect to a Wi-Fi at the same time)
Step 2: Set the HTTP proxy of the mobile phone, the proxy IP address is set to the IP address of the PC, and the port is the startup port of the proxy.
Android setting proxy steps: Settings - WLAN - long press to select the network - modify network - advanced - proxy settings - manual iOS setting proxy steps: settings - wireless LAN - select network - HTTP proxy manual
One more step is required for https requests:
Step 3: Install the certificate on the phone.
For the second step, we can set up port forwarding and virtual host mapping to establish a tcp connection by connecting to USB, so that the ip can be set to localhost, and the proxy settings do not need to be changed after the ip changes, but it needs to connect to the USB , each has its own merits.
aids for debugging
Through the above method, we have established the preparation environment for debugging. But really debug the application, find the problem, and solve the problem. Additional information is required to assist. Here are some debugging aids.
User track
Sometimes we need to know the user's browsing track, so as to facilitate the location of the problem. The granularity of the browsing track can be determined by yourself, either at the component level or at the page level.
application data
Getting enough information is very important for debugging. Especially for data driven applications, once you know the data, you can basically restore the scene and locate the problem.
For example, if we use a state management framework such as vuex or redux, one way is to mount the central store on the window. In this way, we can get the global store by accessing the properties of the window. A similar approach can be taken if other state management frameworks or home-made state management are used.
However, we can also use off-the-shelf tools, such as using react-dev-tools to debug react applications. For example, use redux-dev-tools to debug applications using redux, etc.
Additional debug information
For example, the user's id, client data, logged-in session information, etc. are helpful for debugging, and can be collected.
refer to
https://www.jianshu.com/p/19c18c924f91
https://aotu.io/notes/2017/02/24/Mobile-debug/index.html