webkit有上千个类，在这么错综复杂的结构里看流程无疑找死，好吧，用GDB调试看吧！

      环境：webkit + Qt4.8.4 + gdb

      调试之前，当然先要生成调试版本的程序了，关于调试环境的搭建后续文章会阐述。。。。。。。

      现在就开始总结加载流程吧！

      当我们在浏览器中输入网站地址后，会通过把url赋给ResourceRequest这个类，并将ResourceRequest作为类参数传给Frameloader的load方法，ResourceRequest从头文件看貌似是关于网络协议的一系列接口封装（以后再深入了解这个类，应该可以提取出来做自己为用）。之后通过CreateDocumentLoader创建出documentloader对象（该对象负责对于请求资源动作的一系列封装，eg.请求数据，数据请求完成等动作的响应，其实就是对于下载接口的一层封装），并作为参数传给frameloader的load方法。

   在该方法中，获取之前得到的ResourceRequest对象，通过addExtraFieldsToMainResourceRequest对于ResourceRequest对象中的一些关于http的头信息的内如注册，比如Agent字段和Accept字段等（其实就是填充HTTP协议头），接着通过调用loadwithDocumentloader进行正式的下载流程。

   先来看下之前操作流程的栈信息：

注：frameloader doucmentloader 和resourceRequest这几个类之间都是你中有我我中有你的好基友，所以都可以在各自的类中分别调用到

   接着往下看，进入loadwithDocumentloader之后，获取之前的resourceRequest对象的url，并将该url对象给到KURL类中（该类又是一个对于URL的功能封装），之后通过Documentloader的startloadingMainResource方法开始加载主页面数据（一般网页就是html文件），接着创建mainresourceloader类对象（这个类看名字就知道是做什么的了）

通过调用loadnow开始进行下载工作。

   先来看下之前操作流程的栈信息：

   因为我用的是Qt的port，所以具体的下载动作由Qt来做了，接着看数据接收的操作。

   当数据下载完之后，mainresourceloader的didreceivedata负责接收下载下来的数据，把接收的数据给到Documentloader，再由Documentloader的方法commitload发布加载的内容（在这一步中，浏览器先将旧的页面清除掉在加载新的页面），之后进过很多步的转发，给到了DOM文件夹中的DecodeDataDocumentParse的appendBytes。从这开始正式进入HTML的解压和词法解析流程，这之后将对HTML内容解析工作。

   先来看下之前操作流程的栈信息：

   总结下主要流程：

1.        DocumentLoader 调用 MainResourceLoader::load 向 loader 发起请求

2.        调用 MainResourceLoader::loadNow

3.        调用 MainResourceLoader::willSendRequest

4.        调用 ResourceLoader::willSendRequest, 将 callback 通过 ResourceNotifier 传导给 FrameLoaderClient 。 Client 可以在回调中操作 ResourceRequest ，比如设置请求头部。

5.        调用 PolicyChecker::checkNavigationPolicy 过滤掉重复请求等

6.        loader 调用 ResourceHandle::create 向 Network 发起加载请求

7.        收到第一个 HTTP 响应数据包 ,Network 回调MainResourceLoader::didReceiveResponse ，主要处理 HTTP 头部。

8.        调用 PolicyChecker:: checkContentPolicy, 并最终通过 FrameLoaderClient 的dispatchDecidePolicyForMIMEType 判断是否为下载请求（存在 "Content-Disposition"http 头部）

9.        调用 MainResourceLoader::continueAfterContentPolicy ，根据ResourceResponse 检测是否发生错误。

10.   调用 ResourceLoader::didReceiveResponse ，将 callback 通过 ResourceNotifier传导给 FrameLoaderClient 。

11.   收到 HTTP 体部数据，调用 MainResourceLoader::didReceiveData

12.   调用 ResourceLoader::didReceiveData ，将 callback 通过 ResourceNotifier 传导给 FrameLoaderClient

13.   调用 MainResourceLoader::addData

14.   调用 DocumentLoader::receivedData

15.   调用 DocumentLoader::commitLoad

16.   调用 FrameLoader::commitProvisionalLoad ， FrameLoader 从 provisional 状态跃迁到 Committed 状态

17.   调用 FrameLoaderClientQt::committedLoad

18.   调用 DocumentLoader::commitData ，启动 Writer 对象来处理数据（DocumentWriter::setEncoding ， DocumentWriter::addData ）

