Debugging is a common practise for programmers, no one can say that the code he/she wrote is fine and does not need debugging.
For PC web , most of them can be debugged with Chrome + packet capture tool. But for H5, the scene is relatively complex, and there are many corresponding debugging methods.
In this post we will summarize the H5 debugging methods.
H5 debugging tools
Chrome DevTools and Web Inspector
Chrome DevTools and Max Safari Web Inpsector should be the most commonly used tools in H5 debugging. The mobile debugging functions supported by these two tools are basically similar to those on the PC side.
Steps to use Chrome DevTools:
- Connect the phone to the computer and enable USB debugging on the phone
- Visit chrome://inspect on the Chrome browser to see the page that can be debugged
- Click inspect to start debugging
- you can also use the adb tool to connect the mobile phone , and chrome inpsect will also display the connected device.
Steps to use Max Safari Web Inpsector:
- Enable development mode for Safari on Mac
- Enable Dev Mode for Safari on iOS Devices
- Connect the phone to max and debug the web page on the iOS device
These two tools should be the preferred debugging tools in H5 debugging,. However, they need to be natively enabled to support Webview debugging. Generally, after the official release of the APP, the debugging function of Webview will generally be disabled, resulting in the inability to connect to the above debugging tools. This is where other tools need to be considered.
Weinre, Chii
Such tools need to start a service locally , and then inject a piece of JS code on the debugged web page to point to this service. The entire debug panel is very similar to Chrome DevTools, providing DOM/CSS viewing and modification, JS execution, log viewing, local storage viewing, and limited network monitoring (xhr only)
Taking Wenire as an example, let’s see how such tools are used.
- Install Wenire:
npm install -g weinre - Open the server locally:
weinre --httpPort 8080 --boundHost -all- - Import JS code in the project to be debugged
- Start your debugging
Whistle, spy-debugger
The above tool needs to inject a piece of JS code on the web page, which is difficult to do for an already online site. To solve this pain point, some people in the community have developed proxy tools that integrate weinre or chii. Dynamically inject debugged JS code at proxy time to further reduce debugging costs.
Similarly, let’s look at the basic use of Whistle:
- Install Whistle:
npm install whistle -g - Start the service:
w2 start -p 8899 - Configure the mobile terminal proxy, the mobile terminal settings and the computer must be connected to a WIFI, the proxy address is the service started above
- Configure weinre rules and use weinre to debug
You can see the related JS scripts of weinre are automatically injected into your project
Proxy tool
In some specific debugging scenarios, some special processing needs to be done to the request, which requires proxy tools, such as
- Map online JS and CSS files to the local, which is convenient for bug verification
- Forge request responses and return special data to bypass specific processes or perform some boundary testing
Proxy tools typically include capabilities
- Request monitoring
- Request impersonation
- Request forwarding
- Request interception
- Response forgery
Several popular proxy tools: Fiddler, Charles, Whistle, etc.