Read the article H5 mobile development debugging skills

Since there are two types of mobile operating systems, iOS and Android, the debugging tips in this article will be divided into different systems. Look for the most appropriate and efficient way to get twice the result with half the effort.

This article lists various options available for mobile debugging, so choose your best practices.

Safari: iPhone debugger

• Browser Settings: Safari – Preferences – Advanced – Check the Show Development in Menu Bar menu

• IPhone Settings: Settings – Safari – Advanced – Open Web Inspector

With that done, open the H5 page in Safari on your phone, and we can see from the browser development options:

IOS emulator: no real machine required, suitable for debugging Webview and H5 feature pages with frequent interaction.

First, download Xcode, run the project, select the emulator iphoneX, and when compiled, the emulator will open as follows:

You can see that H5 is already running in the shell, and now you can try calling Webview methods to interact with the shell. For more debugging tips, see the article iOS Emulator Debugging.

The specific debugging functions depend on the browser development options, as above, so I won’t go into detail.

Charles: a preferred packet capture tool for The Mac OS. It is suitable for viewing and controlling network requests and analyzing data.

Charles packet capture first needs to configure the mobile agent, Wifi – configure the agent (IP address) – manual, as shown in the following figure:

When the phone agent is configured, open Charles and you will receive a confirmation notification, so select allow. And then you can capture the phone’s request, but these are normal operations, so let’s do a little bit more advanced.

Here’s the interesting thing: We can use local files to replace online files, making it easier to debug and remotely locate online problems.

Select Structure and find the file you want to replace. Right-click on the menu – Map Local, as shown below:

A popup window will open and fill in the details:

OK, you are done, quickly go to change the local file, from now on is not afraid of online debugging. Note that to capture HTTPS requests, you need to install a trust certificate, as described below.

The equivalent, Fiddler for the Windows platform, does much the same thing but won’t go into detail here.

Spy – Debugger: mobile terminal debugging sharp tool, convenient remote debugging mobile page, packet capture tool.

Let’s first install:

> sudo npm install spy-debugger -g

Start command:

> spy-debugger

At this point, the console will print the following information indicating that the service is started:

Starting agent

The IP address of the local computer on the current network is 10.200.24.46

Node-mitmproxy startup port: 9888

Open your browser –> http://127.0.0.1:50389

The last step is to set up the mobile agent: 10.200.24.46, port number: 9888. A footnote:

• To configure proxy Settings on Android, perform the following steps: – WLAN – Hold down to select the network – Modify the network – Advanced – Proxy Settings – Manual

• IOS Proxy Settings: Settings – WLAN – Select Network – HTTP proxy Manual

Next, try a packet capture:

Open the debugging page again:

The root certificate is required for HTTPS packet capture, as described in the following sections.

The above recommended a simple debugger, upgrade to the more powerful debug tool Whistle.

Whistle: Node-based cross-platform Web debugging agent.

Whistle ([ˈ k ɪsəl], pinyin [wēisǒu]) is a Node based cross-platform packet capture debugging agent with the following basic functions:

1. View HTTP and HTTPS requests and responses

2. View frame data sent and received by WebSocket and Socket

3. Set the request hosts and upstream HTTP/SOCKS proxy

4. Modify the request URL, method, header, and content

5. Modify the response status code, header, and content, and support local replacement

6. Modify frame data sent and received by WebSocket or Socket

7. Built-in Weinre and log for debugging mobile pages

8. As an HTTP proxy or reverse proxy

9. Support for writing plug-in extensions with Node

After a general understanding, let’s try to install:

sudo npm install -g whistle

Taobao mirror: NPM install whistle – g – registry=https://registry.npm.taobao.org

After the whistle is installed, run the whistle help or w2 help command to view the help information about the whistle:

run Start a front service

start Start a background service

stop Stop current background service

restart Restart current background service

help Display help information

Only a few of the commands are listed here. For more, see w2 help.

Seeing the above, why don’t we try the abbreviation w2 start to start the service:

w2 start

If the following output is displayed, the service is started normally:

Open the link in your browser, configure the proxy on your phone (same as Charles), and you can happily debug. It’s worth noting that this is far from what Whistle does. For more details, check out the documentation on whistle’s website and see a preview below:

Remember to enable HTTPS interception: select Capture HTTPS CONNECTs

For Charles, do as follows to install the certificate:

help-SSL – Proxying – install Charles root

A dialog box is displayed asking you to install the certificate.