19.   调用 DocumentWriter::addData

20.   调用 DocumentParser::appendByte

21.   调用 DecodedDataDocumentParser::appendBytes 对文本编码进行解码

22.   调用 HTMLDocumentParser::append ，进行 HTML 解析

  好了，下载加载流程就到这，下篇会带来详细的HTML词法解析和压缩流程

转载地址：Webkit学习 ----网页资源的构建加载流程

比如Chrome Net Stack(里面包含了HTTP Stack的实现)中实现了HTTP Cache, 而Android浏览器则是在HTTP Client中实现了HTTP Cache。 关于缓存，会专门在新篇中学习一下。另外在加载中的策略控制已经在第一篇中提到了，其它的还有错误处理、跳转等。

下面补充几个场景下的流程。没有做进一步的总结，只是简单将流程列出来。

1.错误控制

错误由HTTP Stack中抛出来，依次调用到CachedResource::error进行处理。这里要说明的是WebCoreResourceHandleAsDelegate本身只对应到ResourceHandle的，在错误处理调用则使用m_handle->client()的形式访问到了ResourceLoader。

2.跳转

关于跳转，实际完全在HTTP Stack中完成的，只是会在跳转前通过willSendRequest的方式通知到DocumentLoader。

3. Subframe

关于iframe,或是plugin之类的sub frame, 在加载时也是走DocumentLoader::startLoadingMainResource()的流程，不同的是它的发起者是SubframeLoader。它并不是继承自CachedResourceClient, 而是封装了一些上层的加载逻辑。

后续会根据HTTP 1.1协议中关于页面加载的定义展开一些WebKit的实现，特别是缓存的处理。

转载请注明出处: http://blog.csdn.net/horkychen

首先可以这样理解WebKit的加载逻辑，涉及三个主要的组件， 其中HTTP stack为各个平台下使用的HTTP协议模块，WebCore Loaders则依据页面加载及解析过程对加载不同HTML Element的控制，Loading Controller则具体实现了资源加载的行为控制:

虽然从WebKit整体结构上这样理解不太严谨的，但单纯站在加载的角度来看，却有利于理解加载流程。因为HTTP Stack依赖平台实现，这里从中间的Loading Controller说起。

Loading Controller提供了两个重要的接口类，一个是供WebCore调用以加载各个资源的类CachedResourceLoader, 另一个是对接HTTP模块的ResourceHandle。

1. 加载不同的资源

不同的资源的加载其差异在于数据的处理方式不同，比如主文档要提交到Document Parser里去进行解析，图片则要显示出来，但它们的网络加载流程是相同的，所以它们有不同的CachedResourceClient实现，复用了SubresourceLoader的加载流程。

下图可以看到DcoumentLoader及ScriptElement如何关联到CachedResource：

开始加载资源包含两个重要过程:一是创建CachedResource, 二是调用CachedResource::addClient注册CachedResourceClient实例。

下图是ScriptElement的加载序列图:

CachedResourceHandle可以视为CachedResource的一个封装，提供给WebCore Loaders使用。

CachedResourceHandle是一个模板类

template <class R> class CachedResourceHandle

CachedResourceLoader为不同类型的资源提供了不同的接口函数，比如Script对应的加载函数:

CachedResourceHandle<CachedScript> CachedResourceLoader::requestScript(CachedResourceRequest& request)

{

    return static_cast<CachedScript*>( requestResource(CachedResource::Script, request).get() );

}

当收到数据时，从CachedResource派生出来的子类，会通过data函数及时获得已加载的数据，再通过注册的clients完成相应的操作。

上一篇已经提到加载的发起流程，下面是收到数据后，HTTP Stack回调的过程:

  *出错时，则调用到CachedResource::error()

下图是主文档(CachedRawResource)收到数据后的处理流程(DocumentLoader就是CachedRawResource的client):

以下是CachedRawResource::data的代码片段:

if (incrementalDataLength) {

        CachedResourceClientWalker<CachedRawResourceClient> w(m_clients);

        while (CachedRawResourceClient* c = w.next())

            c->dataReceived(this, incrementalData, incrementalDataLength);

    }

2. ResourceHandle的跨平台

关于WebKit的跨平台机制，可以参考<<WebKit模块化分析>>中"兼容并蓄 - WebKit的跨平台方案"。

