随笔 - 6  文章 - 0  trackbacks - 0
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

常用链接

留言簿

随笔分类

随笔档案

文章分类

文章档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

@import url(http://www.cppblog.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

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

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

Structure

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

Loading

从页面元素上讲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)。

Loaders


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


主要类的关系

Classes


FrameLoader加载时序

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

States

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


Document Loader

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


子资源的加载

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

SubResources

CachedResourceLoader

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

States

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

ScriptElement



Memory Cache/Application Cache

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

SubResources


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


Resource Load Scheduler

Scheduler

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

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

Scheduler


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

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

@import url(http://www.cppblog.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
posted @ 2016-03-03 21:31 月下孤影| 编辑 收藏

The Standard Librarian: Sorting in the Standard Library

当 你有一个数据序列时,你最想做的操作之一就是排序。将数据排序使得它易于被人理解,而且排序是许多泛型算法的第一步--即使是计算一系列数字的和这样的微 末算法。每个编程系统都提供了几种形式的排序;标准C++运行库提供了6种!(或可能更多,这取决于你怎么数了。)他们有多么大的差异,并且什么时候你该 使用其中某一个而不是另外的那些?用泛型算法进行排序 <1">    C++标准24章有一个小节叫“Sorting and related operations”。它包含了很多对已序区间进行的操作,和三个排序用泛型算法:sort(),stable_sort(),和partial_sort()。<

前两个,sort()和stable_sort(),本质上有相同的接口:同通常的STL泛型算法一样,传入指 明了需要排序的区间的Random Access Iterator。 同样,作为可选项,你也能提供第三个参数以指明如何比较元素:第三个参数是一个functor,接受两个参数(x和y),在x应该位于y之前时返回 true。所以,举例来说,如果v是一个int的vector:

    std::sort(v.begin(), v.end());

将以升序来排序它。要改为降序,你需要提供应该不同的比较方法:

    std::sort(v.begin(), v.end(), std::greater<int>());

    注 意,我们正在以greater作为第三参数,而不是greater_equal。这很重要,它是所有STL排序算法的前提条件:比较函数必须在两个参数相 同时返回false(WQ注:参看《Effective STL》Item 21)。在某种程度上,这太武断了:看起来完全可以随便使用“<”或者“<=”这样形式的比较函数来表达一个排序算法的。然而,作出明确的选 择是必需的,并且要始终坚持这个选择。标准C++运行库选择了前者。如果你传给sort()一个对等价的参数返回true的functor,你将得到不可 预知的、完全依赖于具体实现的结果;在某些系统下,它看起来能工作,而在另外一些系统下可能导致无限循环或内存保护错误。

    对 于比较简单的场合,使用stable_sort()代替sort(),你不会看出很多差异。与sort()一样,stable_sort()对 [first, last)区间进行排序,默认是升序,并且,同样你可以提供一个比较函数以改变顺序。如果你读过C++标准,你将会看到sort()和 stable_sort()的两个不同:

l         如名字所示,stable_sort()是稳定的。如果两个元素比较结果为等价,stable_sort()不改变它们的相对顺序。

l         性能上的承诺是不同的。

第一点,稳定,比较容易懂。它对int 类型通常无所谓(一个“42”和另外一个“42”完全相同),但有时对其它数据类型就非常重要了。比如,你正对task根据优先级排序,你或许期望高优先 级的task被提到低优先级的task之前,但相同优先级的任务保持它们原来的先后顺序。sort()没有这个承诺,而stable_sort()承诺了 这一点。

    标准对性能的描述就不怎么直观了:sort()和stable_sort()的承诺都很复杂,并且都不完备。标准说sort()的“平均”复杂度是O(N log N),而没有说最坏的情况;stable_sort()的复杂度是O(N (log N)2),但在有足够额外内存时同样是O( N log N)。

    怎样搞清楚所有这些不同情况?

    性 能的承诺是和特殊的实现技巧联系在一起的,而如果你知道这些技巧是什么的话,这个承诺就更明白了。允许sort()以快速排序(递归分割区间)来实现,而 stable_sort()以归并排序(递归归并已序子区间)来实现[注1]。快速排序是已知的最快速排序算法之一,复杂度几乎总是O(N log N),但对一些特殊序列是O(N2); 如果标准总要求sort()是O(N log N),将不能使用快速排序。同样,归并两个子区间在有额外缓冲区以拷贝结果时将很容易实现;归并排序在可以使用与原始区间同样大的辅助缓冲区时是O(N log N),如果不能获得任何辅助缓冲区时是O(N (log N)2)。如果它只能使用一个较小的辅助缓冲区,复杂度将在两者之间--但,在现实中,更接近于O(N log N)。

    这 解释了标准中说的东西,但还不全。标准说“如果最坏情况时的行为很重要”,你就不该使用sort()。然而,事实并不象标准第一次写下这条建议时那样。许 多标准运行库的实作,包括GNU g++和Microsoft Visual C++,现在使用快速排序的一个新的变种,称为introsort[注2](WQ注:参看侯捷《STL源码剖析》)。Introsort一般说来和快速排 序同样快,但它的复杂度总是O(N log N)。 除非你顾虑老的标准库的实作,最差情况时的行为不再成为避免使用sort()的理由。并且,虽然stable_sort (通常)也是O(N log N),这个O掩盖了很多细节。

    在 绝大多数情况下,stable_sort()比sort()慢很多,因为它必须对每个元素作更多操作;这就是你要为“稳定”付出的代价。使用 stable_sort()应付等价元素维持原来的相对顺序很重要的情况(比如,根据优先级进行排序,但要对相同优先级的条目保持先来先处理的顺序),而 使用sort()处理其它情况。

    另 一个泛型排序算法是partial_sort()(包括一个小变种,partial_sort_copy())。它的功能稍有不同,语法也稍有区别:它查 找并排序区间内的前n名元素。和其它情况一样,默认是通过“<”比较进行升序排列,但能提供一个functor来改变它。于是,举例来说,如果你只 对序列的前10名的元素感兴趣,可以这样找到它们:

    partial_sort(first, first+10, last, greater<T>());

然后,最大的10个元素将被容纳在[first, fist + 10)(降序排列), 其余元素容纳在[first + 10, last)。

    这 儿有一个明显的受限情况:如果你写partial_sort(first, last, last),那么你正要求partial_sort()排序整个[first, last)区间。于是,虽然语法稍有不同,你能仍然能以使用sort()的同样的方法使用partial_sort()。有理由这么做吗?实际是没有。查 看一下C++标准对复杂度的描述,你将看到partial_sort()和sort一样,也是O(N  log N),但是,再一次,这是不完全的描述。两个O(N log N)的运算不必然有同样的速度;对此例,sort()通常快得多。

    partial_sort() 的存在是为了部分排序。假如你有一个一百万个名字的列表,而你需要找前一千个,按字母排序。通过对整个列表排序并忽略后面的部分,你可以得到这一千个名 字,但那会非常浪费。使用partial_sort()或partial_sort_copy()会快得多:

    vector<string> result(1000);

    partial_sort_copy(names.begin(), names.end(), result.begin(), result.end());

    当你只对已序区间的前面部分感兴趣时,使用partial_sort(),而在需要排序整个区间时使用sort()。

   如 对sort()和stable_sort()所做过的,考查一下partial_sort()是如何实现的将会有帮助。通常的实现,也是C++标准制订者 建议的,是使用堆排序:输入区间在一个称为heap的数据结构中重新整理,heap本质上是一个用数组实现的二叉树,它很容易找到最大的元素,并且很容易 在移除最大元素时仍然保持为一个有效heap。如果我们连续地将元素从一个heap中移开,那么将会留下最小的n个元素:正是我们想从 partial_sort获得的。如果从heap中移除所有元素,将会得到一个已序区间。

    标准C++运行库包含了直接操纵heap的泛型算法,所以,代替使用 partial_sort(),要排序一个区间可以写:

    make_heap(first, last);

    sort_heap(first, last);

这看起来和

    partial_sort(first, last, last);

不同,但其实不是这样。两种情况下,你都使用了堆排序;两种形式应该具有完全相同的速度。

    最 后,还有最后一个“泛型”排序算法,从C语言继承而来:qsort()。 对“泛型”加引号,是因为qsort()实际上不象sort()、stable_sort()和partial_sort()那样通用。不能用它排序具有 构造函数、虚函数、基类或私有数据成员的对象。C语言不知道这些特性;qsort()假设它可以按位拷贝对象,而这只对最简单的class才成立。也很难 在模板中使用qsort(),因为你必须传给它一个参数是void *类型的比较函数,并且在这个函数内部知道要排序的对象的精确类型。

    C 语言标准没有对qsort()作出性能承诺。在可以使用qsort()的场合,通常表现得比sort()慢很多。(主要是因为一个简单的原 因:sort()的接口被设计得可以将比较函数内联,而qsort()的接口做不到这一点。)除非是遗留代码,你应该避免使用 qsort();sort()具有一个更简单并且更安全的接口,它的限制比较少,而且更快。

对特别的容器进行排序

    我以讨论泛型算法开始,是因为标准C++运行库的基本原则是解耦不必要耦合的事物。算法被从容器中分离出来。在对容器的需求中,没有提到排序;排序一个vector是使用一个独立于std::vector的泛型算法:

    sort(v.begin(), v.end());

    然而,任何对C++中的排序的完备讨论都必须包括容器。通常,容器没有提供排序方法,但一些特殊的容器提供了。

    你 不能通过写v.sort()来排序一个vector,因为std::vector没有这样的成员函数,但你可以通过写l.sort()来排序一个 list。和往常一样,你可以显式地提供一个不同的比较函数:如果l是一个int型的list,那么l.sort(greater<int> ())将按降序排序它。

    事 实上,list::sort()是排序一个list的唯一的容易方法:std::list只提供了Bidirectional Iterator,但独立的泛型排序算法(sort()、stable_sort()和partial_sort())要求更强大的Random Access Iterators[注3]。这个特别的成员函数list::sort()不使用iterator,于是暴露了list是以相互连接的节点来实现的事实。 它使用归并排序的一个变种,通过连接和解连节点来工作,而不是拷贝list中的元素。

    最 后,排序一个set(或一个multiset,如果你需要拥有重复元素)是最简单的:它本来就是已排序的!你不能写 sort(s.begin(),s.end()),但你也从不需要这么做。set的一个基本特性是它的元素按顺序排列的。当你insert()一个新元素 时,它自动将它放置在适当的位置以维持排序状态。在其内部,set使用一个能提供快速(O(log N))的查找和插入的数据结构(通常是某种平衡树)。

时间测试

这将我们置身何处?我已经对时间作了一些论断,而且我们还能作些更直觉的预测:比如,在set 中插入一个元素将比排序一个vector慢,因为set是一个复杂的数据结构,它需要使用动态内存分配;或者,排序一个list应该和使用 stable_sort差不多快,它们都是归并排序的变种。然而,直觉不能取代时间测试。测量很困难 (更精确地说,你要测量什么,又如何测量?),但这是有必要的。

    Listing 1的程序构造了一个vector<double>,其中的元素乱序排列,然后用我们讨论过的每个方法(除了qsort()(WQ注:原文如 此))反复对它进行排序。在将vector传给每个测试用例时,我们故意使用传值:我们不想让任何一个测试用例得到一个已排序的vector!

    用Microsoft Visual C++ 7 beta编译程序(结果和g++相似),在500M的Pentium 3上进行,结果如下:

    Sorting a vector of 700000 doubles.

    sorting method    t (sec)

    sort              0.971

    qsort             1.732

    stable_sort       1.402

    heap sort         1.282

    list sort         1.993

    set sort          3.194

    这 和期望相符:sort()最快;stable_sort()、堆排序和qsort()稍慢;排序一个list和set(它使用动态内存分配,并且是个复杂 的数据结构),更加慢。 (实际上,qsort()有一个不寻常的好成绩:在g++和VC的老版本上,qsort()仅比sort()慢。)

    但这不足以称为排序基准测试--太不具有说服力了。我在一个特定的系统上,使用一个特定的(乱序)初始化,来测试排序一个vector<double>。只有实践能决定这些结果有多大的普遍性。至少,我们应该在double以外再作些测试。

    Listing 2排序一个vector<string>:它打开一个文件并将每一行拷贝进一个独立的string。因为qsort()不能处理具有构造函数 的元素,所以这个测试中不再包括qsort()。以Project Gutenberg的免费电子文本《Anna Karenina》[注4]作为输入,结果是:

    Sorting a file of 42731 lines.

    sorting method  t (sec)

    sort            0.431

    stable_sort     1.322

    heap sort       0.751

    list sort       0.25

    set sort        0.43

    突然之间,事情发生了变化。我们仍然看到sort()比stable_sort()和堆排序快得多,但list和set的结果发生了戏剧性的变化。使用set的速度几乎和sort()一样,而list实际上更快。发生了什么?

    变 化是double是原生类型,而std::sting是一个复杂的class。拷贝一个string或将它赋值给另一个,意味着要调用一个函数--甚至意 味着需要使用动态内存分配或创建一个mutex锁。平衡点被改变了;排序string比排序double时,赋值的次数将有更多的影响。排序一个list 时,根本没有调用赋值运算:定义一个特别的list::sort()成员函数的全部理由就是它通过操纵指向list的内部节点的指针来工作的。重连接一些 list的node的指针比拷贝一个string快。

    我 们再度发现一个老的至理名言:如果你正在处理大的记录,你绝不要排序记录本身,排序指向它们的指针。使用list使得这一点成为自动,但你也能很容易地显 式做到这一点:不是排序原始的vector<string>,取而代之,创建一个索引vector,其元素类型是 vector<string>::const_iterator,然后排序这个索引vector。你必须告诉sort()如何比较索引 vector的元素(你必须确保比较的是iterator所指的值而不是iterator本身),不过这只是个小问题。我们只需提供一个合适的比较函数对 象:

    template <class Iterator>

    struct indirect_lt {

      bool operator()(Iterator x, Iterator y) const

        { return *x < *y; }

    };

    Listing 3展示了如何使用indirect_lt,并对比了直接排序和间接排序时的速度。速度的提升是显著的。

    Sorting a file of 42731 lines.

    sorting method   t (sec)

    indirect sort    0.29

    sort             0.401

posted @ 2011-05-25 16:54 月下孤影 阅读(1159) | 评论 (0)编辑 收藏
仅列出标题