Go to the mobile browser as prompted to open: chls.pro/ SSL, and install the trust certificate.

For spy-debugger and HTTPS packet capture, install the root certificate, select RootCA, scan the QR code, and trust the certificate as prompted. There are a few things to be aware of when installing a certificate:

1. The mobile phone must first set up the agent and then through the (non-wechat) mobile browser to http://s.xxx (address QR code) installation certificate;

2. A certificate is required for the first debugging of a mobile phone. If the certificate has been installed on a mobile phone, you do not need to install it again.

3. The phone and THE PC stay on the same network (for example, connected to a WIFI connection);

Remember: Mobile device and PC must be in the same WIFI.

A lot has been said, but in the actual development process, we don’t wait until we go live to verify compatibility, so you may need to “debug on the real machine” beforehand. Here are two ways:

Chrome Remote Devices: Relies on Chrome for Remote debugging, suitable for Android phones.

First, open developer Options for Android phones and check USB Debugging.

Then, type: Chrome ://inspect in Chrome to go to the debug page

A very comprehensive article, can refer to: Chrome remote debugging.

Localhost to IP, scan the QR code mobile phone display, this is relatively simple.

You can install a Chrome plugin in your browser that converts the current page link into a QR code, so you can preview it as you develop, which is very convenient.

Here’s a recommended debugging tool: vConsole, a lightweight, scalable, front-end developer debugging panel for the mobile web. Installation is simple:

npm install vconsole

If you are not using the AMD/CMD specification, you can introduce the vConsole module directly into your HTML. To facilitate further expansion, it is recommended to introduce in <head> :

<head>

<script src=”path/to/vconsole.min.js”></script>

<script>

var vConsole =new VConsole();

</script>

</head>

If you use the AMD/CMD specification, you can introduce the module using require() within the module:

var VConsole = require(‘path/to/vconsole.min.js’);

var vConsole = new VConsole();

Note that VConsole is only a prototype of VConsole, not an instantiated object.

So the vConsole is not inserted into the web page until manual new instantiation. The general functions are as follows:

It looks perfect, but there is a small drawback: the network request, need to refresh the page, but many embedded H5 page is not a chance to refresh the page, so need to add the refresh function of the client to facilitate debugging.

Given that there are so many options for mobile debugging, how do I choose one in practice?

Having said so many schemes, here is a summary of the applicable scenarios of each scheme, and select the best debugging scheme according to different scenarios, so as to output more quickly and Carry the whole field:

1.Safari: iPhone debugger

2. IOS emulator: no real machine is required, suitable for debugging Webview and H5 with frequent interactive functional pages;

3.Charles: The preferred packet capture tool for Mac OS. It is suitable for viewing and controlling network requests and analyzing data.

4.Fiddler: Windows platform, similar to Charles, view and control network requests, analyze data;

5. Spy-debugger: mobile terminal debugging sharp tool, convenient remote debugging mobile page, packet capture tool;

6.Whistle: Node-based cross-platform Web debugging proxy tool;

7.Chrome Remote Devices: Rely on Chrome for Remote debugging, suitable for Android phone Remote debugging static page;

8. Localhost to IP: real machine debugging, suitable for remote debugging static pages;

9. VConsole: built into the project, print mobile terminal logs, view network requests, and view cookies and Storage;

Mobile terminal white screen is the most troublesome problem, here by the way to provide several analysis of the problem, for reference.

When something goes wrong online, the easiest thing to think about is whether the new code caused the problem. So the effective solution is the “control variable method”.

Strange white screen, suitable for the page no exception log, no request to send at the same time, the problem is concentrated in a single page. This kind of problem is straightforward. It must be a code exception or an invalid return on a page that causes the page rendering to terminate, but it is not an exception. In this case, “code comment” is your best choice, commenting the code line by line until the problem is identified.

This scenario is often encountered, and we need to use a way to debug the page exception, such as Safari, Spy-Debugger, Whistle, vConsole to view the exception log to quickly locate the class library and find a replacement or compatibility solution.

If your project doesn’t have exception monitoring, Try and Catch suspicious snippets of code.

The most effective way to do this is to install the vConsole in your project and use it with the client debug plugin to monitor all exceptions in 360 degrees.

Generally, we compile ES6 with Babel, but additional third-party libraries that have incompatible syntax can cause exceptions on older mobile devices. So, use the debugging methods described above, identify exceptions, and then add a Polyfill for compatibility.

That’s all for today’s share, thank you!

Editor: IT big coffee says, reprint please indicate copyright and source