ResourceHandle,ResourceHandleInternal及NetworkingContext都定义在platform/network目录下. ReourceHandle针对不同平台有部分函数有不同的实现，实现的单元文件在platform/network目录下具体平台port的子目录下。

*在使用的HTTP Stack中，除curl等平台实现外，WebKit源代码还提到了SOUP, 这也是一个为GNOME应用提供HTTP支持的库，简介如下:

Soup uses GObjects and the glib main loop, and is designed to work well with Gtk/GNOME applications. This enables GNOME applications to access HTTP servers on the network in a completely asynchronous fashion, very similar to the Gtk+ programming model (a synchronous operation mode is also supported for those who want it).

转载请注明出处: http://blog.csdn.net/horkychen

本系列上一篇:

  [WebKit]WebCore之页面加载的设计与实现(一)

UML图档下载地址(GitHub):

  WebKit-Documentation

版权声明：本文为博主原创文章，未经博主允许不得转载。

之前写了几篇加载流程的说明，是从下向上看，有点只见树木不见森林的感觉。经过最近一段时间的学习，有了能加以概括抽象的方法。

WebKit加载流程和页面组成是直接相关的，页面就是WebKit要加载的对象。所以WebKit负责加载的类也与负责页面管理的类相对应。Apple关于WebView的说明里清楚表现了页面视图上的MVC结构:

一个页面从元素上也有其层次结构，并且和加载类对应，如下:

从页面元素上讲WebView代表了一个页面的呈现，对应一个Page. 一个Page包含一个或多个Frame,其中一个称为Main Frame,其它的Frame(iframe或object元素引入HTML)称为Sub Frame。每一个Frame,从JavaScript里都有一个window和document对象。

页面中的Frame,Document和子资源，对应到加载的FrameLoader, DocumentLoader和SubresourceLoader。其中Frame可以进行导航(Navigation)操作，即加载、重新加载、前进、后退操作，而Document则表示一个具体的HTML文档，没有导航操作。

从这里看到的几个Loaders都是加载的逻辑表示，实际的加载行为交给ResourceLoader(s)，即MainResourceLoader和SubresourceLoader来完成，其中包括了资源加载的队列管理操作(ResourceLoadScheduler)。

ResourceHandle在WebKit中是一个重要的port接口，与各个平台的网络层适配，代表了一个具体的网络加载任务。

主要类的关系

FrameLoader加载时序

从上面可以知道FrameLoader代表了Frame的加载行为，DocumentLoader代表了Document的加载行为。为了区分加载的进程，FrameLoader对加载状态进行了区分，并且让DocumentLoader在不同的状态间转换。除此之外FrameLoader还另外使用一个状态机，管理Frame加载显示的状态(FrameLoaderStateMachine)。

除此之此，FrameLoader还要维护历史项(HistoryController),以对应处理Navigation操作, 详细项目定义在FrameLoaderTypes.h中。

Document Loader

相对FrameLoader而言，DocumentLoader相对简单一些，它的任务就是调用一个MainResourceLoader加载主文档。因为状态的转换在FrameLoader里完成了。子资源的加载依托于DocumentLoader来管理。

子资源的加载

正如页面元素从属于Document存在一样，负责子资源的加载的类从属于Document,后来又移到了DocumentLoader类中。就形成了下面的关系:

CachedResourceLoader

至于CachedResourceLoader,其实就是一个封装类，封装了创建各类CachedResource的功能。各个需要进行加载的页面元素会继承自CachedResourceClient,创建CachedResourceRequest, 通过DocumentLoader/Document里的CachedResourceLoader发起请求。

下面是Script元素发起请求的调用:

Memory Cache/Application Cache

为了让用户有更快的应用体验，缓存机制不能少。在WebKit里CachedResource/CachedResourceLoader的命名里之所以有了Cached,就是因为它们中缓存的交互。

WebKit也有一些算法上的说明，可以参考这里。

Resource Load Scheduler

在HostInformation里存储着两个两个列表,一个是使用不同优先级数组存储的等待加载的列表，一个是正在加载的列表。

使用scheduleServePendingRequests处理排队的请求时，会按优先级依序执行。下面是基本流程:

以上就是加载流程的概要性说明,中间缺少一些流程内容，可以参考以下两个链接:
  [WebKit]WebCore之页面加载的设计与实现(二)
  [WebKit]WebCore之页面加载的设计与实现(三)

转载请注明出处: http://blog.csdn.net/horkychen