分类： LINUX
2013-09-06 10:18:41
Before WebKit can render a web page, it needs to load the page and all of its subresources from the network. There are many layers involved in loading resources from the web. In this post, I’ll focus on explaining how WebCore, the main rendering component of WebKit, is involved in the loading process.
WebKit contains two loading pipelines, one for loading documents into frames and another for loading the subresources (such as images and scripts). The diagram below summarizes the major objects involved in the two pipelines:
The FrameLoader is in charge of loading documents into Frames. Whenever you click a link, the FrameLoader begins by creating a new DocumentLoader object in the “policy” state, where it awaits a decision by the WebKit client about how it should handle this load. Typically, the client will instruct the FrameLoader to treat the load as a navigation (instead of blocking the load, for example).
Once the client instructs the FrameLoader to treat the load as a navigation, the FrameLoader advances the DocumentLoader to the “provisional” state, which kicks off a network request and waits to determine whether the network request will result in a download or a new document.
The DocumentLoader, in turn, creates a MainResourceLoader, whose job is to interact with the platform’s network library via the ResourceHandle interface. Separating the MainResourceLoader from DocumentLoader serves two purposes: (1) the MainResourceLoader insulates the DocumentLoader from details of handling the callbacks from the ResourceHandle and (2) the lifetime of the MainResourceLoader is decoupled from the lifetime of the DocumentLoader (which is tied to the Document).
Once the loading system has received sufficient information from the network to determine that the resource actually represents a document, the FrameLoader advances the DocumentLoader to the “committed” state, which transitions the Frame to displaying the new document.
Of course, displaying a web page requires more than just the HTML that comprises the document. We also need to load the images, scripts, and other subresources referenced by the document. The DocLoader is in charge of loading these subresources. (Note that although DocumentLoader and DocLoader have similar names, their roles are quite different.)
Let’s take loading an image as a typical example. To load an image, the DocLoader first asks the Cache whether it already has a copy of the image in memory (as a CachedImage object). If the image is already in the Cache, the DocLoader can respond immediately with the image. For even greater efficiency, the Cache often keeps the decoded image in video memory so that WebKit does not have to uncompress the same image twice.
If the image is not in the Cache, the Cache creates a new CachedImage object to represent the image. The CachedImage object asks the “Loader” object to kick off a network request, which the Loader does by creating a SubresourceLoader. The SubresourceLoader plays a similar role in the subresource loading pipeline as the MainResourceLoader does in the main resource loading pipeline in that it interacts most directly with the ResourceHandle interface to the platform.
There are many areas in which we can improve WebKit’s loading pipelines. The FrameLoader is significantly more complex than necessary and encompasses more tasks than simply loading a frame. For example, FrameLoader has a several subtly different methods named “load,” which can be confusing, and is responsible for creating new windows, which seems only tangentially related to loading a frame. Also, the various stages of the loading pipeline are more tightly coupled than necessary and there are a number of “layering” violations in which a lower-level object interacts directly with a higher-level object. For example, the MainResourceLoader delivers bytes received from the network directly to FrameLoader instead of delivering them to DocumentLoader.
If you study the diagram above, you will notice that the Cache is used only for subresources. In particular, main resource loads do not get the benefits of WebKit’s memory cache. If we can unify these two loading pipelines, we might be able to improve the performance of main resource loads. Over time, we hope to improve the performance of the loader to make loading web pages as fast as possible.
From: http://webkit.org/blog/1188/how-webkit-loads-a-web-page/
