Front-end remote debugging

The original article is on my Github

Debugging is a very important process in the development process, and with the popularity of mobile terminals, mobile development is also more and more, and due to the many limitations of mobile terminals, making debugging more complicated than PC. So remote debugging is very important. In recent years, browser vendors have introduced their own remote debugging tools, such as Opera Mobile’s Opera Dragonfly, and iOS Safari can enable Web checker for remote debugging on Mac OS X. The desktop version of Chrome 32+ already supports remote debugging of pages/Webviews on mobile devices without the installation of ADB. Domestic UC browser developer version also launched its own remote debugging tool RemoteInspector. In addition to browser vendors, a number of third-party remote debugging tools have emerged, such as Weinre, which supports full-platform debugging.

This article focuses on what remote debugging is, what the rationale is, what the scenarios are, and how to choose the appropriate and elegant way to debug in each case.

Local debugging

Remote debugging is relative to local debugging, so understanding local debugging is important to understanding remote debugging. Local debugging refers to the direct debugging of an APP running locally. The most common is to debug the local PC (very simple). For example, I run a webpack-dev-server locally with port 8080. Then access 8080 and open the developer tools in your browser to debug locally. For example, if I want to debug Google’s official website, I just need to visit www.google.com and open developer tools to debug locally.

Remote debugging

So remote debugging is debugging an APP that is running remotely. For example, to access Google on my phone, I need to use the Google APP running on my test phone on my 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 this case, the debug target is a PC and the debug Server is a PC.

• Webpage debugging android webpage/ WebView (many ways, but android 4.4 is essentially an extension of the Chrome DevTools Protocol) The debug server is a PC.

• Debug the ios WebPag/WebView (you can use the ios WebKit Debug Proxy, and then the problem degrades to the above two scenarios). The Debug target of this type is the ios WebView, and the Debug server is the PC.

Chrome Remote Debugging

The Chrome Remote Debug Protocol is a remote debugging protocol. It uses WebSocket to establish a communication channel with the page, consisting 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 invoke this protocol to interact with and debug pages. In short, it enables two-way communication with pages in Chrome.

If you want to debug a Chrome PC browser, you can enable chrome debugging by passing the following parameters:

sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
Copy the code

At this point, you can view all remote debugging targets at http://127.0.0.1:9222

http://127.0.0.1:9222/json to view the specific remote debugging target information, type of 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"}]Copy the code

The ID is a unique identifier, and chrome Dev Protocol basically relies on it.

For example, close a page:

http://localhost:9222/json/close/477810FF-323E-44C5-997C-89B7FAC7B158
Copy the code

Another example is to activate a page:

http://localhost:9222/json/activate/477810FF-323E-44C5-997C-89B7FAC7B158
Copy the code

You can view the official information.

The webSocketDebuggerUrl is the address of the WebSocket connection needed for the debugging page.

For example, if I need to clear the browser cache, I call the send method after connecting to the page using webSocket

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

There are many similar apis, so complex extensions can be constructed

Comparison of common remote debugging frameworks

Now that we know what types of remote debugging are available, we are most concerned about what we should do with the different types. 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.

Here is my simple comparison of the more common remote debugging frameworks.

In the dashed line at the back are the debugging frameworks other than packet capture, which you can see in gray are the ones they don’t support. At this time you need a special packet capture tool to replace. Specialized packet capture tools in general include, but are not limited to, request interception and modification, HTTPS support, replay and construct requests, and (Web) sockets.

The principle of the packet capture tool is very simple, it is essentially a forward proxy, all requests pass through it, it can record them, even replay construction requests, etc.

For packet capture tools, the steps are basically a trilogy.

Step 1: Keep your phone and PC on the same network (like connecting to one Wi-Fi at the same time)

Step 2: Set the HTTP proxy of the mobile phone, set the PROXY IP address to the IP address of the PC, and set the port to the start port of the proxy.

Android proxy Settings step: Settings – WLAN – Long press select network – Modify network – Advanced – Proxy Settings – Manual iOS proxy Settings step: Settings – WLAN – Select network – HTTP proxy manual

One more step is required for HTTPS requests:

Step 3: Install a certificate on your phone.

For the second step, we can connect USB, then set port forwarding and virtual host mapping, establish TCP connection, so that THE IP can be set to localhost, the IP change, the proxy setting does not need to change, but it needs to connect USB, each has its own characteristics.

Remote debugging service

By using the framework mentioned above (or one you wrote with the basic features above), you can easily debug. But the truth is that most companies debug locally by developers. And that creates a lot of problems, like

• If the phone is running on different developer computers, you will need to install multiple certificates on one phone.
• Developers need to configure their own agent profiles, and sharing requires manual export and import is relatively troublesome.
• If the developer’s local IP changes, then you need to change the phone’s proxy IP (not using usb virtual host mapping)……

These problems can be solved by setting up a remote debugging service (product).

Ideally, the phone would only need to be configured once (installing certificates, setting up agents, etc.), and later debugging would be able to directly view the phone’s requests, console, elements, etc., and directly specify the mapping to any computer for PC debugging. It is easy to share configurations between different developers (such as having a group or company share configurations).

Take the service that builds a whistle.

Download the project and start:

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

w2 start
Copy the code

Set up the agent:

For example, set the mobile phone proxy to X.X.X.X :8899

X is the IP address of the deployment service, and 8899 is the default port. If the port number is changed, the new port number is used

dashboard

Go to http://x.x.x.x:8899/ and you’ll see the following page:

A brief introduction to what the configuration does. The first two are simply mapping requests locally. The third configuration intercepts a request for www.duiba.com.cn and injects a Weinre script into the HTML. Intercept success can visit http://x.x.x.x:8899/weinre/client/#sword to access the corresponding developer tools for debugging.

Network: It is mainly used to view the request information, construct the request, the log printed by the page console and the JS error thrown, etc

Rules: Configures operation Rules

Plugins: Information about installed plug-ins, and enabling or disabling them

Weinre: Set the Weinre list

HTTPS: Specifies whether to intercept HTTPS requests and download the whistle root certificate

We can go further and install certificates to support HTTPS interception, configure the account system, log mapping, etc. The basic idea and steps for deploying another remote debugging framework are basically the same.

After the above steps, we have a centralized debugging server, we do not need to configure complex environment and configuration locally, and is flexible enough, we can view all requests, change requests at will, and directly proxy to the local debugging painstaking.

In fact, there are many other issues that we will encounter, and it is necessary to enrich the functionality of the framework by extending it, where the extensibility of the framework is important.

Auxiliary means of debugging

In this way we have set up the setup environment for debugging. But really debugging your app, finding problems, and fixing them. Other information is needed to assist. Here are some debugging AIDS.

User trajectory

Sometimes we need to know the user’s browsing track to locate problems. The granularity of the browsing track can be arbitrary, either at the component level or at the page level.

Application data

Getting enough information is very important for debugging. Especially data driven (data driven) applications, know the data, basically can restore the scene, locate the problem.

For example, if we use a state management framework like Vuex or Redux, one way is to mount the central Store to the window. So we can access the global store by accessing the window properties. You can take a similar approach if you use other state management frameworks or homemade state management.

However, you can also use ready-made tools such as react-dev-tools to debug the React app. Use redux-dev-tools to debug applications that use Redux.

Other Debugging Information

For example, user IDS, client data, session information logged in, etc. can be collected for debugging purposes.

reference

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

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

Welcome to follow my public number, not regular update.