Explore WebKit kernel (4) -- Inspector

Recently, WebOS's remote debugging function is implemented. The effect is the same as that of chrome for Android and safari for iOS. For details, see:

• Chrome: https://developers.google.com/chrome-developer-tools/docs/remote-debugging
• IOS: https://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/DebuggingSafarioniPhoneContent/DebuggingSafarioniPhoneContent.html

It was amazing to get started with this task for the first time. How can we achieve that external tools can control the WebKit kernel so much. Later, it was discovered that this was not difficult. The main shelf WebKit had already been set up for us. We only needed to do something inside and port the developer tool to a remote location, as chrome implemented in this way, this is also true for safari. Therefore, we should focus on figuring out the Inspector architecture of WebKit. This time, we will analyze its principles and context and discuss how to remotely debug WebKit later.

First, most of the inspectorCodeAll are under WebCore/inspector to see the relationship between its main classes:

This class picture is a bit messy. Before reading it, I will first talk about the principles of WebKit debugging. The WebKit kernel has laid the groundwork for debugging. Various messages are sent to Inspector through these tracking points in all stages of the running process, and then passed to the front-end debugging tool by inspector, in addition, Inspector exposes the interface for receiving messages, which can receive commands from external debugging tools, such as querying DOM tree information, hitting breakpoints for JS, and running console commands, what is even more valuable is that WebKit regulates these incoming and outgoing messages as a protocol, which is packaged through JSON, so as long as the Protocol is followed, third-party tools can debug WebKit by sending JSON messages.

Now, let's take a look at the figure after getting a general idea. The most important thing is that I have three categories marked with colors:

• Inspectorcontroller
• Inspectorfrontendchannel
• Inspectorinstrumentation

1) inspectorcontroller

Inspectorcontroller is the control center of an entire Inspector block. It initializes other modules and is affiliated to a page. Therefore, each page has an inspector, therefore, Inspector needs to be traced from the page. In addition, inspectorcontroller provides a very important method:

Void dispatchmessagefromfrontend (const string & message );

The external debugging tool mentioned above sends the debugging command to the WebKit kernel entry. The implementation of this function is simply to call inspectorbackenddispatcher. Dispatch. Inspectorbackenddispatcher is the facade for WebKit to receive commands. It maintains the handle corresponding to each command. These handle actually calls various inspectoragents to respond to these commands, then, the results are packaged as JSON and sent to the external debugging tool through inspectorfrontendchannel. Here we will talk about inspectoragent. inspectoragent is a group of classes. For example, inspectordomagent is the debugging agent of each core element of WebKit and the main contributor to responding to debugging instructions, each core element has an agent class, so the dom-related debugging requirements will be completed by inspectordomagent, And the JS debug requirements will be completed by inspectordebuggeragent.

2) inspectorfrontendchannel

As we can see above, inspectorfrontendchannel is the channel through which WebKit sends protocol information to the external debugging tool. This channel is mainly implemented by the debugging tool:

Bool sendmessagetofrontend (const string & message)

For example, the local developer tool can implement this method, and send the message and debugging tool page to inspectorclient, so that the debugging tool page can obtain the protocol information. For example, for remote debugging, you need to send the message over the network and receive network data in the remote debugging tool.

3) inspectorinstrumentation

Inspectorinstrumentation is the burial point mentioned in the above principles. It provides various static methods, so that the inspectorinstrumentation static methods can be called in all normal WebKit processes that require debugging. These static methods obtain the corresponding inspectoragent from the instrumentagent. These inspectoragent completes the Tracking Task and encapsulates the message as JSON data through inspectorfront, which is finally sent through inspectorfrontendchannel.

Therefore, after figuring out the above core classes, we can basically master the main context of inspector. Therefore, browsers on major mobile platforms can perform remote debugging, thanks to the elegant layout of WebKit. WebKit provides external access to several key words in and out, this allows external tools to participate in all aspects of debugging elegantly.

Next time, I will analyze the main principles of JS debugging carefully, which is also amazing.