Debugging is a very important process in the development process, and with the popularity of mobile terminals, mobile development is more and more, and because of the limitations of mobile terminals, debugging is much more complicated than PC. So remote debugging is very important. In recent years, browser makers have launched their own remote debugging tools, such as Opera Dragonfly from Opera Mobile, and iOS Safari, which enables remote debugging on Mac OS X using the Web inspector. Chrome for Android 4.0+ supports remote desktop debugging with the Android Debug Bridge (ADB). Chrome 32+ for desktop already supports remote mobile device page /WebView debugging without the installation of ADB. The UC browser developer version in China has also launched its own remote debugging tool RemoteInspector. In addition to browser vendors, there are also a number of third-party remote debugging tools, such as Weinre, which supports full platform debugging.

This article focuses on what remote debugging is, what the fundamentals are, what the situations are, and how to choose the appropriate and elegant way to debug for different situations.

Local debugging

Remote debugging is relative to local debugging, so understanding local debugging is important to understand remote debugging. Local debugging refers to directly debugging an APP running locally. A common one is to debug the local PC (easy). For example, I run a webpack-dev-server locally on port 8080. Then access the 8080, and open the browser developer tools, you can debug locally.

Remote debugging

Remote debugging is debugging an APP running remotely. For example, to access Google on my mobile phone, I need to upgrade the Google APP running on my mobile phone on my PC. This is called remote debugging.

There are roughly three types of remote debugging:

  • Debug remote PC (essentially a Debug server and a Debug target, in fact, the following two models are also the same, ios intermediate protocol conversion) this type of debug target is a PC, debug server is also a PC.

  • Webpage/WebView (many ways, but android 4.4 and onwards are essentially extensions of the Chrome DevTools Protocol) and the debug target of this type is the Android WebView, The DEBUG server is a PC.

  • Debug the ios Webpag/WebView (you can use the ios WebKit Debug Proxy to Debug the ios WebPag/WebView. The Debug target is an ios WebView, and the Debug server is a PC.)

Chrome Remote Debugging

When it comes to remote debugging in Chrome, you have to mention the Chrome Remote Debug Protocol. It uses Websocket to establish communication channel with the page, consisting of command and data sent to the page. Chrome developer tools is the main user of this protocol, and third-party developers can also invoke this protocol to interact with the page debugging. In short, it allows two-way communication with pages in Chrome.

Debug port is turned off by default when Chrome starts up. If you want to debug a Chrome PC browser, you can start up by passing a parameter to enable Chrome debugging:

Sudo/Applications/Google \ Chrome app/Contents/MacOS/Google \ Chrome - remote - was debugging - port = 9222 duplicated codeCopy 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" copying code}]Copy the code

Id is a unique identifier, and chrome Dev Protocol basically relies on this ID.

For example, close a page:

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

Or activating a page:

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

You can check the official information.

WebSocketDebuggerUrl is the address of the WebSocket connection that the debug page needs to use.

For example, if I need to clear the browser cache, I use webSocket to connect to the page and call send

Const ws = new WebSocket (' ws: / / 127.0.0.1:9222 / devtools/page/fefa... Ws - ffa '). The send (' {" id ": 1," method ":" Network. ClearBrowserCache ", "params" : {}} ') duplicate codeCopy the code

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

Comparison of common remote debugging frameworks

Now that we understand the types of remote debugging, we are most concerned about what we should do for different types. Before we answer that question, let’s take a look at the remote debugging frameworks on the market, what they do, and what problems they solve.

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

Behind the dotted line is the debugging framework in addition to the packet capture function, you can see that the gray part is not supported by them. At this time, you need a special package capture tool instead. Generally, specialized packet capture tools include but are not limited to request interception and modification, HTTPS support, replay and request construction, and (Web) sockets.

The principle of the packet capture tool is very simple, in essence it is a forward proxy, all requests through it, it can be recorded, even replay the construction of requests and so on.

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

Step 1: Keep your phone and PC on the same network (i.e. connected to the same Wi-Fi)

Step 2: Set the HTTP proxy for the mobile phone. Set the proxy IP address to the IP address of the PC and the port to the startup port of the proxy.

Android Proxy Settings: Set – WLAN – Hold down Select Network – Modify Network – Advanced – Proxy Settings – Manual iOS Proxy Settings: Set – WLAN – Select Network – HTTP Proxy Manual

An additional step is required for HTTPS requests:

Step 3: Mobile phone installation certificate.

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 as localhost, later IP changes, proxy Settings do not need to change, but need to connect USB, it can be said that each has its own strengths.

Remote debugging service

By using the framework mentioned above (or writing your own framework that has the basic functionality mentioned above), you can easily debug. But the reality is that most companies do debugging locally by developers. And that creates a lot of problems, like

  • If the phone is being debugged on different developer computers, you will need to install multiple certificates on one phone.
  • Developers need to configure proxy configuration files by themselves, and sharing requires manual export and import.
  • If the developer’s local IP address changes, you need to change the phone’s proxy IP address (if usb is not used for virtual host mapping)……

In view of the above problems, if you build a remote debugging service (product), then the problem can be very good to solve.

Ideally, the phone only needs to be configured once (install certificates, set up agents, etc.), and later debugging can directly view the phone’s requests as well as the console, elements, etc., and directly map to any computer for PC debugging. Easy configuration sharing between different developers (such as a common configuration for a group or company).

Take the service that builds a whistle.

Download the project and start:

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

W2 start copies the codeCopy the code

Setting the proxy:

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

X is the IP address of the deployment service. 8899 is the default port number. If the port number is changed, change it to the new port number

dashboard

Visit http://x.x.x.x:8899/ and you will see the following page:

We can view remote network requests in Network, we can view elements through its built-in Weinre, console, etc. You can see that we have configured three sets of configuration, which are the default configuration, item 1 and Item 2.

A brief description of what configuration does. The first two simply map requests locally. The third configuration intercepts the request for www.duiba.com.cn and injects one side of the 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.

Other features:

Network: mainly used to view request information, construct requests, logs printed by the page console and js errors thrown, etc

Rules: Configures operation Rules

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

Weinre: Specifies the Weinre list

HTTPS: sets whether to intercept HTTPS requests and download the Whistle root certificate

We can further install certificates to support HTTPS blocking, 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 debug server, we don’t need to configure complex environments and configurations locally, and we are flexible enough to view all requests, change requests at will, and delegate directly to the local dedicated debugging.

In fact, there are many other problems that we will encounter. It is necessary to enrich the functionality of the framework by extending it. At this time, the extensibility of the framework is important.

Debugging AIDS

In this way we have set up a debug preparation environment. But really debugging the application, finding problems, solving problems. Other information is needed to assist. Here are some debugging AIDS.

User trajectory

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

Application data

Getting enough information is very important for debugging. Data driven applications, in particular, know the data, basically can restore the scene, locate the problem.

For example, using a state management framework like Vuex or Redux, one way is to mount the central Store onto the Window. This allows us to access the global store by accessing the properties of the window. If you use other state management frameworks or home-grown state management, you can take a similar approach.

However, we can also use off-the-shelf tools such as react-dev-tools to debug the React application. For example, use redux-dev-tools to debug applications using Redux, and so on.

Other Debugging Information

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

[{front-end learning training, video tutorials, learning routes, add weixin Kaixin666Haoyun contact me}]Copy the code