The original:
Imnerd.org/webview-deb…
WebView is a client-side browser control that implements the logic of loading and rendering web pages. But this control is not exactly the same as the browser, and some of the behavior of our page depends on the interaction of the client, so we need to debug it in the WebView environment. Now I will talk about a simple WebView debugging method.
caught
Packet capture means we look at all the network requests in the WebView, which is useful in many cases where the machine is not available. The abnormal page behavior is usually caused by the incorrect parameters of the interface request or the abnormal data returned by the interface. Even the page behavior has a dot, according to the dot request to determine whether the behavior is normal. Through this “look, hear, ask” approach, some questions can surface. There are a lot of package grabber programs out there, like Fiddler on Windows, Charles on Mac, and a few others I won’t mention here. However, many of the principles of the software are the same, in simple terms, HTTP proxy is used to forward all requests to the software to record the relevant data of the HTTP request.
First, we need to ensure that the mobile phone and the PC are on the same LAN, and Enable Proxy configuration in the software. In this case, Charles is used as an example. Then set the HTTP proxy IP to your computer’S IP address and port to the one configured in the software just now (default: 8888). After configuration, you can see the request flow in the software if there are no problems. We can view the request and response messages in detail like Network in Chrome Developer Tools.
Since the proxy method is essentially man-in-the-middle hijacking, it is also important to note that SSL certificates of the packet capture software need to be installed on the mobile phone if the website is using HTTPS to capture packets. Take Charles as an example. After Charles is connected, access CHLS. Pro to obtain the SSL certificate. IOS will automatically enter the installation step, most Android devices need to enter the security options in the Settings to install the certificate from SD card. After the certificate is installed, we can capture HTTPS packets normally.
debugging
When the captured data cannot locate the problem, we need to use more powerful debugging methods. The principle of this method is to obtain the ability to view and modify the output of all logs, DOM structure and style, etc. through a certain method similar to Chrome developer tools. There are many ways to implement this, depending on the environment and the client, and I’ll explain them one by one.
Android Chrome
If you need to debug Android phone version >= 4.4, it is recommended to use Chrome ://inspect for debugging, which brings native developer tools to WebView and makes it easy to debug code breakpoints. This method can be used only if it meets the following three conditions:
- The Android 4.4 +
- Enable USB connection for device debugging on mobile phone
- Enable the WebView debug mode on the client
/ / open the debug mode of the webview webview. SetWebContentsDebuggingEnabled (true);Copy the code
When the above requirements are met, visit Chrome ://inspect and the page will display a list of webViews that have debugging enabled on your device. To start debugging, click Inspect under the WebView you want to debug. Use developer tools like remote browser tabs.
Image from remote debug Webview
This method needs to be noted that some students may visit the white page for the first time, this is because the developer tool is essentially a web page, it will load Google-related resources, these resources are blocked by the mainland, need to go over the wall to solve.
iOS Safari
If you have DEBUG apps installed on your phone, it is recommended to use Safari, which brings native developer tools to WebViews and makes it easy to DEBUG code with breakpoints. This method can be used only if it meets the following three conditions:
- Mac: Safari -> Preferences -> Advanced -> Show “Development” menu in the menu bar check
- IOS: Settings -> Safari -> Advanced -> Web Inspector opens
- The most important thing is that the App must be in DEBUG mode
Due to the signature verification mechanism of iOS, Safari Debug is not allowed in the real machine official package. Therefore, the package installed on the real machine must be the package with the test signature. We need to contact the client to write the ID of our iOS device into the list of trusted devices, and then use iTunes to install the test package provided by the client. When the above requirements are met, you can view the device and the web page in the WebView in Safari -> development. After clicking on the Inspector, you can open the corresponding page for breakpoint debugging.
The image comes from debugging the WebView using Safari
weinre
If the above methods are unavailable due to the system version or the debug mode is not enabled, use weinre. Weinre sends all of the page’s behavior to the service by inserting a script into the page. First we need to install and start the service:
npm install -g weinre
weinre --httpPort 8000
Copy the code
Images from remote debugging mobile web pages with Weinre
Visit http://localhost:8000 and insert the debug script into the page as prompted. After visiting the page, you will find the corresponding request record appears in the Winere page. Click this record to jump to the following page. This is a web version of the developer tool, you can easily view network requests, console execution code and style changes, etc. However, due to the principle, breakpoint debugging is not available.
Images from remote debugging mobile web pages with Weinre
eruda
If starting the service is not convenient, you can also use methods such as ERUDA. Similar to the Weinre method, this method inserts a JAVASCRIPT script into the page and outputs all the data to a mini-developer tool within the page. There are many similar tools on the market, but the methods are similar. Here is an example of Eruda. After inserting the script into the page, click the tool button in the page to pop up mini DevTool on the current page, and you can see all the requests and logs.
Wechat WebView debugging
Because the demand for viewing web pages in wechat is particularly large, the debugging methods of wechat WebView are listed separately here. Normally, you can use wechat developer tools to debug web pages and wechat on the computer side. When this situation cannot be met and you need to troubleshoot problems on the real phone, you need to use TBS Studio developed by Tencent X5 for debugging. It is essentially similar to the Chrome ://inspect method, except that it provides debug mode for online wechat packages and simplifies operations. The use of specific methods can refer to the official document: x5.tencent.com/tbs/guide/d…
conclusion
At present, the common WebView debugging methods on the market are about these, and some are based on the integration and evolution of the above methods. If chrome://inspect and Safari can be used, this is undoubtedly the best solution, but the other several are not without use scenarios, you can choose the corresponding debugging mode according to your own needs.
In addition, sometimes we cannot use all of the above methods in the user’s environment, and the problem is not easy to troubleshoot, we can consider recording the page HTML after user interaction and send it to the server for debugging according to the situation of the HTML page. Because the user can perceive the abnormal will be shown in HTML, users can also obtain the user interaction logic by recording the user, and it is convenient for us to troubleshoot the problem by replaying the user behavior.
Read more:
- Remote Debugging WebView
- Weinre Primer
- Mobile Terminal Development and Debugging