Suk's Blog-Our Power,Our Gift,Our Heaven

浏览器大战正当时

2009-03-25T20:36:00.009+08:00

最近关于浏览器的新闻真可谓满天飞，这不IE8终于面世啦；Chrome1.0正式版也早已推出，Chrome社区正忙乎2.0及linux版本呢；Safari可也没闲着，才不久也来了个Safari4.0beta版，引得大众一番轰动；Firefox可也不断的忙乎着升级，从3.0一步一步升到3.0.7哪，以目前的势头可没暂停终止的迹象。。。

再说啦国内上网本可炒得不一乐乎，从供应商到硬件平台，甚至到用户的使用等等，可惜真正走到用户手中，或许还得要有些日子，其中一直让人好奇的是上网本究竟使用哪款浏览器内核，对用户而言仅仅上上网浏览浏览新闻、逛逛论坛、看看视频、参加参加网上社区就够了吗？有这样便宜的硬件平台及好用的浏览器吗？

如此林林总总让人目不暇接，于是在沉寂了一段时间之后，想借此机会总结总结自己的一些使用体会及对浏览器今后发展的一些看法。

一、各款浏览器大比拼

从IE8正式版本推出后的第一时间，就下载试用过它，经过一段时间的对比测试，第一时间使用的感受如下：
在浏览器大混战中IE8正奋力追赶，几乎没有独创或值得大说特说的新特性，几乎就是在模仿或抄袭其他浏览器受人欢迎的特性如多页签、多进程、web开发人员工具等；

IE8虽然在很多方面有所改进但仍然是IE系列浏览器，关键方面没有质的飞跃，好的方面有持续支持已有的框架、风格、设置、扩展等，令人诟病以久的W3C标准支持及推动仍举步艰难，这不ACID3测试还是保持在30分左右的水平呢？

经过一些测试发现其加载页面速度及占用资源方面，与Chrome相比仍然有一定的差距，总体而言Chrome要想超越IE系列浏览器关键要在扩展方式及应用方面向IE、Firefox学习，当然还要有用户推广方面更大的努力；

IE8虽然看起来步伐不是很快，但在其拥有庞大的用户基础之上进行稳步推进是非常值得肯定的，特别是它保持了对原有扩展的支持的基础之上，实现了多进程及安全方面的加强。从目前看来要想IE浏览器使用WebKit内核简直就是痴人说梦，忽悠忽悠而已，因为微软仍然对Web采取封闭而非开放合作的态度。。。

Chrome

Chrome浏览器自去年九月份推出以来就属当红炸鸡啦，赚足了眼球，当然Google及Chrome社区其实正不余遗力地加强Chrome浏览器的功能及满足用户的潜在需求及对广大网民的承诺，正与其一位开发人员所讲由于目前的浏览器太差，从而有想要开发浏览器的驱动力；

到目前为止其稳定性相比测试版本有了较大的提升，加载速度方面也算佼佼者啦，唯一的缺憾在于其扩展的支持，从其实现架构及WebKit内核来讲要达到类似IE ActiveX或Firefox Extension那样的方便也许难度不小；

令人值得称道的是其linux gtk版本或许不久就能面试啦，对linux用户来讲是一大福音；

Safari

Safari4.0beta版的发布有点出乎人们的意料，Apple在其网站Safari全新特色上对其特性进行过一番"吹嘘"，通过仔细阅读其内容，发现Apple也似乎正努力的打造一款极具个性的Safari浏览器，其中从Chrome中学了不少东东如页签的位置、TopSite等，当然其中令人有趣的页签拖动还是独特的，还有类似的界面及操作风格延续了Apple的优良传统；

虽然其JavascriptCore内核没变，但起了个商业上的名称nitro，一时真让人莫名其妙，也许只要Apple自己知道改名的真正原因；

虽然其ACID3测试的得分在90分以上(Chrome80-90，Firefox70多一点)，但其在Windows上的资源使用情况就没有宣称的那么好啦，特别是拥有Adobe flash的页面上；其架构上仍然没有使用多进程，与Firefox一样，但其消耗内存及CPU可比Firefox高的多，并且还不稳定，也许是Beta版的原因吧，看样其要想在Windows上分一杯羹难度不少；

那么Apple为什么还要"折腾"Safari哪？我想或许其算盘在Mac及iPhone上呢？Apple也许还担心哪天Chrome杀到Mac平台呢？要是现在不紧跟浏览器的发展，到那时Chrome壮大啦，自己又没有守住自己的领地哪滋味可就真不好受，再说Chrome使用的WebKit内核可是由Apple主导开发的呢？改个Javascript引擎的名字为Nitro，或许相比JavascriptCore、SFX起来，更好听，更像V8那样容易让人记住；

WebKit的发展来源于Apple，当然也离不开Apple，其对W3C标准的支持及扩展付出了极大的努力，这一点让人钦佩，特别是其对ACID3测试所作的努力及Javascript引擎实现方式的突破；

在这场浏览器大战中，没有Apple，没有WebKit，也就没有了大战的平台，虽然目前结果未知，但WebKit内核本身非常值得关注，也许WebKit内核的发展是大战成败的关键，有了Google、Apple、Adobe等的参与与使用，WebKit内核的市场份额经过大战之后肯定会得到大量的提升，其发展同样令人瞩目；

Firefox

Mozilla自从推出Firefox1.5，就逐步的从上一次失败的阴影中走出来，到了2008年推出Firefox3.0开始使用Gecko1.9，才让人真正的感觉到凤凰涅磐的滋味，那些家伙，狂热的技术追逐者，令世人刮目相看，其架构、其扩展性、其开放性、其开拓性，成为推动Web技术发展与应用的根本；

正可谓Firefox是这场浏览器大战的导火索，由一群对技术孜孜不倦的家伙发起对Web发展及应用的号角；这不其倡导的多页签、xul、xbl、npapi、cavas等，在Firefox上得到充分的应用与展现，有些方面IE、WebKit还在苦苦的追逐呢；网上有人评论Firefox离开了Google财务的支持，也许即将面临死亡，听起来有些骇然，从商业角度讲或许他是对的，但Mozilla社区对Web技术的开拓创新等却不会那么轻易的死掉，只要他们坚持这条道同时考虑考虑用户感受，先锋不会再次成为先烈，饿死的或许只会是那不思进取，抱残守缺的家伙。。。。

二、浏览器发展方向
浏览器的发展推动Web的发展与应用，同时Web的发展与应用促使浏览器更加的强壮，浏览器的发展离不开Web的发展，目前看来其发展方向应该在于：

更加的标准化

也许IE被逼着卷入这场浏览器大战，不如说被逼着卷入标准化大战，Firefox、Chrome、Safari、Opera都自觉不自觉的坚持w3c标准，并且还不断的推动标准的发展，从目前的态势看Microsoft不得不应战，虽然极不情愿，也许大势所趋吧，识时务者为俊杰；

Firefox、WebKit正不遗余力的推动html5 video等标签、增加工作线程、跨域名XmlHttpRequest等，或许未来的标准就此产生；

更加的开放

上面提及的几个浏览器大部分搭乘开源的顺风，实施开源，公开透明，行自由开放之风，这样Web的发展及应用或许更加的开放；

更加的复杂

由于Web应用更加的复杂及多样性，对浏览器的要求及本地系统、硬件的要求越来越高，所以多进程的出现，从另一个侧面体现其复杂性及可靠性要求的提高。试想一个程序，它可使用来自世界各地形式各异的Web数据，同时尽可能的按照同样的方式展现给不同的用户，虽然有公共遵守的W3C标准，但要求其高效、可靠的完成，其实现本身的复杂性就可想而知了，如果Web数据进行更进一步的多样化，那其复杂度自然增加；

小型设备化应用

由iPhone开启手机浏览互联网的新风，如火如荼的andriod、QtWebKit、Fennec、MiniOpera、UcWeb等正大力的拓展浏览器的嵌入式应用，上网本正是在这样的背景上进入人们的视眼，上网本还没火起来，曾经的维纳斯电视上网计划或许在不久的将来会真正的走进人们的客厅；这样看起来上面提到的浏览器大战似乎才刚刚开局呢。。。。

三、如何把握浏览器开发及商业应用
目前浏览器的开发主要体现在IE内核、Firefox Gecko内核、WebKit内核，从历史的角度看IE内核的扩展更加的容易，面对的PC用户庞大，但同样仅受限于windows平台使用；

针对Gecko内核，最近几年的extension快速扩展及应用普及加速了Firefox的发展与应用，并且得到一些开发者及网民的好评，同时其可应用于Windows、Mac、Linux平台，其扩展性令人赞叹；

而WebKit内核，发端应用于Mac平台Safari，名声大振于iPhone，Chrome的出现将其推到风口浪尖，其特性鲜明，虽然其移植性较好，可移植到不同平台，包括嵌入式应用，但其扩展性就没那么方便啦，有些平台对NPAPI插件的全方位支持也显得那么的难得，也许需要给他们一点时间吧，目前看来要想对其进行一定程度的开发难道还是不少。。。

从以前的历史经验中我们都知道浏览器这样一个软件，受到广大用户的青睐，可没有哪家大公司直接从中获得过与其实际地位相符的利润，包括免费捆绑销售的IE及Netscape等等，从这点看来与Office相比太令人惭愧啦，可见开发浏览器可不那么好赚钱，商业模式不是那么直接，那么写写扩展是否能获取一定回报哪，看看以前IE ActiveX的流行，或许能让我们打开一片联想的天地。

从更大的角度看，直接从浏览器本身来收取费用如Opera及以前的Netscape，是比较难的，关键得从应用服务来收费，如Firefox从内嵌Google搜索栏来获取收费，Adobe从嵌入的Flash插件来获取丰厚利润回报，但是一个好的扩展应用则需要对浏览器本身及其应用的充分理解。

也许上网本及各式各样的嵌入设备的出现再加上捆绑免费的浏览器，正是浏览器获取应用及回报的另一途径。

在浏览器扩展的同时及时提供优秀的Web应用或许是获取商业利润的又一方式，这或许是Google、IBM等大力推广云计算的良苦用心啦。

面对如此林林总总的方式，作为一个开源浏览器的爱好者，你找到了利用浏览器或其技术实现利润收入的方式了吗？也许大家还有更好的方式，不免大家一起分享分享。。。

WebKit网页布局实现之布局篇

2008-12-26T21:44:00.006+08:00

在我们对WebKit网页布局实现所涉及的主要概念及数据结构有了一定的理解之后，让我们再来看看其布局过程的具体实现。

一、FrameView::layout方法
FrameView作为与View相关的类，其主要涉及与显示相关的内容，而其中对页面元素的布局至关重要，这也是浏览器的核心处理部分。

我们都知道浏览器从Web服务器获得数据后，经解析会构建DOM树、Render树，然后进行布局处理，进而为渲染页面作好准备，其中的布局处理往往由FrameView::layout方法发起，让我们来具体看看其实现，一窥其主要实现过程。
void FrameView::layout(bool allowSubtree)
{
if (d->m_midLayout)
return;
// Always ensure our style info is up-to-date. This can happen in situations where
// the layout beats any sort of style recalc update that needs to occur.
//进行CSSStyleSelector的更新处理，因为一旦CSS发生变化，布局的结果也可能发生相关变化，所以在开始布局之前，需要检查CSS是否发生变化，如果有则需要作相应调整，进而可能影响Render树等。
bool subtree = d->m_layoutRoot;
.......................................................................
RenderObject* root = subtree ? d->m_layoutRoot : document->renderer();
if (!root) {
// FIXME: Do we need to set m_size here?
d->m_layoutSchedulingEnabled = true;
return;
}
//布局的处理可能相互嵌套，这与发起布局处理的时机相关。
d->m_nestedLayoutCount++;
ScrollbarMode hMode = d->m_hmode;
ScrollbarMode vMode = d->m_vmode;

d->m_doFullRepaint = !subtree && (d->m_firstLayout || static_cast(root)->printing());

if (!subtree) {
// Now set our scrollbar state for the layout.
ScrollbarMode currentHMode = hScrollbarMode();
ScrollbarMode currentVMode = vScrollbarMode();
//对于初次布局，则需要设置FrameView的滚动条信息等
if (d->m_firstLayout || (hMode != currentHMode || vMode != currentVMode)) {
suppressScrollbars(true);
if (d->m_firstLayout) {
d->m_firstLayout = false;
d->m_firstLayoutCallbackPending = true;
d->m_lastLayoutSize = IntSize(width(), height());
d->m_lastZoomFactor = root->style()->zoom();

// Set the initial vMode to AlwaysOn if we're auto.
if (vMode == ScrollbarAuto)
ScrollView::setVScrollbarMode(ScrollbarAlwaysOn); // This causes a vertical scrollbar to appear.
// Set the initial hMode to AlwaysOff if we're auto.
if (hMode == ScrollbarAuto)
ScrollView::setHScrollbarMode(ScrollbarAlwaysOff); // This causes a horizontal scrollbar to disappear.
}

if (hMode == vMode)
ScrollView::setScrollbarsMode(hMode);
else {
ScrollView::setHScrollbarMode(hMode);
ScrollView::setVScrollbarMode(vMode);
}

suppressScrollbars(false, true);
}

IntSize oldSize = m_size;

m_size = IntSize(visibleWidth(), visibleHeight());

if (oldSize != m_size)
d->m_doFullRepaint = true;
}
//root往往为RenderView对象
RenderLayer* layer = root->enclosingLayer();
......................................
d->m_midLayout = true;
beginDeferredRepaints();
root->layout();
endDeferredRepaints();
d->m_midLayout = false;
.......................................
d->m_layoutSchedulingEnabled = true;

if (!subtree && !static_cast(root)->printing())
adjustViewSize();

// Now update the positions of all layers.
//对当前Render树布局完后，设置RenderLayer树的布局信息，其中d->m_doFullRepaint描述是否需要发起渲染处理。
beginDeferredRepaints();
layer->updateLayerPositions(d->m_doFullRepaint);///it's very important for RenderLayer to set m_x/m_y/m_width/m_height
endDeferredRepaints();
//因为在布局的过程中，可能进一步获得网页数据，则需要继续布局处理。
if (needsLayout()) {
// Post-layout widget updates or an event handler made us need layout again.
// Lay out again, but this time defer widget updates and event dispatch until after
// we return.
........................
layout();
}
}

FrameView::layout方法，简单的说来就是发起对Render树中的每一个节点按照从父节点到子节点的方式进行x、y、width、height计算，当每一个树节点的位置及大小确定之后就可以进行后面的渲染。

FrameView::layout往往会调用Render树根的layout方法即RenderView::layout。

二、RenderView::layout方法
void RenderView::layout()
{
if (printing())
m_minPrefWidth = m_maxPrefWidth = m_width;

// Use calcWidth/Height to get the new width/height, since this will take the full page zoom factor into account.
bool relayoutChildren = !printing() && (!m_frameView || m_width != viewWidth() || m_height != viewHeight());
if (relayoutChildren)
setChildNeedsLayout(true, false);

ASSERT(!m_layoutState);
LayoutState state;
// FIXME: May be better to push a clip and avoid issuing offscreen repaints.
state.m_clipped = false;
m_layoutState = &state;

if (needsLayout())
RenderBlock::layout();//类继承的好处，直接调用父类的layout

// Ensure that docWidth() >= width() and docHeight() >= height().
setOverflowWidth(m_width);
setOverflowHeight(m_height);

setOverflowWidth(docWidth());
setOverflowHeight(docHeight());

ASSERT(m_layoutStateDisableCount == 0);
ASSERT(m_layoutState == &state);
m_layoutState = 0;
setNeedsLayout(false);
}

void RenderBlock::layout()
{
// Update our first letter info now.
updateFirstLetter();
// Table cells call layoutBlock directly, so don't add any logic here. Put code into
// layoutBlock().
layoutBlock(false);

// It's safe to check for control clip here, since controls can never be table cells.
if (hasControlClip()) {
// Because of the lightweight clip, there can never be any overflow from children.
m_overflowWidth = m_width;
m_overflowHeight = m_height;
m_overflowLeft = 0;
m_overflowTop = 0;
}
}

三、RenderBlock::layoutBlock方法
void RenderBlock::layoutBlock(bool relayoutChildren)
{
......................................................
calcWidth();//先计算宽度
calcColumnWidth();

m_overflowWidth = m_width;
m_overflowLeft = 0;
if (oldWidth != m_width || oldColumnWidth != desiredColumnWidth())
relayoutChildren = true;
clearFloats();

int previousHeight = m_height;
m_height = 0;
m_overflowHeight = 0;
..................................................
//这就是在布局基本概念中提到的Block-level元素的子节点要么是Block-level元素要么为Inline-level元素。
if (childrenInline())
layoutInlineChildren(relayoutChildren, repaintTop, repaintBottom);
else
layoutBlockChildren(relayoutChildren, maxFloatBottom);

// Expand our intrinsic height to encompass floats.
int toAdd = borderBottom() + paddingBottom() + horizontalScrollbarHeight();
if (floatBottom() > (m_height - toAdd) && (isInlineBlockOrInlineTable() || isFloatingOrPositioned() || hasOverflowClip() ||
(parent() && parent()->isFlexibleBox() || m_hasColumns)))
m_height = floatBottom() + toAdd;

// Now lay out our columns within this intrinsic height, since they can slightly affect the intrinsic height as
// we adjust for clean column breaks.
int singleColumnBottom = layoutColumns();

// Calculate our new height.//布局完子节点后确定父节点高度
int oldHeight = m_height;
calcHeight();
....................................................
if (previousHeight != m_height)
relayoutChildren = true;
...................................................
if ((isCell || isInline() || isFloatingOrPositioned() || isRoot()) && !hasOverflowClip() && !hasControlClip())
addVisualOverflow(floatRect());
//另外布局属性为Fixed和absolute的元素
layoutPositionedObjects(relayoutChildren || isRoot());

// Always ensure our overflow width/height are at least as large as our width/height.
m_overflowWidth = max(m_overflowWidth, m_width);
m_overflowHeight = max(m_overflowHeight, m_height);

......................................................

// Update our scroll information if we're overflow:auto/scroll/hidden now that we know if
// we overflow or not.
if (hasOverflowClip())
m_layer->updateScrollInfoAfterLayout();//also is important..

// Repaint with our new bounds if they are different from our old bounds.
bool didFullRepaint = false;
//布局后根据条件确定是否发起渲染处理
if (checkForRepaint)
didFullRepaint = repaintAfterLayoutIfNeeded(oldBounds, oldOutlineBox);
..........................................................
// Make sure the rect is still non-empty after intersecting for overflow above
if (!repaintRect.isEmpty()) {
repaintRectangle(repaintRect); // We need to do a partial repaint of our content.
if (hasReflection())
layer()->reflection()->repaintRectangle(repaintRect);
}
}
setNeedsLayout(false);
}

四、RenderBlock::layoutBlockChildren方法
void RenderBlock::layoutBlockChildren(bool relayoutChildren, int& maxFloatBottom)
{
int top = borderTop() + paddingTop();
int bottom = borderBottom() + paddingBottom() + horizontalScrollbarHeight();

m_height = m_overflowHeight = top;
//遍历子节点
RenderObject* child = firstChild();
while (child) {
if (legend == child) {
child = child->nextSibling();
continue; // Skip the legend, since it has already been positioned up in the fieldset's border.
}
.........................................
// Handle the four types of special elements first. These include positioned content, floating content, compacts and
// run-ins. When we encounter these four types of objects, we don't actually lay them out as normal flow blocks.
bool handled = false;
RenderObject* next = handleSpecialChild(child, marginInfo, compactInfo, handled);
if (handled) { child = next; continue; }

// The child is a normal flow object. Compute its vertical margins now.
child->calcVerticalMargins();
// Do not allow a collapse if the margin top collapse style is set to SEPARATE.

// Try to guess our correct y position. In most cases this guess will
// be correct. Only if we're wrong (when we compute the real y position)
// will we have to potentially relayout.
int yPosEstimate = estimateVerticalPosition(child, marginInfo);

// Cache our old rect so that we can dirty the proper repaint rects if the child moves.
IntRect oldRect(child->xPos(), child->yPos() , child->width(), child->height());

// Go ahead and position the child as though it didn't collapse with the top.
view()->addLayoutDelta(IntSize(0, child->yPos() - yPosEstimate));
//先确定x、y。
child->setPos(child->xPos(), yPosEstimate);
..........................................
bool childNeededLayout = child->needsLayout();
if (childNeededLayout)
child->layout();//子节点进行布局处理
...................................................
// Now place the child in the correct horizontal position
determineHorizontalPosition(child);
// Update our height now that the child has been placed in the correct position.
m_height += child->height();
if (child->style()->marginBottomCollapse() == MSEPARATE) {
m_height += child->marginBottom();
marginInfo.clearMargin();
}
.........................................................
// Update our overflow in case the child spills out the block.
..........................................................
child = child->nextSibling();
}
// Now do the handling of the bottom of the block, adding in our bottom border/padding and
// determining the correct collapsed bottom margin information.
handleBottomOfBlock(top, bottom, marginInfo);
}

五、RenderBlock::layoutInlineChildren方法
这个方法相当复杂，其作用就是布局文字、图像等，对文字行高确定、断行等处理，同时还包括文字从左到右或从右到左的布局处理。具体可以参考bidi.cpp中的源码实现。

六、调用FrameView::layout方法的时机
由于从Web服务器获取的网页数据不可能一次性完成，往往需要边获取数据，边布局，然后渲染，这样才可能获得良好的用户感受。

所以一旦获得主要数据如css数据及body等标签后，就可以开始布局，布局完后会根据当前条件决定是否将布局的数据渲染出来，或者继续布局处理后来获取的数据，这样也增加了布局处理过程的复杂度。

而调用layout方法的时机也至关重要，因为layout本身就可能需要花费大量的时间如layoutBlockChildren、layoutInlineChildren等处理，其往往与网页的内容有关，而网页的内容却由网页开发者来确定，对浏览器来讲是千变万化的，这就对layout方法的实现及调用时机提出更高的要求，同时确定了其复杂性。

调用layout的时机主要有获得一定DOM文档数据后调用Document::updateLayout()、需要重新使用CSS数据时调用Document::recalcStyle()、改变窗口大小后调用Frame::forceLayout()等来实现。。。

七、总结
其实WebKit涉及网页布局方面的layout方法蛮复杂的，如其他RenderObject子类也会根据自身情况重载实现layout，还有对float、fixed、absolute、inline元素等的处理，但其主要逻辑就象上面所提，这里只是汇总一下主要流程及概念，针对每一个具体标签或RenderObject的布局实现则需要更深一步的了解，希望大家能对了解WebKit的网页布局过程有一个清晰而准确的认识。。

八、参考资源
The WebKit Open Source Project

WebKit网页布局实现之主要数据结构篇之二

2008-12-18T20:38:00.023+08:00

从上一篇 WebKit网页布局实现之主要数据结构篇中,我们对WebKit网页布局所涉及的主要数据结构有了初步的了解，认识到Render树的构成及CSS属性的描述RenderStyle等，对主要 RenderObject基类及子类有了一定的了解，但在构成Render树时所涉及的一些关键方法还未具体描述，同时还有其他一些为布局及渲染所准备的数据结构也需要有更深入的理解，下面将进一步的了解相关数据结构及相关方法。

一、继续Render树的构成
1、子类RenderButton
RenderButton代表html中input标签type为button时对应的Render树节点，它直接继承自RenderFlexibleBox；
RenderFlexibleBox代表能按居中、左对齐、右对齐等水平或垂直方向布局子节点的树节点；

RenderButton主要数据成员

图一

其中m_buttonText为button上的文字对应的树节点，而m_inner为添加m_buttonText时创建的匿名对象，以便于居中等处理等。这些成员的创建来自于方法updateFromElement；
void RenderButton::updateFromElement()
{
// If we're an input element, we may need to change our button text.
if (element()->hasTagName(inputTag)) {
HTMLInputElement* input = static_cast(element());
String value = input->valueWithDefault();
setText(value);
}
}
void RenderButton::setText(const String& str)
{
..........................
m_buttonText = new (renderArena()) RenderTextFragment(document(), str.impl());
m_buttonText->setStyle(style());
addChild(m_buttonText);
......................
}
void RenderButton::addChild(RenderObject* newChild, RenderObject* beforeChild)
{
if (!m_inner) {
// Create an anonymous block.
m_inner = createAnonymousBlock();
m_inner->style()->setBoxFlex(1.0f);
RenderFlexibleBox::addChild(m_inner);
}
m_inner->addChild(newChild, beforeChild);
}
在缺省的html.css中对应button的css属性如下：
input[type="button"] {
-webkit-appearance: push-button;
white-space: pre
}
input[type="button"]{
-webkit-box-align: center;
text-align: center;
cursor: default;
color: ButtonText;
padding: 2px 6px 3px 6px;
border: 2px outset ButtonFace;
background-color: ButtonFace;
-webkit-box-sizing: border-box
}
这些css属性通过CSSStyleSelector::applyProperty方法来设定其成员m_RenderStyle对应的值，其中包含 m_style->setAppearance(PushButtonAppearance);尤其值得关注，其初步决定了button是如何画出来的。。

2、子类RenderTextControl
RenderTextControl代表html中input标签type为text或textarea标签对应的Render树节点，它直接继承自RenderBlock；

RenderTextControl主要数据成员

图二

其中成员m_multiLine以描述是textarea或text input；m_innerText为其中包括的文字对应的树节点；当作搜索按钮时m_cancelButton/m_resultsButton为对应的树节点；这些成员的创建来自于方法updateFromElement；
void RenderTextControl::updateFromElement()
{
HTMLFormControlElement* element = static_cast(node());

createSubtreeIfNeeded();

...................................

m_innerText->renderer()->style()->setUserModify(element->isReadOnlyControl() || element->disabled() ? READ_ONLY : READ_WRITE_PLAINTEXT_ONLY);

if ((!element->valueMatchesRenderer() || m_multiLine) && !m_placeholderVisible) {
String value;
if (m_multiLine)
value = static_cast(element)->value();
else
value = static_cast(element)->value();
if (value.isNull())
value = "";
else
value = value.replace('\\', backslashAsCurrencySymbol());
if (value != text() || !m_innerText->hasChildNodes()) {
if (value != text()) {
if (Frame* frame = document()->frame())
frame->editor()->clearUndoRedoOperations();
}
ExceptionCode ec = 0;
m_innerText->setInnerText(value, ec);
if (value.endsWith("\n") || value.endsWith("\r"))
m_innerText->appendChild(new HTMLBRElement(document()), ec);
m_dirty = false;
m_userEdited = false;
}
....................................
}
....................................
}
void RenderTextControl::createSubtreeIfNeeded()
{
............................................
if (!m_innerText) {
m_innerText = new HTMLTextFieldInnerTextElement(document(), m_innerBlock ? 0 : node());
RenderTextControlInnerBlock* textBlockRenderer = new (renderArena()) RenderTextControlInnerBlock(m_innerText.get());
m_innerText->setRenderer(textBlockRenderer);
m_innerText->setAttached();
m_innerText->setInDocument(true);

RenderStyle* parentStyle = style();
if (m_innerBlock)
parentStyle = m_innerBlock->renderer()->style();
RenderStyle* textBlockStyle = createInnerTextStyle(parentStyle);
textBlockRenderer->setStyle(textBlockStyle);

// Add text block renderer to Render tree
if (m_innerBlock) {
m_innerBlock->renderer()->addChild(textBlockRenderer);
ExceptionCode ec = 0;
// Add text block to the DOM
m_innerBlock->appendChild(m_innerText, ec);
} else
RenderBlock::addChild(textBlockRenderer);
}
.................................
}
在缺省的html.css中对应标签的css属性如下：
textarea {
-webkit-appearance: textarea;
background-color: white;
border: 1px solid;
-webkit-rtl-ordering: logical;
-webkit-user-select: text;
-webkit-box-orient: vertical;
resize: auto;
cursor: auto;
}
input, input[type="password"], input[type="search"], isindex {
-webkit-appearance: textfield;
padding: 1px;
background-color: white;
border: 2px inset;
-webkit-rtl-ordering: logical;
-webkit-user-select: text;
cursor: auto;
}
其中-webkit-appearance属性分别为textarea、textfield；

3、子类RenderListBox
RenderListBox代表html中select标签对应的Render树节点，它直接继承自RenderBlock；

RenderListBox主要数据成员

图三

其相关成员同样通过方法updateFromElement来设置初值；
在缺省的html.css中对应标签的css属性如下：
select {
-webkit-appearance: menulist;
-webkit-box-sizing: border-box;
-webkit-box-align: center;
border: 1px solid;
..............................................................
}

4、子类RenderTheme
RenderTheme在html标签中没有对应的页面元素，其作用主要用于如何渲染按钮、输入框、列表框等，其实现往往有一定平台相关性。

RenderTheme主要数据成员及方法

图四

RenderTheme 往往提供一个接口，不同的图形库对其中不同的方法如paintbutton、paintcheckbox、painttextfield等进行了实现；其中 paint方法则根据appearance属性的不同以分别调用不同的paintxxx方法，其示例代码如下：
bool RenderTheme::paint(RenderObject* o, const RenderObject::PaintInfo& paintInfo, const IntRect& r)
{
........................................
if (paintInfo.context->paintingDisabled())
return false;
// Call the appropriate paint method based off the appearance value.
switch (o->style()->appearance()) {
case CheckboxAppearance:
return paintCheckbox(o, paintInfo, r);
case RadioAppearance:
return paintRadio(o, paintInfo, r);
case PushButtonAppearance:
case SquareButtonAppearance:
case DefaultButtonAppearance:
case ButtonAppearance:
return paintButton(o, paintInfo, r);
case MenulistAppearance:
return paintMenuList(o, paintInfo, r);
break;
....................................................
default:
break;
}
return true; // We don't support the appearance, so let the normal background/border paint.
}
其中的appearance就是上面RenderButton、RenderTextControl、RenderListBox中提到的属性，至于 html中涉及到的类似标签或属性如radio、checkbox等等，其相关代码基本类似，至于不同的平台如Qt、Gtk、Win、Mac等究竟是如何画按钮、下拉框、列表框、多选框、单选框等等，则需详细参考RenderThemeQt/RenderThemeGtk/RenderThemeWin /RenderThemeMac等中的实现。

通过上述的了解我们应该对html中form标签内的输入框、按钮、下拉框等实现有了一定的认识。

5、子类RenderTable、RenderTableRow、RenderTableCol、RenderTableCell
这一组子类主要对应与html中table标签相关的树节点；

Table标签相关类主要数据成员

图五

RenderTable主要通过addChild方法来维护对RenderTableCell、RenderTableCol、RenderTableRow等对象的管理及维护；
void RenderTableCell::updateFromElement()
{
Node* node = element();
if (node && (node->hasTagName(tdTag) || node->hasTagName(thTag))) {
HTMLTableCellElement* tc = static_cast(node);
int oldRSpan = m_rowSpan;
int oldCSpan = m_columnSpan;

m_columnSpan = tc->colSpan();
m_rowSpan = tc->rowSpan();
if ((oldRSpan != m_rowSpan || oldCSpan != m_columnSpan) && style() && parent()) {
setNeedsLayoutAndPrefWidthsRecalc();
if (section())
section()->setNeedsCellRecalc();
}
}
}

void RenderTableCol::updateFromElement()
{
int oldSpan = m_span;
Node* node = element();
if (node && (node->hasTagName(colTag) || node->hasTagName(colgroupTag))) {
HTMLTableColElement* tc = static_cast(node);
m_span = tc->span();
} else
m_span = !(style() && style()->display() == TABLE_COLUMN_GROUP);
if (m_span != oldSpan && style() && parent())
setNeedsLayoutAndPrefWidthsRecalc();
}
RenderTableRow通过方法layout和paint方法来布局管理RenderTableCell对象；
这一组子类主要实现人们熟知的表格布局，具体的实现可具体参考相关类实现；

6、子类RenderFrame
RenderFrame代表html中标签frame对应的Render树节点，其继承关系如下：

RenderFrame类继承关系

图六

其中属性m_widget、m_view代表frame对应的widget及frameview，通过其中setwidget方法来设置m_widget属性，m_view属性则在对象创建的时候设置为当前document对应的frameview。

其中html中的embed/object插件标签对应的Render树节点为RenderPartObject对象。

7、构建Render树
从上一篇中我们了解到构建Render树的基本实现流程如下：void Element::attach()=>createRendererIfNeeded()=>createRenderer；以前我们着重了解过createRenderer，现在我们回头再来看看createRendererIfNeeded()，以更深入的了解是如何构建Render树。
void Node::createRendererIfNeeded()
{
if (!document()->shouldCreateRenderers())
return;
Node *parent = parentNode();
RenderObject *parentRenderer = parent->renderer();
if (parentRenderer && parentRenderer->canHaveChildren()
#if ENABLE(SVG)
&& parent->childShouldCreateRenderer(this)
#endif
) {
RenderStyle* style = styleForRenderer(parentRenderer);
if (rendererIsNeeded(style)) {
if (RenderObject* r = createRenderer(document()->renderArena(), style)) {
if (!parentRenderer->isChildAllowed(r, style))
r->destroy();
else {
setRenderer(r);
renderer()->setAnimatableStyle(style);
parentRenderer->addChild(renderer(), nextRenderer());
}
}
}
style->deref(document()->renderArena());
}
}

RenderStyle* Element::styleForRenderer(RenderObject* parentRenderer)
{
return document()->styleSelector()->styleForElement(this);
}

void RenderObject::setAnimatableStyle(RenderStyle* style)
{
if (!isText() && m_style && style)
style = animation()->updateImplicitAnimations(this, style);

setStyle(style);
}

从createRendererIfNeeded中我们可以了解到创建完RenderObject子类对象后，会为其设置RenderStyle属性，然后在该DOM Node的父节点对应的RenderObject中添加刚新建的RenderObject，这样以构建Render树。

但是在setStyle的过程中可能会调用createAnonymousFlow或createAnonymousBlock来创建匿名对象，其中RenderBox的setStyle方法如下：
void RenderBox::setStyle(RenderStyle* newStyle)
{
bool wasFloating = isFloating();
bool hadOverflowClip = hasOverflowClip();
RenderStyle* oldStyle = style();
if (oldStyle)
oldStyle->ref();

RenderObject::setStyle(newStyle);
....................................................................
setInline(newStyle->isDisplayInlineType());

switch (newStyle->position()) {
case AbsolutePosition:
case FixedPosition:
setPositioned(true);
break;
default:
setPositioned(false);

if (newStyle->isFloating())
setFloating(true);

if (newStyle->position() == RelativePosition)
setRelPositioned(true);
}

// We also handle and , whose overflow applies to the viewport.
if (!isRoot() && (!isBody() || !document()->isHTMLDocument()) && (isRenderBlock() || isTableRow() || isTableSection())) {
// Check for overflow clip.
if (newStyle->overflowX() != OVISIBLE) {
if (!hadOverflowClip)
// Erase the overflow
repaint();
setHasOverflowClip();
}
}
..............................................
if (requiresLayer()) {
if (!m_layer) {
if (wasFloating && isFloating())
setChildNeedsLayout(true);
m_layer = new (renderArena()) RenderLayer(this);
setHasLayer(true);
m_layer->insertOnlyThisLayer();
if (parent() && !needsLayout() && containingBlock())
m_layer->updateLayerPositions();
}
} else if (m_layer && !isRoot() && !isRenderView()) {
.......................................................
}
..................................................................
}

bool RenderObject::requiresLayer()
{
return isRoot() || isPositioned() || isRelPositioned() || isTransparent() || hasOverflowClip() || hasTransform() || hasMask() || hasReflection();
}

bool RenderObject::isRoot() const { return document()->documentElement() == node(); }
bool RenderObject::isPositioned() const { return m_positioned; } // absolute or fixed positioning
bool RenderObject::isRelPositioned() const { return m_relPositioned; } // relative positioning
bool RenderObject::isTransparent() const { return style()->opacity() <>RenderObject::hasOverflowClip() const { return m_hasOverflowClip; }
bool RenderObject::hasTransform() const { return m_hasTransform; }
bool RenderObject::hasMask() const { return style() && style()->hasMask(); }
bool RenderObject::hasReflection() const { return m_hasReflection; }

通过上面的了解我们知道在setStyle时符合一定条件的RenderObject会创建RenderLayer对象，那么究竟什么是RenderLayer类，其有什么作用，下面作初步的介绍。

二、RenderLayer树
1、类RenderLayer
RenderLayer类其实是一个非常复杂并且很重要的类，其主要数据成员如下：

RenderLayer类主要数据成员

图六

RenderLayer类主要与处理分层布局、渲染页面元素等相关如处理z-index、opacity等，只有符合一个条件的RenderObject才会创建RenderLayer对象，并且将这些RenderLayer对象组织成一颗树。

2、构建RenderLayer树
通过方法insertOnlyThisLayer来组织这颗RenderLayer树。
void RenderLayer::insertOnlyThisLayer()
{
if (!m_parent && renderer()->parent()) {
// We need to connect ourselves when our renderer() has a parent.
// Find our enclosingLayer and add ourselves.
RenderLayer* parentLayer = renderer()->parent()->enclosingLayer();
RenderLayer* beforeChild = parentLayer->reflectionLayer() != this ? renderer()->parent()->findNextLayer(parentLayer, renderer()) : 0;
if (parentLayer)
parentLayer->addChild(this, beforeChild);
}

// Remove all descendant layers from the hierarchy and add them to the new position.
for (RenderObject* curr = renderer()->firstChild(); curr; curr = curr->nextSibling())
curr->moveLayers(m_parent, this);

// Clear out all the clip rects.
clearClipRects();
}

void RenderLayer::addChild(RenderLayer* child, RenderLayer* beforeChild)
{
RenderLayer* prevSibling = beforeChild ? beforeChild->previousSibling() : lastChild();
if (prevSibling) {
child->setPreviousSibling(prevSibling); prevSibling->setNextSibling(child);
} else
setFirstChild(child);

if (beforeChild) { beforeChild->setPreviousSibling(child); child->setNextSibling(beforeChild); } else setLastChild(child); child->setParent(this);

if (child->isOverflowOnly())
dirtyOverflowList();

if (!child->isOverflowOnly() || child->firstChild()) {
// Dirty the z-order list in which we are contained. The stackingContext() can be null in the
// case where we're building up generated content layers. This is ok, since the lists will start
// off dirty in that case anyway.
RenderLayer* stackingContext = child->stackingContext();
if (stackingContext)
stackingContext->dirtyZOrderLists();
}

child->updateVisibilityStatus();
if (child->m_hasVisibleContent || child->m_hasVisibleDescendant)
childVisibilityChanged(true);
}

static void addLayers(RenderObject* obj, RenderLayer* parentLayer, RenderObject*& newObject,
RenderLayer*& beforeChild)
{
if (obj->hasLayer()) {
if (!beforeChild && newObject) {
// We need to figure out the layer that follows newObject. We only do
// this the first time we find a child layer, and then we update the
// pointer values for newObject and beforeChild used by everyone else.
beforeChild = newObject->parent()->findNextLayer(parentLayer, newObject);
newObject = 0;
}
parentLayer->addChild(obj->layer(), beforeChild);
return;
}

for (RenderObject* curr = obj->firstChild(); curr; curr = curr->nextSibling())
addLayers(curr, parentLayer, newObject, beforeChild);
}

void RenderObject::addLayers(RenderLayer* parentLayer, RenderObject* newObject)
{
if (!parentLayer)
return;

RenderObject* object = newObject;
RenderLayer* beforeChild = 0;
WebCore::addLayers(this, parentLayer, object, beforeChild);
}

void RenderObject::removeLayers(RenderLayer* parentLayer)
{
if (!parentLayer)
return;

if (hasLayer()) {
parentLayer->removeChild(layer());
return;
}

for (RenderObject* curr = firstChild(); curr; curr = curr->nextSibling())
curr->removeLayers(parentLayer);
}

void RenderObject::moveLayers(RenderLayer* oldParent, RenderLayer* newParent)
{
if (!newParent)
return;

if (hasLayer()) {
if (oldParent)
oldParent->removeChild(layer());
newParent->addChild(layer());
return;
}

for (RenderObject* curr = firstChild(); curr; curr = curr->nextSibling())
curr->moveLayers(oldParent, newParent);
}

通过上面一组方法我们可以了解到拥有RenderLayer对象的RenderObject对象，按照Render树中最近的原则将含有的RenderLayer对象依Render树对应的父子关系组织RenderLayer树，RenderLayer对象的存在是依附于RenderObject对象而存在。

RenderView对象拥有对应的RenderLayer对象，同时其作为RenderLayer树根。

3、RenderLayer树与Render树的关系
通过RenderContainer::addChild方法回过头再来具体看看Render树自身的构成。
void RenderContainer::addChild(RenderObject* newChild, RenderObject* beforeChild)
{
bool needsTable = false;
//检查是否为Table的情况
if (needsTable) {
......................................................
} else {
// just add it...
insertChildNode(newChild, beforeChild);
}
.........................................................
}

void RenderContainer::insertChildNode(RenderObject* child, RenderObject* beforeChild, bool fullInsert)
{
if (!beforeChild) {
appendChildNode(child);
return;
}

while (beforeChild->parent() != this && beforeChild->parent()->isAnonymousBlock())
beforeChild = beforeChild->parent();

if (beforeChild == m_firstChild)
m_firstChild = child;

RenderObject* prev = beforeChild->previousSibling();
child->setNextSibling(beforeChild);
beforeChild->setPreviousSibling(child);
if(prev) prev->setNextSibling(child);
child->setPreviousSibling(prev);

child->setParent(this);

if (fullInsert) {
// Keep our layer hierarchy updated. Optimize for the common case where we don't have any children
// and don't have a layer attached to ourselves.
RenderLayer* layer = 0;
if (child->firstChild() || child->hasLayer()) {
layer = enclosingLayer(); child->addLayers(layer, child);
}

// if the new child is visible but this object was not, tell the layer it has some visible content
// that needs to be drawn and layer visibility optimization can't be used
if (style()->visibility() != VISIBLE && child->style()->visibility() == VISIBLE && !child->hasLayer()) {
if (!layer)
layer = enclosingLayer();
if (layer)
layer->setHasVisibleContent(true);
}
...........................................................
}

child->setNeedsLayoutAndPrefWidthsRecalc();
if (!normalChildNeedsLayout())
setChildNeedsLayout(true); // We may supply the static position for an absolute positioned child.
.................................................................
}
通过上面代码的了解我们知道通过addChild不仅维护Render树的构成，同时会将拥有的RenderLayer树构建起来。

4、RenderLayer树的作用
RenderLayer树的构建为渲染阶段处理z-index、opacity、overflow、scrollbar等打下一定的基础，在我们了解渲染的处理过程时我们再来深入的了解。

在这里我们初步的了解到在构建Render树的同时会维护一颗RenderLayer树，为分层布局、渲染作准备。

三、总结
其实WebKit涉及网页布局方面的数据结构还有关于SVG方面的，但通过上面的理解，如果对SVG感兴趣的话，应该对理解SVG有一定的参考作用。当然数据结构方面还有相当多的内容未提及，这里只是列出一些关键类或结构，以便有个整体的抽象认识，希望能对了解WebKit的网页布局渲染有一定的基础性作用。

四、参考资源
The WebKit Open Source Project

WebKit网页布局实现之主要数据结构篇

2008-11-29T13:41:00.001+08:00

在有了对CSS网页布局标准及相关概念的认识之后，我们可以更加深入的理解WebKit究竟是如何实现其网页布局，同时实现对CSS布局标准的支持。
毕竟标准归标准，要高效的实现这些标准，不同的实现肯定有其不同的实现方式，就像不同的Web服务器对HTTP协议标准的实现有所不同一样，当然不同的实现也会增加一些自身特有的属性。
下面我们从数据结构的角度来了解WebKit中为实现网页布局所设计的主要类结构及其主要方法。

一、Render树的构成
在我们编写网页及使用JS的时候，大概都知道DOM树及其主要构成，了解到DOM树的构建其实质是对一个html或xml文件的内容采取树结构的方式来组织及描述，不同的标签及其在文档中的位置决定了其在整颗DOM树的地位及属性，针对具体DOM树的构成及不同树节点的描述，可以参考有关DOM的相关标准等，以后有机会我们也会单独来了解。

也许对于Render树大家就不那么了解了，简单的说来，它是对DOM树更进一步的描述，其描述的内容主要与布局渲染等CSS相关属性如left、top、width、height、color、font等有关，因为不同的DOM树结点可能会有不同的布局渲染属性，甚至布局时会按照标准动态生成一些匿名节点，所以为了更加方便的描述布局及渲染，WebKit内核又生成一颗Render树来描述DOM树的布局渲染等特性，当然DOM树与Render树不是一一对应，但可以相互关联，下面分别描述其主要节点：

1、基类RenderObject
RenderObject作为所有Render树节点的基类，完全类似与DOM树中的Node基类，它是构成Render树的基础，作用非比寻常，其中包含了构成Render树所可能涉及到的一些基本属性及方法，内容相当多，其主要数据成员及方法分别如下：

RenderObject主要数据成员

图一

其中成员m_parent、m_previous、m_next为构建Render树设置好关联基础；
m_Node则为DOM树中对应的节点；
m_style成员则描述该节点对应的各种CSS基本属性数据，下面会单独介绍；
至于其他的诸如m_positioned、m_isText、m_inline、m_floating、m_replaced等则描述其特性，就像CSS标准对不同元素的属性分类定义一样，从字面上我们就可以上一节WebKit网页布局实现之基本概念及标准篇中可以找到它们这么定义的踪影。

成员m_needsPositionedMovementLayout、m_normalChildNeedsLayout、m_posChildNeedsLayout、m_needsLayout等主要用来描述该RenderObject是否确实需要重新布局；
当一个新的RenderObject对象插入到Render树的时候，它会设置其m_needsLayout属性为true，同时会根据该RenderObject对象在祖先RenderObject看来是一个positioned(拥有positiong:absolute或fixed属性)状态的孩子，如是则将相应祖先RenderObject对象的属性m_posChildNeedsLayout设置为true;

如果是一个in-flow(positon:static或relative)状态的孩子，则将相应祖先RenderObject对象的属性m_normalChildNeedsLayout设置为true;

主要方法：
//与是否需要layout相关
bool needsLayout() const { return m_needsLayout || m_normalChildNeedsLayout ||m_posChildNeedsLayout; }
bool selfNeedsLayout() const { return m_needsLayout; }
bool posChildNeedsLayout() const { return m_posChildNeedsLayout; }
bool normalChildNeedsLayout() const { return m_normalChildNeedsLayout; }

//与基本属性相关
bool isFloating() const { return m_floating; }
bool isPositioned() const { return m_positioned; } // absolute or fixed positioning
bool isRelPositioned() const { return m_relPositioned; } // relative positioning
bool isText() const { return m_isText; }
bool isInline() const { return m_inline; } // inline object
bool isCompact() const { return style()->display() == COMPACT; } // compact object
bool isRunIn() const { return style()->display() == RUN_IN; } // run-in object
bool isDragging() const { return m_isDragging; }
bool isReplaced() const { return m_replaced; } // a "replaced" element (see CSS)

//与外部DOM关联相关
RenderView* view() const;
// don't even think about making this method virtual!
Node* element() const { return m_isAnonymous ? 0 : m_node; }
Document* document() const { return m_node->document(); }
void setNode(Node* node) { m_node = node; }
Node* node() const { return m_node; }

// RenderObject tree manipulation
//////////////////////////////////////////
virtual bool canHaveChildren() const;
virtual bool isChildAllowed(RenderObject*, RenderStyle*) const { return true; }
virtual void addChild(RenderObject* newChild, RenderObject* beforeChild = 0);
virtual void removeChild(RenderObject*);
virtual bool createsAnonymousWrapper() const { return false; }

// raw tree manipulation
virtual RenderObject* removeChildNode(RenderObject*, bool fullRemove = true);
virtual void appendChildNode(RenderObject*, bool fullAppend = true);
virtual void insertChildNode(RenderObject* child, RenderObject* before, bool fullInsert = true);
// Designed for speed. Don't waste time doing a bunch of work like layer updating and repainting when we know that our
// change in parentage is not going to affect anything.
virtual void moveChildNode(RenderObject*);

virtual void paint(PaintInfo&, int tx, int ty);

/*
* This function should cause the Element to calculate its
* width and height and the layout of its content
*
* when the Element calls setNeedsLayout(false), layout() is no
* longer called during relayouts, as long as there is no
* style sheet change. When that occurs, m_needsLayout will be
* set to true and the Element receives layout() calls
* again.
*/
virtual void layout() = 0;

其中很多方法如paint()、layout()等是虚拟的，不同的子类可以重载它；

其中方法container() 、containingBlock()、paint()、layout()很值得大家深入研究；

总的说来RenderObject基类定义一些通用属性、方法，以便维护、布局、渲染Render树。

2、子类RenderBox
RenderBox代表描述CSS标准中的Box Model，它继承自RenderObject;

RenderBox主要数据成员
图二

其主要重载了部分继承而来的方法。

3、子类RenderContainer
RenderContainer类用来描述可以拥有子RenderObject成员的容器类，它继承自RenderBox；

RenderContainer主要数据成员
图三

其主要重载了RenderObject提供的维护Render树新增、删除树节点等方面的方法。

4、子类RenderFlow
RenderFlow主要用来描述CSS标准中提到的能进行inline-flow、block-flow相关处理的Render树结点，它继承自RenderContainer；

RenderFlow主要数据成员
图四

其主要方法包括在flow的过程中创建、关联匿名对象等；

5、子类RenderBlock
RenderBlock代表CSS标准中的block-level元素，它继承自RenderFlow；

RenderBlock主要数据成员
图五

它维护了一组由它定位的positioned树节点，以及有关overflow方面的设置；
其主要重载了RenderObject继承下来的layout、paint等方法；

因为html中的body、div、p等标签对应RenderBlock类对象，其在Render树具有非常重要的地位，其layout、paint等方法的实现，往往是WebKit整个布局、渲染处理的发起中心，内容比较多并且复杂，以后有机会详解。

6、子类RenderInline
RenderInline代表inline-level元素，其继承自RenderFlow，主要重载了RenderObject关于inline-flow方面处理的方法，提供了splitFlow、splitInlines等处理自动换行的方法。

7、子类RenderText
RenderText代表对html中Text node对应的Render树节点，它直接继承自RenderObject；

RenderText主要数据成员
图六

它提供关于处理文字方面如显示文字、行高计算、整个Text node对应的宽度等；它没有重载layout方法，因为它自身的定位往往由RenderBlock、RenderInline父对象来处理；

8、子类RenderImage
RenderImage代表html中img标签对应的树节点，它继承自RenderBox；

RenderImage继承关系及主要数据成员
图七

其主要提供关于图片显示、大小设置等方面的处理，其中paintReplaced方法将其图片显示出来；

9、子类RenderView
RenderView对应整个html文档对象的树节点，可看成是Render树的根，它继承自RenderBlock；

RenderView主要数据成员
图八

其中m_frameview成员对应整个文档对应的FrameView，而m_widgets则包括了该文档可能包含的plugin插件等对应的Render树节点；

RenderView对象作为Render树的根，它往往随着Document对象的创建而创建，它的layout、paint方法的发起往往是整颗Render树布局、渲染处理的开始；其中也包含了对选择处理。

10、其他
整个Render树中涉及的树节点类型，还有很多如RenderButton、RenderTable、RenderMedia等；并且各个类的方法及数据成员非常多，这里只是初步列出主要的类及其主要方法，特别是可能涉及到布局、渲染方方面的方法，以便我们能从中大致WebKit布局、渲染所涉及的基本内容及方法。

二、CSS属性的描述
1、RenderStyle类
RenderObject对象的m_style成员为RenderStyle类对象，它往往用来描述一个RenderObject所可能涉及的CSS属性数据(如left、top、align、color、font等等)，其数据成员往往对应于CSS中定义的所有属性项，内容非常的庞杂，简单的说来就是将CSS标准中的所有属性按照一定分类定义到一个数据结构中。

2、RenderStyle类主要方法
为了获取、设置CSS属性所对应的值，RenderStyle类提供了所有的获取、设置CSS属性的方法如：
void setDisplay(EDisplay v) { noninherited_flags._effectiveDisplay = v; }
void setOriginalDisplay(EDisplay v) { noninherited_flags._originalDisplay = v; }
void setPosition(EPosition v) { noninherited_flags._position = v; }
void setFloating(EFloat v) { noninherited_flags._floating = v; }

void setLeft(Length v) { SET_VAR(surround,offset.left,v) }
void setRight(Length v) { SET_VAR(surround,offset.right,v) }
void setTop(Length v) { SET_VAR(surround,offset.top,v) }
void setBottom(Length v){ SET_VAR(surround,offset.bottom,v) }

void setWidth(Length v) { SET_VAR(box,width,v) }
void setHeight(Length v) { SET_VAR(box,height,v) }
等等。。。。

三、RenderObject及子类对象的生成
1、CSSParser
CSSParser类顾名思义，主要用来解析文本中各种CSS属性，并且有效的组织在一个RenderStyle对象中。
其主要方法parseValue、applyProperty的部分代码示例如下：
bool CSSParser::parseValue(int propId, bool important)
{
.....................................................
case CSSPropertyFloat:
// left | right | none | inherit + center for buggy CSS
if (id == CSSValueLeft || id == CSSValueRight ||
id == CSSValueNone || id == CSSValueCenter)
valid_primitive = true;
break;

case CSSPropertyClear: // none | left | right | both | inherit
if (id == CSSValueNone || id == CSSValueLeft ||
id == CSSValueRight|| id == CSSValueBoth)
valid_primitive = true;
break;

case CSSPropertyWebkitBoxAlign:
if (id == CSSValueStretch || id == CSSValueStart || id == CSSValueEnd ||
id == CSSValueCenter || id == CSSValueBaseline)
valid_primitive = true;
break;
.....................................................
case CSSPropertyWebkitBoxPack:
if (id == CSSValueStart || id == CSSValueEnd ||
id == CSSValueCenter || id == CSSValueJustify)
valid_primitive = true;
break;
....................................................
}

void CSSStyleSelector::applyProperty(int id, CSSValue *value)
{
case CSSPropertyOpacity:
HANDLE_INHERIT_AND_INITIAL(opacity, Opacity)
if (!primitiveValue || primitiveValue->primitiveType() != CSSPrimitiveValue::CSS_NUMBER)
return; // Error case.
// Clamp opacity to the range 0-1
m_style->setOpacity(min(1.0f, max(0.0f, primitiveValue->getFloatValue())));
return;
case CSSPropertyWebkitBoxAlign:
{
HANDLE_INHERIT_AND_INITIAL(boxAlign, BoxAlign)
if (!primitiveValue)
return;
EBoxAlignment boxAlignment = *primitiveValue;
if (boxAlignment != BJUSTIFY)
m_style->setBoxAlign(boxAlignment);
return;
}
...................................................
}

2、CSSStyleSelector类
CSSStyleSelector类其作用是基于所有用户的stylesheets集合为一个给定的DOM Element创建出其对应的RenderStyle对象。其主要功能由方法RenderStyle* styleForElement(Element*, RenderStyle* parentStyle = 0, bool allowSharing = true, bool resolveForRootDefault = false);来实现。

3、构建Render树
在构建DOM树的过程中，Dom Element对象创建完后，往往通过attach方法来创建RenderObject对象，进而构建Render树。
其基本实现流程如下：void Element::attach()=>createRendererIfNeeded()=>createRenderer；

RenderObject* Element::createRenderer(RenderArena* arena, RenderStyle* style)
{
if (document()->documentElement() == this && style->display() == NONE) {
// Ignore display: none on root elements. Force a display of block in that case.
RenderBlock* result = new (arena) RenderBlock(this);
if (result)
result->setAnimatableStyle(style);
return result;
}
return RenderObject::createObject(this, style);
}

RenderObject* RenderObject::createObject(Node* node, RenderStyle* style)
{
Document* doc = node->document();
RenderArena* arena = doc->renderArena();

const ContentData* contentData = style->contentData();
if (contentData && !contentData->m_next && contentData->m_type == CONTENT_OBJECT && doc != node) {
RenderImageGeneratedContent* image = new (arena) RenderImageGeneratedContent(node);
image->setStyle(style);
if (StyleImage* styleImage = contentData->m_content.m_image)
image->setStyleImage(styleImage);
return image;
}

RenderObject* o = 0;

switch (style->display()) {//往往在CSSStyleSelector::styleForElement或CSSStyleSelector::adjustRenderStyle时//调用setDisplay()以确定其display属性。
case NONE:
break;
case INLINE:
o = new (arena) RenderInline(node);
break;
case BLOCK:
o = new (arena) RenderBlock(node);
break;
case INLINE_BLOCK:
o = new (arena) RenderBlock(node);
break;
case LIST_ITEM:
o = new (arena) RenderListItem(node);
break;
case RUN_IN:
case COMPACT:
o = new (arena) RenderBlock(node);
break;
case TABLE:
case INLINE_TABLE:
o = new (arena) RenderTable(node);
break;
case TABLE_ROW_GROUP:
case TABLE_HEADER_GROUP:
case TABLE_FOOTER_GROUP:
o = new (arena) RenderTableSection(node);
break;
case TABLE_ROW:
o = new (arena) RenderTableRow(node);
break;
case TABLE_COLUMN_GROUP:
case TABLE_COLUMN:
o = new (arena) RenderTableCol(node);
break;
case TABLE_CELL:
o = new (arena) RenderTableCell(node);
break;
case TABLE_CAPTION:
o = new (arena) RenderBlock(node);
break;
case BOX:
case INLINE_BOX:
o = new (arena) RenderFlexibleBox(node);
break;
}
return o;
}
这样就不同的DOM树节点结合不同的显示属性，创建出不同的RenderObject子类对象，进而形成一个Render树。

四、总结
其实WebKit涉及网页布局方面的数据结构远不止这些，其中有的也比较复杂，这里只是列出自己认为较为重要的一小部分，希望能对了解WebKit的网页布局渲染有一定的基础性作用。。

五、参考资源
The WebKit Open Source Project

WebKit网页布局实现之基本概念及标准篇

2008-11-22T21:38:00.002+08:00

作为一个广受好评的浏览器引擎，其网页布局的质量(包括速度、效率、符合标准度等)往往是其关键，那么WebKit究竟是如何布局网页上的所有元素(包括滚动条、文字、图片、按钮、下拉框等)呢？其主要数据结构及流程都包括哪些呢？其布局的基本概念及标准都有哪些呢？下面分别介绍WebKit对其实现及运用。我们首先从关于布局的基本概念及标准的认识开始。

一、CSS布局相关标准介绍
其实我们对要素的布局都有不同程度的了解如我们使用Office时经常使用对一段文字的居中、靠左等操作，复杂一点有设置编号及文字与图片的环绕对应关系等，其实布局的关键在于确定页面元素的显示位置及大小，而页面中主要包括有文字、图片、按钮等页面元素，为了有效的组织布局这些页面元素，一些专家学者经过多年的摸索，总结并设计了布局这些元素所涉及的一些规则及标准，这就是CSS标准。

其中Visual formatting model details对其主要规则进行过具体描述，通过下面相关总结和汇总希望能对其主要要点有一定的认识与理解。

二、布局页面的基本概念
要在一块指定的画布(或窗口)上布局一些要素，往往需要按从上到下或从左到右(或从右到左)的规则来布局这些元素，而有些元素则可以包含其他元素，当作布局容器来使用。其中浏览网页的原生窗口就可看作一个布局容器的根。

由于页面内容的大小可能超过原生窗口提供的显示区域的大小，CSS中称页面上当前显示出来的区域为ViewPort，这个ViewPort相对页面的原始位置可通过滚动条来调整；

CSS标准中定义了html中的一些标签所对应的元素可当成容器使用的，以建立坐标定位所包含的元素如p、div，CSS中称这样的元素为block-level元素，相邻的block-level元素往往从上到下垂直排列；

而其他象i、a、b、span等标签及text node对应的元素则缺省为inline-level元素，inline-level元素不能用来定位其他元素，但可以包含其他同为inline-level元素，相邻的inline-level元素，往往按照从左到右或从右到左的水平方向排列；

block-level元素所包含的元素往往要么全为block-level元素要么全为inline-level元素，在一定条件下布局时可能会产生匿名block-level元素；

而页面上的每一个元素必须对应一个布局容器称之为Containing Block，只有block-level元素可以成为Containing Block；

一个Containing Block元素究竟包含哪些子元素或者某一元素的Containing Block元素究竟是谁，由其自身position属性及其在文档层次结构中所处的位置所确定，下一节会描述相关内容；

而每一个元素至少包含一个Box模型即由margin、border、padding、content width/height等属性所能描述的矩形区域；而这块区域相对于布局容器的坐标top、left，往往由布局容器按照block-flow、inline-flow等规则布局该元素时确定；

CSS中将布局block-level元素的过程称为block-flow；将布局inline-level相关元素的过程称为line-flow；

而CSS对html中诸如标签frame、image、object、embed、form等对应的元素称为replaced元素，它表示这些元素的内部布局不由Css来定义，而由浏览器来实现，而这些元素从外部来看相当于block-level元素，但可通过设置display:inline将其从外部看设为inline-level元素；

不同的html标签元素可以通过display:inline、display:block、display:inline-block等方式来调整其缺省block-level或inline-level属性；

三、如何确定页面元素显示位置
一个html标签元素的position属性可以设置为static、relative、fixed、absolute、inherit等，所有元素缺省为static，其Containing Block布局容器元素为最近的祖先block-level元素，其属性left、top、right、bottom不起作用；

position属性为relative的元素同static属性元素一样，但其left、top等属性可以有效，其坐标相对于布局容器而言；

position属性为absolute的元素的布局容器元素是最近的除了其属性不为static的祖先block-level元素；

position属性为fiexed的元素的布局容器元素是往往是根布局容器，但其定位坐标需要根据ViewPort的位置作相应调整；

一旦确定了其Containing Block布局容器，同时结合其自身的block-level或inline-level特性，布局时根据block flow和inline flow规则就可确定其起始位置，其中inline-level元素可在其布局容器提供的区域内自动换行；而block-level元素可在其布局容器提供的区域内自动换一个段落。

另外float属性为left或right元素较为特殊，则不遵守上面的规则，该元素让在其高度范围内的其他元素始终在其左边或右边。

四、如何确定页面元素大小
对于有定义其宽高的页面元素，则按照其定义的宽高来确定其大小，而对于象text node这样的inline-level则需要结合其字体大小及文字的多少等来确定其对应的宽高；如果页面元素所确定的宽高超过了布局容器Containing Block所能提供的宽高，同时其overflow属性为visible或auto，则会提供滚动条来保证可以显示其所有内容。

除非定义了页面元素的宽高，一般说来页面元素的宽高是在布局的时候通过相关计算得出来的。

五、如何理解z-index的使用
页面元素z-index属性的出现，引入了页面元素三维布局的思路，提出分层的概念，具有同一z-index属性的所有元素按照上面提到的二维布局方式(确定其位置及大小)来布局，而不同z-index所代表的层的元素有可能被其他层的元素所覆盖。每一个页面元素只能处在一个z-index所对应的层中，所有元素缺省z-index为0。

六、总结
CSS布局标准的内容相当多，有的还相当复杂，这里只是初步的了解其基本原则及要素，也未必在各种条件下都成立，希望能为我们能从WebKit代码去了解WebKit究竟是如何布局页面元素作一定准备而已，如果要想对CSS标准有更深入的具体理解，只有不断的练习及阅读理解CSS布局标准文档。

七、参考资源
CSS Wiki
CSS Specification
CSS basic box model
Visual formatting model details

也谈WebKit、Gecko使用图形库

2008-10-29T20:58:00.000+08:00

阅读了Graphics in Google Chrome之后，觉得作为浏览器内核WebKit、Gecko，为了能高效美观的显示页面的内容，选择适当的图形库非常重要。如果图形库选择不当，往往会导致页面上显示的文字、图片不美观，看起来总让人觉得别扭，更为糟糕的是排列布局出现紊乱，简直无法阅览。

从浏览器发展的历史来看，IE系列浏览器的网页布局、文字图片显示的美观程度还是相当高的，也许这与Microsoft图形显示方面的功力相关，到目前为止linux桌面显示还是与传统的windows桌面显示有相当的差距。

相比较Firefox1.5，Firefox3.0图形显示方面也有相当大的进步，这应该归功于完全采取Cario图形库来显示页面，目前应当完全达到了IE6的显示效果。可见图形显示的好与坏，直接决定了一款浏览器的质量以及用户接受程度。那究竟什么是图形库？其主要功能是什么？目前WebKit、Gecko可使用哪些图形库？它们在浏览器中是如何发挥其应有的作用呢？

一、图形库概述及其主要功能
A graphics library is a program designed to aid in rendering computer graphics to a monitor. This typically involves providing optimized versions of functions that handle common rendering tasks.

This can be done purely in software and running on the CPU, common in embedded systems, or being hardware accelerated by a GPU, more common in PCs. By employing these functions, a program can assemble an image to be output to a monitor. This relieves the programmer of the task of creating and optimizing these functions, and allows them to focus on building the graphics program.

目前主要的图形库有：
windows提供的GDI/GDI+、DirectX、OpenGL；
支持X的有Cario、GTK、QT、OpenGL；
其他的还有Skia(google提供)、Quartz 2D(apple提供)、wxWidget等；

一般说来图形库只提供绘画图形，渲染文字、图片等，不管是2D还是3D，其往往不提供消息处理，简单的说来就是如何高效的在一块指定的画布上将线条、文字、图片显示出来，其中往往涉及字体、颜色等；典型的图形库如GDI/GDI+、Cario、DirectX、Quartz 2D等；

而按钮、菜单、窗口等图形组件往往是基于图形库的基础上绘画出来的并有相对固定形状，同时一般具有消息处理功能；相关实现有GTK、QT、wxWidget、windows组件等；

其中GTK、QT、wxWidget、Skia等不仅提供图形组件，同时提供图形库的功能；而Cario则是一个纯粹的图形库，类似与Quartz 2D，目前GTK2则完全基于Cario来实现；

由于浏览器页面元素的数量存在不确定性，将页面上的一些元素对应成图形组件可能导致一个页面使用组件过多的问题(早期的IE就曾出现使用GDI对象过多的现象)。因此尽可能的将一个页面的所有元素显示在一个图形组件上，至于其显示交给图形库来处理，其消息响应交互交给DOM及原生窗口消息循环来完成。

从这里我们可以进一步的确认图形库在浏览器中的重要性，以及随着用户需求的增加及硬件的提升，浏览器中使用3D效果应该是一个大的方向。

二、Gecko中使用图形库Cario
1、Cario概述
Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL (through glitz), XCB, BeOS, OS/2, and DirectFB.

Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension).

其主要优点在于其在X、Win32、Quartz的基础上统一了图形库的操作方式，同时支持PS、PDF、SVG、PNG/JPEG等图像格式的输出，极大的方便页面的再次利用，在glitz的支持下支持部分3D效果。

2、Cario在Gecko中的使用
首先提供一个gfxASurface抽象类，代表一块可以作画的画布；提供一个gfxContext类，它用来管理究竟如何作画，如画圆形、旋转，维护画布的状态、当前颜色、路径等，其往往需要一个gfxASurface子类实例来初始化；

其次不同的图形输出实现不同的gfxASurface子类如gfxWindowsSurface、gfxXlibSurface、gfxQuartzSurface、gfxGlitzSurface、gfxQuartzPDFSurface、gfxPSSurface等；

其次提供一个DeviceContextImpl类实现nsIDeviceContext接口，以描述指定原生Widget相关的字体属性及创建可以在该原生Widget上作画的nsIRenderingContext接口实现；

而nsThebesRenderingContext类实现了nsIRenderingContext接口，以供外部(如不同的DOM Node页面元素对应的不同Frame)在其上显示文字、图像、作图形等;

然后当解析、布局完DOM页面元素后需要画出不同的页面元素时则由DeviceContextImpl类实例来创建nsThebesRenderingContext类实现，并初始化它，其初始化代码如下：
nsThebesRenderingContext::Init(nsIDeviceContext* aContext, nsIWidget *aWidget)
{
nsThebesDeviceContext *thebesDC = static_cast(aContext);

mDeviceContext = aContext;
mWidget = aWidget;

mThebes = new gfxContext(aWidget->GetThebesSurface());

return (CommonInit());
}

nsThebesRenderingContext类中包含：
nsRefPtr mThebes;
nsCOMPtr mWidget;
而mThebes初始时需要的gfxASurface子类实例则由原生的Widget的GetThebesSurface()方法来实现，针对不同的图形输出实现返回不同的gfxASurface子类如gfxWindowsSurface、gfxXlibSurface、gfxQuartzSurface、gfxGlitzSurface的实例；

最后将nsThebesRenderingContext类实现实例返回，由不同的Frame自身决定如何在提供的画布上画出其表示的内容。

至于不同的Frame应该怎么画(显示)由其本身及CSS来决定，而nsIRenderingContext接口提供了所有可能用到的作画方式，具体每一个方法的含义需详细了解。

nsIRenderingContext接口提供了一组方法，向外部提供了图形库能实现的功能，其相当于一个中间层，从图形库的角度看，通过这个接口向外部提供了其能提供的功能；从需要图形功能的外部看，可不关心具体图形库的实现，而直接通过该接口使用图形库能提供的功能。

让我们来看看nsIRenderingContext接口究竟有哪些主要方法？
// RenderingContext interface
class nsIRenderingContext : public nsISupports
{
public:
.........................................................................
/**
* Initialize the RenderingContext
* @param aContext the device context to use.
* @param aWidget the widget to hook up to
* @result The result of the initialization, NS_Ok if no errors
*/
NS_IMETHOD Init(nsIDeviceContext* aContext, nsIWidget *aWidget) = 0;
/**
* Get the DeviceContext that this RenderingContext was initialized
* with. This function addrefs the device context. Though it might
* be better if it just returned it directly, without addrefing.
* @result the device context
*/
NS_IMETHOD GetDeviceContext(nsIDeviceContext *& aDeviceContext) = 0;

/**
* Sets the forground color for the RenderingContext
* @param aColor The color to set the RenderingContext to
*/
NS_IMETHOD SetColor(nscolor aColor) = 0;

/**
* Get the forground color for the RenderingContext
* @return The current forground color of the RenderingContext
*/
NS_IMETHOD GetColor(nscolor &aColor) const = 0;

/**
* Sets the font for the RenderingContext
* @param aFont The font to use in the RenderingContext
*/
NS_IMETHOD SetFont(const nsFont& aFont, nsIAtom* aLangGroup) = 0;

/**
* Sets the font for the RenderingContext
* @param aFontMetric The font metrics representing the
* font to use in the RenderingContext
*/
NS_IMETHOD SetFont(nsIFontMetrics *aFontMetrics) = 0;

/**
* Get the current fontmetrics for the RenderingContext
* @return The current font of the RenderingContext
*/
NS_IMETHOD GetFontMetrics(nsIFontMetrics *&aFontMetrics) = 0;

/**
* Add in a translate to the RenderingContext's transformation matrix
* @param aX The horizontal translation
* @param aY The vertical translation
*/
NS_IMETHOD Translate(nscoord aX, nscoord aY) = 0;

/**
* Add in a scale to the RenderingContext's transformation matrix
* @param aX The horizontal scale
* @param aY The vertical scale
*/
NS_IMETHOD Scale(float aSx, float aSy) = 0;

/**
* Draw a line
* @param aXO starting horiztonal coord in twips
* @param aY0 starting vertical coord in twips
* @param aX1 end horiztonal coord in twips
* @param aY1 end vertical coord in twips
*/
NS_IMETHOD DrawLine(nscoord aX0, nscoord aY0, nscoord aX1, nscoord aY1) = 0;

/**
* Draw a rectangle
* @param aRect The rectangle to draw
*/
NS_IMETHOD DrawRect(const nsRect& aRect) = 0;

/**
* Draw a string in the RenderingContext
* @param aString The string to draw
* @param aLength The length of the aString
* @param aX Horizontal starting point of baseline
* @param aY Vertical starting point of baseline.
* @param aSpacing inter-character spacing to apply
*/
NS_IMETHOD DrawString(const char *aString, PRUint32 aLength,
nscoord aX, nscoord aY,
const nscoord* aSpacing = nsnull) = 0;

/*
* Tiles an image over an area
* @param aImage Image to tile
* @param aXImageStart x location where the origin (0,0) of the image starts
* @param aYImageStart y location where the origin (0,0) of the image starts
* @param aTargetRect area to draw to
* @param aSubimageRect the subimage (in tile space) which we expect to
* sample from; may be null to indicate that the whole image is
* OK to sample from
*/
NS_IMETHOD DrawTile(imgIContainer *aImage,
nscoord aXImageStart, nscoord aYImageStart,
const nsRect * aTargetRect,
const nsIntRect * aSubimageRect) = 0;
...............................................................................
};

其中DrawString、DrawTile方法最常用，其分别对应如何显示文字及图像。
针对图形库显示文字的基本原理可以参考Font technology and Freetype及FreeType Glyph Conventions。

至于图形库如何显示不同格式的图像可参考如gif、jpeg、png等。

Gecko对Cario的使用还体现在对canvas标签的实现，具体可参考nsCanvasRenderingContext2D.cpp、nsHTMLCanvasElement.cpp等。

三、WebKit中使用图形库
1、WebKit支持的图形库
目前WebKit支持的图形库包括Cairo、Gtk、Qt、Wx、Cg、Mac、Skia等，虽然不同的图形库能支持不同的平台，但其在不同平台上的显示效果也不尽相同。至于在一个指定的平台上究竟使用何种库，则显示出很大的灵活性。就目前来看，在windows平台上可选的图形库有Cairo、Qt、Wx、Cg、Skia等，其中Graphics in Google Chrome阐述了Chrome关于图形库的选择。

其实从WebKit的角度来看，它通过提供一组与Gecko中nsIRenderingContext类似的公共图形接口，而不同的图形库则根据自身的不同实现了这些公共图形接口，以提供给WebCore元素使用，从而可以让WebKit支持不同的图形库。

2、WebKit支持不同图形库的实现
在WebKit中提供了一个GraphicsContext类，其中包括所有的图形接口，完全类似nsIRenderingContext，针对不同平台的特性，其定义中包含一些不同平台特有的
宏及元素定义。

在目录webcore\platform\graphics\下的子目录Cairo、Cg、Gtk、Mac、Qt、Win、Wx分别提供了GraphicsContext类部分方法的实现，而公共的实现则在webcore\platform\graphics\GraphicsContext.cpp中提供。

其中我们非常值得关注的方法有drawText与drawImage，其实现如下：
void GraphicsContext::drawText(const TextRun& run, const IntPoint& point, int from, int to)
{
if (paintingDisabled())
return;

font().drawText(this, run, point, from, to);
}

void GraphicsContext::drawImage(Image* image, const FloatRect& dest, const FloatRect& src, CompositeOperator op, bool useLowQualityScale)
{
if (paintingDisabled() || !image)
return;

float tsw = src.width();
float tsh = src.height();
float tw = dest.width();
float th = dest.height();

if (tsw == -1)
tsw = image->width();
if (tsh == -1)
tsh = image->height();

if (tw == -1)
tw = image->width();
if (th == -1)
th = image->height();

if (useLowQualityScale) {
save();
setUseLowQualityImageInterpolation(true);
}
image->draw(this, FloatRect(dest.location(), FloatSize(tw, th)), FloatRect(src.location(), FloatSize(tsw, tsh)), op);
if (useLowQualityScale)
restore();
}

最终的实现转交给类Font、Image的方法drawText、draw来实现，而不同实现如Cairo、Cg、Gtk、Mac、Qt、Win、Wx则会针对类Font、Image分别提供部分对应的实现，而公共的实现则在webcore\platform\graphics\Font.cpp及Image.cpp中提供。

3、不同平台GraphicsContext实例创建及使用
GraphicsContext创建的时机往往在对应平台的WebView获得Paint消息事件时，进而将该GraphicsContext类实例传递给FrameView及其不同的RenderObject实例，由不同的RenderObject实例来决定究竟如何来显示自身的内容，而GraphicsContext类实例提供了各种的显示文字、图形、图像的方法以供RenderObject实例调用。其调用关系基本上与Gecko中的不同Frame对象使用nsIRenderingContext接口方法类似。

创建GraphicsContext实例的示例如下：
//Gtk
static gboolean webkit_web_view_expose_event(GtkWidget* widget, GdkEventExpose* event)
{
WebKitWebView* webView = WEBKIT_WEB_VIEW(widget);
WebKitWebViewPrivate* priv = webView->priv;

Frame* frame = core(webView)->mainFrame();
GdkRectangle clip;
gdk_region_get_clipbox(event->region, &clip);
cairo_t* cr = gdk_cairo_create(event->window);
GraphicsContext ctx(cr);
ctx.setGdkExposeEvent(event);
if (frame->contentRenderer() && frame->view()) {
frame->view()->layoutIfNeededRecursive();

if (priv->transparent) {
cairo_save(cr);
cairo_set_operator(cr, CAIRO_OPERATOR_CLEAR);
cairo_paint(cr);
cairo_restore(cr);
}

frame->view()->paint(&ctx, clip);
}
cairo_destroy(cr);

return FALSE;
}

//win
void WebView::paintIntoBackingStore(FrameView* frameView, HDC bitmapDC, const IntRect& dirtyRect)
{
LOCAL_GDI_COUNTER(0, __FUNCTION__);

RECT rect = dirtyRect;

#if FLASH_BACKING_STORE_REDRAW
HDC dc = ::GetDC(m_viewWindow);
OwnPtr yellowBrush = CreateSolidBrush(RGB(255, 255, 0));
FillRect(dc, &rect, yellowBrush.get());
GdiFlush();
Sleep(50);
paintIntoWindow(bitmapDC, dc, dirtyRect);
::ReleaseDC(m_viewWindow, dc);
#endif

FillRect(bitmapDC, &rect, (HBRUSH)GetStockObject(WHITE_BRUSH));
if (frameView && frameView->frame() && frameView->frame()->contentRenderer()) {
GraphicsContext gc(bitmapDC);
gc.save();
gc.clip(dirtyRect);
frameView->paint(&gc, dirtyRect);
gc.restore();
}
}

//wx
void wxWebView::OnPaint(wxPaintEvent& event)
{
if (m_beingDestroyed || !m_impl->frame->view() || !m_impl->frame)
return;

wxAutoBufferedPaintDC dc(this);

if (IsShown() && m_impl->frame && m_impl->frame->document()) {
#if USE(WXGC)
wxGCDC gcdc(dc);
#endif

if (dc.IsOk()) {
wxRect paintRect = GetUpdateRegion().GetBox();

WebCore::IntSize offset = m_impl->frame->view()->scrollOffset();
#if USE(WXGC)
gcdc.SetDeviceOrigin(-offset.width(), -offset.height());
#endif
dc.SetDeviceOrigin(-offset.width(), -offset.height());
paintRect.Offset(offset.width(), offset.height());

#if USE(WXGC)
WebCore::GraphicsContext* gc = new WebCore::GraphicsContext(&gcdc);
#else
WebCore::GraphicsContext* gc = new WebCore::GraphicsContext((wxWindowDC*)&dc);
#endif
if (gc && m_impl->frame->contentRenderer()) {
if (m_impl->frame->view()->needsLayout())
m_impl->frame->view()->layout();

m_impl->frame->paint(gc, paintRect);
}
}
}
}

//Qt
void QWebFrame::render(QPainter *painter, const QRegion &clip)
{
if (!d->frame->view() || !d->frame->contentRenderer())
return;

d->frame->view()->layoutIfNeededRecursive();

GraphicsContext ctx(painter);
QVector vector = clip.rects();
WebCore::FrameView* view = d->frame->view();
for (int i = 0; i <>paint(&ctx, vector.at(i));
}

/*!
Render the frame into \a painter.
*/
void QWebFrame::render(QPainter *painter)
{
if (!d->frame->view() || !d->frame->contentRenderer())
return;

d->frame->view()->layoutIfNeededRecursive();

GraphicsContext ctx(painter);
WebCore::FrameView* view = d->frame->view();
view->paint(&ctx, view->frameGeometry());
}

4、WebKit 3D Port实现
在Clutter WebKit port中提供了WebKit 对3D Port的支持与实现，其实现类似于Gtk+/Cairo图形库的实现，但其3D效果仅实现在Port层，没有对页面上的元素如文字、图像实现3D效果支持。

这里只是简单的了解WebKit中如何整合不同的图形库及其与WebCore的交互。要想更加深入的了解页面上的文字、图形、图像究竟是如何显示出来的，则需要更进一步的针对不同平台库进行学习与了解。

WebKit中也支持canvas标签，该标签提供的接口与Gecko能提供的几乎一致，其具体实现可参考webcore\html \CanvasRenderingContext2D.cpp，结合GraphicsContext类的实现，应该能对canvas标签的实现有充分的理解。

四、总结
其实关于图形库及其使用的内容非常的多，而对浏览器内核来讲能对图形库进行高效使用也是非常重要的一部分，所以在这里所谈到的内容也许只是一些皮毛，但希望能在此开阔一下了解浏览器内核特别是图形库使用方面的思路。

五、参考资源
Wiki Rendering (computer graphics)
Wiki Cairo
Cairo HomePage
Wiki Qt
Wiki GTK+
Wiki wxWidgets
Wiki GDI
Wiki DirectX
Wiki Quartz 2D
Wiki OpenGL
Wiki OpenGL ES

Wiki gif
Wiki jpeg
Wiki png

Clutter Toolkit
Font technology and Freetype

Javascript调试工具

2008-10-18T15:58:00.000+08:00

Javascript作为一门脚本语言，最近受到人们越来越多的关注，例如Chrome推出V8、Mozilla推出TracMonky、WebKit推出SquirrelFish等等Javascript引擎，使得Javascript实现的性能不断的得到提升，甚至更有Microsoft高级开发人员认为Silverlight的对手竟然是Javascript，而不是Flash，还有诸如Gears、prototype、dojo、jquery等JS库的大力发展，可见Javascript的应用前景相当光明。

但是其复杂性也会越来越高，Web开发人员遇到大量的Javascript往往会觉得头痛，甚至觉得Javascript比较诡异而又神奇，从而难以彻底掌握应用好。不过要掌握好Javascript的应用，其调试是个不得不提的话题，很早以前Microsoft就推出了Script Debugger工具，但Web开发人员使用起来还不是特别的方便，作为一个Web开发应用平台的推动者，Mozilla社区却为我们提供了更优秀的Javascript Debugger工具Venkman、Firebug，它们的出现极大的方便了Javascript的调试，让开发人员爱不释手，将它们比着Web开发的瑞士军刀一点都不为过。

今天我们从Venkman、Firebug的使用入手，进而分析其实现原理，同时了解了解WebKit内核的Javascript调试工具及其实现原理。

一、安装使用Venkman、Firebug
如果你还没使用过它们，现在就该动手了。赶快去Mozilla Addon中心下载JavaScript Debugger Venkman、Firebu g吧。作为Firefox的extension，Venkman、Firebug不管是下载、安装、更新及使用，都已经与Firefox进行有机结合，使用起来非常的方便。

作为调试工具，其基本的功能不外乎设置断点、Step-in、Step-out、Step-over、Continue、查看参数及调用堆栈等。操作上与用VS调试C/C++代码几乎一致，但考虑各自特点的不同，下面总结一下个人对这两个工具的使用感受：

1、Firebug非常适合普通的Web开发人员，它可以非常方便、直观的查看html、js、dom等详细内容，查看js执行效率以及网络获取状态等，更值得称赞的是调试时动态更改html、js、dom的内容后，浏览效果会及时显现，从而大大的提供修改、调试效率。

网上一篇《初识Firebug 全文 — firebug的使用》很值得刚接触者参考参考。
有关Firebug更加详细的内容请参考Firebug网站。

2、Venkman非常适合与Firefox开发相关的开发者如extension开发者等，虽然它的使用没有Firebug那么的直观方便动态更改内容，但其提供了完整的命令行调试模式，这一点与python的pdb很类似；更为突出的是它可以调试Firefox本身以及各种extensions(即chrome源文件，这一点目前Firebug还难以方便的处理)，同时提供方便的过滤功能。有了Venkman，开发研究Firefox(当然包括各种有特色的extension及js库等)也就得心应手。

其中Learning the JavaScript debugger Venkman对Venkman有非常详细的介绍，很值得好好阅读阅读。

有关Venkman更加详细的使用请参考其 HomePage。

3、使用Venkman、Firebug调试Javascript有时会出现一些异常，没有象用Vs、gdb调试C/C++那样的稳定，也许与其本身的实现有些相关，毕竟是调试脚本语言。下面了解一下其实现也许能解除你的一些困惑。

二、Venkman实现
Venkman作为一个extension，其实现完全基于js+xul等相关技术实现。

1、UI
考虑所调试内容的多样性，Venkman UI方面的实现充分的利用了Gecko中的Overlay、XBL等技术要素，同时其显示的项目及其菜单等都是动态生成，界面风格类似于VS，各个显示区域可动态调整、组装。

可以具体关注一下Venkman-bindings.xml、Venkman.xul、Venkman-overlay.xul等实现；

2、调试逻辑控制
整个Gecko内核调试逻辑控制由一个实现了接口Components.interfaces.jsdIDebuggerService，CTRID为 "@mozilla.org/js/jsd/debugger-service;1"的XPCOM组件，其提供的主要接口如下：
interface jsdIDebuggerService : nsISupports
{
...........................................
/**
* Called when an error or warning occurs.
*/
attribute jsdIErrorHook errorHook;
/**
* Called when a jsdIScript is created or destroyed.
*/
attribute jsdIScriptHook scriptHook;
/**
* Called when the engine encounters a breakpoint.
*/
attribute jsdIExecutionHook breakpointHook;
/**
* Called when the engine encounters the debugger keyword.
*/
attribute jsdIExecutionHook debuggerHook;
/**
* Called when the errorHook returns false.
*/
attribute jsdIExecutionHook debugHook;
/**
* Called before the next PC is executed.
*/
attribute jsdIExecutionHook interruptHook;
/**
* Called when an exception is thrown (even if it will be caught.)
*/
attribute jsdIExecutionHook throwHook;
/**
* Called before and after a toplevel script is evaluated.
*/
attribute jsdICallHook topLevelHook;
/**
* Called before and after a function is called.
*/
attribute jsdICallHook functionHook;
attribute unsigned long flags;
attribute boolean initAtStartup;
readonly attribute boolean isOn;
/**
* Turn on the debugger.
*/
void on ();
[noscript] void onForRuntime (in JSRuntime rt);
void off ();
readonly attribute unsigned long pauseDepth;
unsigned long pause();
unsigned long unPause();
/**
* Force the engine to perform garbage collection.
*/
void GC();
void DumpHeap(in string fileName);
void clearProfileData();
/**
* Adds an execution hook filter. */
void insertFilter (in jsdIFilter filter, in jsdIFilter after);
/**
* Same as insertFilter, except always add to the end of the list.
*/
void appendFilter (in jsdIFilter filter);
....................................................
void enumerateContexts (in jsdIContextEnumerator enumerator);
void enumerateScripts (in jsdIScriptEnumerator enumerator);
void clearAllBreakpoints ();
jsdIValue wrapValue (/*in jsvalue value*/);

/**
* Push a new network queue, and enter a new UI event loop.
*/
unsigned long enterNestedEventLoop (in jsdINestCallback callback);
/**
* Exit the current nested event loop after the current iteration completes,
* and pop the network event queue.
*/
unsigned long exitNestedEventLoop ();
};

调试过程主要控制流程如下：
1、由Debugger(如Venkman)发起调试开始，调用DebuggerService.on方法，DebuggerService创建JSDContext，与当前JSRuntimer建立联系，并将DebuggerService中方法设置为当前JSRuntimer的globalDebugHooks对应元素的Hook(即设置回调函数指针)；

2、Debugger将DebuggerService中的errorHook、scriptHook、breakpointHook、debuggerHook、debugHook、interruptHook、throwHook等Hook设置成Debugger提供的方法；

3、当JS引擎执行解析、调用JS脚本时，发现其globalDebugHooks中有对应回调Hook，如每解析完一个JS Function时就会调用newScriptHook，进而由DebuggerService调用Debugger提供的scriptHook，Debugger的scriptHook会根据JS引擎提供的文件名、函数名、行号等，读出对应文件显示出来；

4、当在指定文件对应行设置一个断点时，Debugger由DebuggerService调用JS引擎向指定的函数调用Frame中设置Trap操作码；

5、一旦JS引擎执行到Trap操作码，则会调用其globalDebugHooks中对应的回调Hook，进而调用DebuggerService breakpointHook，从而调用Debugger的debugTrap，其中会根据当时的调用上下文调用DebuggerService的DebuggerService的EnterNestedEventLoop方法，它往往会维护一个嵌套计数，然后作事件处理循环，其主要代码如下：
jsdService::EnterNestedEventLoop (jsdINestCallback *callback, PRUint32 *_rval)
{
// Nesting event queues is a thing of the past. Now, we just spin the
// current event loop.
nsresult rv;
nsCOMPtr
stack(do_GetService("@mozilla.org/js/xpc/ContextStack;1", &rv));
if (NS_FAILED(rv)) return rv;
PRUint32 nestLevel = ++mNestedLoopLevel;
nsCOMPtr thread = do_GetCurrentThread();
if (NS_SUCCEEDED(stack->Push(nsnull))) {
if (callback) {
Pause(nsnull);
rv = callback->OnNest();
UnPause(nsnull);
}
while (NS_SUCCEEDED(rv) && mNestedLoopLevel >= nestLevel) {
if (!NS_ProcessNextEvent(thread))
rv = NS_ERROR_UNEXPECTED;
}
JSContext* cx;
stack->Pop(&cx);
NS_ASSERTION(cx == nsnull, "JSContextStack mismatch");
}
else rv = NS_ERROR_FAILURE;
NS_ASSERTION (mNestedLoopLevel <= nestLevel,
"nested event didn't unwind properly");
if (mNestedLoopLevel == nestLevel)
--mNestedLoopLevel;
*_rval = mNestedLoopLevel;
return rv;
}

其中的事件处理循环很关键，在处理事件时被调试的JS脚本无法继续进行执行(即Block)，而Debugger仍然可以处理UI事件，如显示当前CallFrame、查看变量值等；

6、当遇到断点时，用户通过Step-in或Step-out等触发JS引擎调用CallHook等，进而根据嵌套计数跳出上面的处理循环，而进入另一个循环或调试结束。

说明：整个过程与传统的windbg、gdb与OS、硬件协同完成Debug过程的实现非常类似，只不过这里的JS引擎相当与OS，它们都非常清楚源文件与具体执行点之间的对应和当时的上下文信息；一样由debugger来提供一些Hook给JS引擎或OS，当JS引擎或OS遇到Trap指令或异常等，它们会及时调用debugger提供的Hook，以由debugger给出下一步执行的决定。

但它们之间有个最大的不同在于JS debugger与运行的被debug的JS脚本都处于同一浏览器进程中；而windbg、gdb调试程序时debugger与被debug的程序往往处于不同的进程。

这里就导致JS debugger中需要过滤的问题，因为不可能在同一进程中调试自己(如用Venkman调试Venkman或用Firebug调试Firebug)，这个过滤的动作往往由debugger来决定什么样的源文件可以设置断点、可对其函数进行Step-in、Step-out等，Venkman与Firebug的过滤机制不一样，导致Firebug不能调试chrome类的源文件。

Firebug有关调试方面的实现与Venkman很类似，一样需要利用DebuggerService来实现交互，有时间可具体参考参考。

三、WebKit Javascript调试实现
其实现逻辑与Gecko差不多，首先由Javascript实现提供一个Debugger接口类(相关于Gecko中的DebugHook)，然后由一个实现了该Debugger接口的JavaScriptDebugServer来控制调试窗口与被调试页面之间的关系。

一旦JS引擎遇到解析完JS函数、设置的断点、开始函数调用、结束函数调用等则通知(或回调)调试窗口，以控制下一步的操作。

Drosera-Webkit-Trac对其中的设计有一定的说明。

四、总结
对一个开发人员来讲，不管是Web开发、还是Java、C/C++开发，乃至内核、驱动开发等，调试是一门必须掌握的技术，因为它不仅能让你提高工作效率，同时能让你更加深入的了解掌握计算机技术；如果能更一步的了解调试工作原理，则会让你如虎添翼。有空可以看看《软件调试》、《How debuggers work》等。。。

五、参考资源
Venkman HomePage
Learning the JavaScript debugger Venkman
Firebug HomePage
Drosera-Webkit-Trac

Wiki Debugger
Wiki GNU_Debugger(GDB)
Wiki WinDbg
Advanced Debugging(高端调试)

认识了解Gears

2008-10-15T18:40:00.000+08:00

前一段时间对Google Chrome有过简单的认识与了解，在体验新鲜出炉的Google Chrome浏览器中提到Google的Google Chrome Comic，其中提出通过Gears来扩展Web应用，但究竟什么是Gears以及其如何来扩展浏览器等，一直令人好奇。通过了解Gears应该可以了解Google将来究竟主推怎样的方式来扩展Web应用，当然包括Chrome浏览器及Android等，因为个人一直认为Gecko内核对扩展的支持非常方便、灵活、实用(具体可参考与Gecko相关的文档)，但对基于WebKit内核的扩展相对来说不是那么的方便与直接，为了满足探究感，让我们开始了解Gears之旅吧。

一、什么是Gears?
Gears is an open source project that enables more powerful web applications, by adding new features to web browsers.

目前主要提供一组JS API以供Web应用使用，对应Web开发者来说其类似于prototype、dojo、jquery等JS库，但其实现是通过扩展浏览器来实现(不仅仅包含js代码还包含二进制代码等)。

主要的API模块有：

A Database module (powered by SQLite) that can store data locally.
A WorkerPool module that provides parallel execution of JavaScript code.
A LocalServer module that caches and serves application resources (HTML, JavaScript, images, etc).
A Desktop module that lets web applications interact more naturally with the desktop.
A Geolocation module that lets web applications detect the geographical location of their users.

通过Google Gears可以了解Gears的发展及目前开发状态等，其中有些已实现或打算实现的API还是非常有意思的如Geolocation、Audio、Camera等，一旦这些API能完善好的话确实非常有利于Web应用的扩展，比如说录音、摄像等。

如果对扩展Web应用如开发RIA等有兴趣的话，可以好好考虑哪些应用或业务，可以或需要扩展到Web上来，通过了解Gears，说不定Gears能给您很大的启发。。。。

二、如何利用Gears?
利用Gears，首先需要用户安装Gears如对Firefox来讲就是一个extension，对Chrome、Safari来讲是一个符合NPAPI的插件，对IE来讲就是一个ActiveX；其次利用Gears API开发相关应用页面，以供最终用户使用。

也许对最终用户来讲稍嫌麻烦，需要额外安装程序，但如果Gears能象Flash一样实用、好用，那时就不再会觉得很麻烦啦。

对开发者来讲利用Gears相对就简单啦。在页面包含
<script src="gears_init.js"></script>
<script>
if (!window.google || !google.gears) {
location.href = "http://gears.google.com/?action=install&message=<your welcome message>" + "&return=<your website url>";
}
</script>
然后就可以使用其中的API啦。

具体可参考Gears Resources and Tools中的gears_init.js、samples及其他API等文档。

三、初步探究Gears基本实现原理
通过初步了解Get gears_init.js可以基本了解Gears提供对IE、Firefox、Chrome、Safari等支持，但其实现方式各有不同。

1、对各浏览器的支持
对Firefox来讲，Gears扩展了一个GearsFactory JS对象，可供JS脚本直接调用，从JS的角度看相对于给window对象新增了一个对象，就像原先的document、navigator对象一样使用，只不过其功能不同而已。

对IE来讲，Gears扩展了一个Gears.Factory ActiveX对象，可通过JS脚本new ActiveXObject('Gears.Factory');来直接调用，从JS的角度看可以象使用XMLHttpRequest对象一样使用Gears.Factory。

对Chrome、Safari来讲，就有点特殊啦，也有点诡异的感觉。需要在当前文档动态添加一个MIMEType为application/x-googlegears的Object插件对象，而这个Object对象就是对应的google.gears.factory对象。

从这里就可以看出WebKit对扩展JS的支持，从架构设计不是那么的直接，需要由NPAPI插件机制来中转实现；而Firefox、IE都从架构上提供了相应扩展机制来扩展，相当的直接明了及与浏览器本身的统一。

2、google.gears.factory对Firefox支持的实现
从浅谈Gecko关键部分之六认识javascript实现及应用中我们可以了解到Gecko中XPCOM组件通过xpconnect及对DOMCLASSINFO的定义，就可轻松的将XPCOM组件Binding给JS使用，就像Gecko中对Components、Components.Interfaces、xmlhttprequest等的实现。

在Gears中就是使用了类似的方式来Binding一个GearsFactory组件给JS环境使用。其中实现了一个实现了GearsFactoryInterface接口的名称为GearsFactory，ContractId 为"@google.com/gears/factory;1"的组件，具体代码详见gears\factory\Factory_ff.cc，然后在gears\base\firefox\Module.cc中注册该组件时使用
catMgr->AddCategoryEntry(JAVASCRIPT_DOM_CLASS,
kGearsFactoryClassName,
kDomciExtensionContractId,
PR_TRUE, PR_TRUE, NULL);
将该组件声明为需要由xpconnect Binding给JS使用。一旦启用xpconnect，xpconnect就会作相应处理，具体可参考nsDOMClassInfo::RegisterExternalClasses()等方法。这样就完成JS GearsFactory对象的实现。

3、google.gears.factory对Safari支持的实现
从浅谈WebKit之JavaScriptCore/V8篇中我们可以知道WebKit中将DOM实现Binding给Javascript实现往往通过generate-bindings.pl生成的代码来静态Binding，这种方式无法满足动态Binding的需求。但是从浅谈Gecko关键部分之九Plugin中我们了解到NPAPI插件接口提供了一组接口可以将插件的接口动态Binding给JS环境，同时可以让插件与JS之间相互调用。

而WebKit中实现了对NPAPI插件接口的支持，这样Gears中实现了一个mimetype为application/x-googlegears的插件，将该插件对象当作google.gears.factory JS对象来提供给页面使用。

具体可参考gears\base\npapi\Module.cc、Npp_bindings.cc，其中的NPP_New()方法应该是主要入口，同时设置该插件为windowless。至于如何将插件的方法动态Binding给JS使用，可具体参考Webkit中对NPN_CreateObject、NPClass的实现支持等。

4、google.gears.factory对IE支持的实现
按照创建ActiveX及BHO等接口方法来实现Gears.Factory ActiveX，进而将该对象赋值给google.gears.factory。具体关于ActiveX及BHO相关的知识参考Microsoft文档。

5、对其他API接口的实现
虽然google.gears.factory实现了create、getBuildInfo、version等接口，但对通过create创建出来的提供给开发人员用的localserver、geolocation、httprequest、audio等对象是如何实现的呢？

体现Gears强大及方便的地方就在这里。Gears提供了一组统一的类及接口实现可以方便将自定义的类及接口Binding给对应浏览器的JS实现。针对Firefox，它通过扩展SpiderMonkey的方式直接扩展JS实现；针对Safari，它还是使用NPAPI、NPObject的方式来扩展。

具体可以参考一下gears\base\common\Js_runner_np.cc、Js_runner_ff.cc、Js_runner_ie.cc等；

这一组统一扩展JS实现的类及接口有：ModuleImplBaseClass、ModuleWrapperBaseClass、DispatcherInterface、Dispatcher、MarshaledModule、ModuleEnvironment等，其作用就是按照统一的方式方便的将自定义的类及接口Binding给不同的浏览器实现。

如果对这方面有兴趣，可以对这些类及接口之间的关系及实现进一步研究，看Gears究竟是如何将C/C++类实现Binding给JS。其实这一点对JS来讲非常有意义，因为一旦可轻松方便的扩展JS，那么JS的应用就会进一步的扩大，就象python一样，python脚本可以方便扩充其模块，C/C++类库也可方便的扩充成python模块，从而让python几乎无所不能。

四、如何扩展Gears API?
在初步了解Gears实现原理之后，正与Gears CreatingNewModules所描述，我们也可以利用Gears来扩展自己的API，在了解其他API的实现基础上，其实扩展一个自己的Gears API难度似乎并不太大。。。

期望大家有时间可以加入到Google Gears中来一起拓展Web应用。。。

五、总结
通过对Gears的初步了解，觉得Gears对浏览器的扩展主要体现在对JS方面的扩展，相当于JS功能库的扩充，并且主要体现在非UI方面，虽然其中有部分UI方面的内容，但相当少；而Adobe推出的flash、Microsoft推出的Silverlight主要是按照插件的方式基于html标准的embed/object进行扩充，往往涉及到UI方面，并都有自身的特色如内嵌脚本语言、播放video/audio、网络处理等等；而Gecko所拥有的extension确可以是全方位的(包括UI、xpcom、插件等等)。

目前随着Ajax及RIA的推广，各式各样的JS库如prototype、dojo、jquery等也层出不穷，但是针对JS功能库方面的扩展还没有一个相对通用的国际标准，也许Gears正好抓住这样一个发展的趋势才采取这种通过扩展JS接口，为开发人员提供API的方式来扩展Web应用。

Gears API一方面迎合了RIA等方面的需求，另一方面也推动浏览器的扩展。但是它似乎抛弃了UI方面的扩展如使用Gecko的XUL、Microsoft XAML等的可能，也许flash对UI方面有太多的优势，同时html5中的video/audio逐步提上日程，做一个类似于Silverlight的插件意义不大，还不如在JS方面下足功夫，同时全面拥抱html(如gmail、gmap、gdoc等)，也许这就是Google目前对扩展Web应用的一点看法吧。。。

六、参考资源
Gears Project
Wiki Gears(software)

浅谈WebKit之Port篇

2008-10-08T13:48:00.000+08:00

WebKit作为一个浏览器引擎，其相对于Gecko而言一个较大的特点就是便于移植，嵌入到其他程序中，目前大家已了解使用WebKit引擎的应用包括Safari、iPhone、Chrome、Android、Nokia S60 Browser及KDE QT4.4等，同时还有其他方面的移植如Gtk、wxWidget、3D等，可以说WebKit从架构上讲其Port移植方面的设计及应用，是非常优秀的。这一点相对于Gecko有相当大的优势，有时间可以参考一下浅谈Gecko关键部分之十二Embedding。为了更深入的了解WebKit，我们现在就从WebKit有关Ports方面入手，了解其有关Port方面的设计，从而了解究竟如何能移植WebKit到自己的应用中。

一、有关Port方面的概述
在通过了解浅谈WebKit之WebCore篇之后，应该说WebKitPort方面的内容是可以很广的，例如可将不同的图形库、网络库与WebCore集成，提供不同的Port接口供外部程序使用等，例如同样在windows平台上可以运行的Google Chrome和Safari就是针对WebKit的不同移植。

我们想了解有关Port方面的主要内容在于提供不同的Port接口供外部程序使用以及如何与外部程序交互，因为WebKit中的其它两部分WebCore、Javascript实现，从逻辑上讲是不直接提供接口给外部程序使用的。同时为了完成浏览器的核心功能，WebKit也需要从外部程序中通过Port接口的方式获取一些支持。

从这个角度讲WebKit作为一个相对独立的整体，它与外部程序之间的交互也就有一组相对固定的接口来定义及维护它们之间的关系，它们之间的关系与插件跟浏览器引擎之间的关系完全类似，接口相当一组协议，有的是由WebKit来实现，而供外部程序调用；有的的正好相反。

通过前面的了解我们知道WebKit的主要功能集中在分析Html、渲染布局Web内容以及Javascript实现方面等，而这些Web内容显示在哪个窗口及消息处理的启动循环等都需要由外部程序来提供。

二、初步分析已有WebKit Port移植实现
1、与WebCore交互接口的实现
在WebKit源代码目录结构中WebKit目录下分别包含gtk、mac、qt、win、wx目录，其分别对应不同的Port移植方式，在每一个目录下面都包括WebCoreSupport目录，而在不同的WebCoreSupport目录下分别包含有对类接口WebCore::ChromeClient、WebCore::ContextMenuClient、WebCore::DragClient、WebCore::EditorClient、WebCore::FrameLoaderClient、WebCore::InspectorClient等的实现，它们代表外部程序提供给WebKit内部使用的接口实现，其中WebCore::ChromeClient、WebCore::FrameLoaderClient非常重要。

初步了解其接口定义能基本了解其对应的含义，这些接口往往需要由Port移植部分来提供实现，往往由WebKit内部根据一定的条件来调用。下面初步来了解几个主要接口：

WebCore::ChromeClient接口：
//往往在运行window.open脚本时调用，以便由外部程序决定如何打开一个新页面如新建一个窗口、新建一个Tab页签等；
virtual WebCore::Page* createWindow(WebCore::Frame*, const WebCore::FrameLoadRequest&, const WebCore::WindowFeatures&);

//通知外部程序显示页面；
virtual void show();

virtual bool canRunModal();

//通知外部程序以Modal的方式显示页面；
virtual void runModal();

//通知外部程序显示JS警告提示窗口；
virtual void runJavaScriptAlert(WebCore::Frame*, const WebCore::String&);

//通知外部程序显示JS警告确认窗口；
virtual bool runJavaScriptConfirm(WebCore::Frame*, const WebCore::String&);

WebCore::FrameLoaderClient接口：
//检查是否拥有主页面窗口；
virtual bool hasWebView() const;
//检查是否拥有页面窗口；
virtual bool hasFrameView() const;

//通知外部程序有关http请求开始、结束、获取数据等，如通常浏览器状态栏显示的信息；
virtual void dispatchDidReceiveResponse(WebCore::DocumentLoader*, unsigned long identifier, const WebCore::ResourceResponse&);
virtual void dispatchDidReceiveContentLength(WebCore::DocumentLoader*, unsigned long identifier, int lengthReceived);
virtual void dispatchDidFinishLoading(WebCore::DocumentLoader*, unsigned long identifier);
virtual void dispatchDidFailLoading(WebCore::DocumentLoader*, unsigned long identifier, const WebCore::ResourceError&);

//通知外部程序WebKit内部主要事件处理，以便外部程序及时响应或创建维护数据等
virtual void dispatchDidHandleOnloadEvents();
virtual void dispatchDidReceiveServerRedirectForProvisionalLoad();
virtual void dispatchDidCancelClientRedirect();
virtual void dispatchWillPerformClientRedirect(const WebCore::KURL&, double interval, double fireDate);
virtual void dispatchDidChangeLocationWithinPage();
virtual void dispatchWillClose();
virtual void dispatchDidReceiveIcon();
virtual void dispatchDidStartProvisionalLoad();
virtual void dispatchDidReceiveTitle(const WebCore::String&);
virtual void dispatchDidCommitLoad();
virtual void dispatchDidFinishDocumentLoad();
virtual void dispatchDidFinishLoad();
virtual void dispatchDidFirstLayout();

//告诉外部程序需要提供切换到一个新页面状态。此时外部程序往往会新建FrameView，并将FrameView与Frame关联，设置原生窗口句柄及其消息处理机制等等；
virtual void transitionToCommittedForNewPage();

//告诉外部程序创建一个新的Frame，如遇到html中iframe标签时，需要外部程序创建一个新的Frame及原生窗口句柄等；
virtual PassRefPtr createFrame(const WebCore::KURL& url, const WebCore::String& name, WebCore::HTMLFrameOwnerElement* ownerElement,
const WebCore::String& referrer, bool allowsScrolling, int marginWidth, int marginHeight);

//告诉外部程序需要创建一个Plugin实例，从而创建其原生窗口等等；
virtual WebCore::Widget* createPlugin(const WebCore::IntSize&, WebCore::Element*, const WebCore::KURL&, const Vector&, const Vector&, const WebCore::String&, bool loadManually);

2、对WebCore中的page/loader等方面的类提供对应Port的实现支持
如EventHandlerWin.cpp、FrameLoaderWin.cpp、DocumentLoaderWin.cpp、DocumentLoaderWin.cpp、WidgetWin.cpp、KeyEventWin.cpp等

3、实现WebView及WebFrame等以便外部程序嵌入WebKit
不同的Port移植对WebView及WebFrame的定义及实现有所不同，但其与WebCore中的Page、Frame之间的关系大致与浅谈WebKit之WebCore篇图一描述相一致。

具体关于WebView、WebFrame的定义与实现，特别是初始化时的动作可根据不同的Port移植而有所不同，同时初始化时会将上面提到的WebCore Port接口实现告诉WebKit内部。主要示例代码如下：
static void webkit_web_view_init(WebKitWebView* webView)
{
WebKitWebViewPrivate* priv = WEBKIT_WEB_VIEW_GET_PRIVATE(webView);
webView->priv = priv;
priv->corePage = new Page(new WebKit::ChromeClient(webView), new WebKit::ContextMenuClient(webView), new WebKit::EditorClient(webView), new WebKit::DragClient, new WebKit::InspectorClient);
priv->mainFrame = WEBKIT_WEB_FRAME(webkit_web_frame_new(webView));
priv->lastPopupXPosition = priv->lastPopupYPosition = -1;
priv->editable = false;
................................

priv->webSettings = webkit_web_settings_new();
webkit_web_view_update_settings(webView);
..................................
}

WebKitWebFrame* webkit_web_frame_new(WebKitWebView* webView)
{
g_return_val_if_fail(WEBKIT_IS_WEB_VIEW(webView), NULL);

WebKitWebFrame* frame = WEBKIT_WEB_FRAME(g_object_new(WEBKIT_TYPE_WEB_FRAME, NULL));
WebKitWebFramePrivate* priv = frame->priv;
WebKitWebViewPrivate* viewPriv = WEBKIT_WEB_VIEW_GET_PRIVATE(webView);

priv->webView = webView;
priv->client = new WebKit::FrameLoaderClient(frame);
priv->coreFrame = Frame::create(viewPriv->corePage, 0, priv->client).get();
priv->coreFrame->init();

return frame;
}

4、Chrome中对Port移植方面的实现
其基本上与其他Port移植类似，其主要代码在webkit\glue目录中，可重点关注带client_impl.cc后缀的文件、webview_impl.cc、webwidget_impl.cc等；但是其究竟如何创建原生windows窗口、如何创建Render进程、Render进程与创建的原生windows窗口的关系如何等需要更进一步深入研究Chrome，如果能从上面提到的Port部分入手也许很快就可得到答案，这一点以后有机会单独研究。

5、Android中对Port移植方面的实现
其实现有点特殊，由于Andriod将WebKit以一个Java类接口的方式提供给Java环境使用(不像上面提到的Chrome、Safari等都是将WebKit以一个C++动态或静态库的方式供C/C++外部程序调用)，这样WebKit内部与外部即JavaVM的交互(如上面提到的ChromeClient、 FrameLoaderClient接口实现)需要一个Bridge类来协调处理，同时WebView、WebFrame接口绑定给JavaVM的jni接口实现也需要通过这个Bridge来支持协调处理。具体可详细参考android源码代码中WebCore\platform\android目录下的源文件。

6、通过进一步了解WebCore Port接口及其实现，可以加深这样一个认识：
如果从MVC的角度来看整个基于WebKit的浏览器(当然不尽合理)，WebKit的Port部分相当于V部分，它提供显示页面内容及其辅助信息(如提示状态)的场所(即原生窗口)以及控制该显示场所的状态变化及消息响应(如改变大小、鼠标移动等)；而M部分往往由WebCore来实现，至于WebCore如何组织DOM则往往由htmlparser部分根据DOM定义来组织，如何在提供的显示场所显示Web内容则往往由WebCore中的layout部分来实现，其中充分利用了Css定义来布局显示该显示的内容；一旦涉及控制或动态处理往往由Port部分发起而由Javascript脚本来实现处理，其任务由JavascriptCore或V8来完成。

一般说来新打开一个页面，Port部分需要提供一个主显示场所(即原生窗口)，如果页面中含有iframe标签，则需要在主显示场所内创建一个子显示场所，以显示iframe标签对应src的内容；如果页面中含有embed/object等插件标签同样往往也需要在主显示场所内创建一个子显示场所(除非windowless)，以交由插件实现在提供的显示场所中显示内容。

特别需要说明的是我们通常看到的页面表单元素input text field、textArea、button、radiobutton等往往不像window图形库中的按钮、菜单、输入框等会对应一个原生窗口，页面中的表单元素在一个显示场所(即原生窗口)中完全是利用Css等通过layout方式来达到我们所看到的类似原生按钮、输入框、列表框、滚动条等效果，其中特别是能准确定位元素大小、设置focus、光标显示、响应事件等，这充分的说明了浏览器引擎内部布局部分的威力所在。

从另外一个角度来看一个页面一般说来(除非遇到iframe或插件需要另外提供一块子画布)相当于一块画布，浏览器引擎能在其精确的位置绘制不同颜色的文字、图片、图标等，同时根据当前的鼠标及一个模拟的输入提示光标位置，接收键盘输入操作。页面中的绝大多数元素与原生的窗口元素几乎没有关联，完全通过组合、布局、准确定位来处理一切。。。

三、如何利用WebKit?
了解WebKit Port部分，对我们如何利用WebKit有非常现实的意义，目前已经将WebKit移植到多种平台如windows、qt、gtk、mac、wx、java、framebuffer等，甚至移植到python、ruby及3D等环境中去。通过借鉴或利用这些已有的WebKit Port实现，完全可以将WebKit发扬广大。

前一阶段正好得到一个网友抓取网页的需求，试想目前移植利用WebKit基本都用来显示页面，往往涉及图形显示方面，但随着ajax及动态页面的广泛使用，未来动态生成的页面越来越多，传统的搜索引擎仅仅抓取静态的页面内容显然是不够的，现代化的搜索引擎应该能抓取动态的页面内容，这样它从某种意义讲相当于一个能获取对应的动态页面但不真正显示出其内容的浏览器，这样一个搜索引擎不仅能分析DOM树，同时能运行Javascript脚本(如运行ajax)，以真正完整获取页面内容，其实这样一个搜索引擎如果利用WebKit来实现的话，应该是个不错的选择，在我们了解WebKit Port部分之后，我们是否可以来模拟一个不真正具备图形显示方面的Port，进而充分利用WebKit中的WebCore及Javascript实现方面的功能呢？一点想法，今后有机会可以试试，或许Google、Yahoo的搜索引擎已经有了相关的实现，不知是否使用的就是WebKit?应该不会，有谁清楚的话，烦请通知一声。

但愿我们也能利用利用WebKit整出一个象模象样的东东如机顶盒浏览器、手机浏览器等等。。

四、参考资源
The WebKit Open Source Project
Google Chrome Home
Android - An Open Handset Alliance Project

南昌游记

2008-09-28T20:20:00.000+08:00

2008.09.13-2008.09.17有幸能到有名的洪城南昌悠闲了几天，现将零星的记忆记录如下：

出发
9.12晚坐上K287车次的火车，车上人不是很多，不算拥挤，眯眯糊糊睡了一觉，第二天6点多就到目的地，觉得也挺方便，又一次感受到国家推广的火车夕发朝至政策的好处，回想多年前坐船从武汉到南京，可得三、五天呢？很方便出了火车站，听说南昌火车站是新近翻修过的，但仍旧未能留下特别的映象。

与南京、上海火车站相比，似乎差距不少，就拿出站打的吧，一般日子在南京、上海火车站打的确实够方便，可南昌火车站则需要排仅有的一队，等待按次序安排进来的TAXI，还有不少人在组织安排，可惜车子和人群一样得排老长的队，也许效率有点不高吧，还好大约等了10几分钟，终于坐上了TAXI。比较有趣的是，坐上车前，组织人员还特意发个卡片，提醒自己提防TAXI绕路、坑人等，也许此类事件在当地不少见，也算很实用吧。不过自己这次旅行未曾遇到。

第一天
上午稍加休息整理，下午来到南昌最大的内湖，最美丽的风景湖区象湖，湖区内风景宜人，空气清新，感觉湖区较大，可惜开发似乎不够，靠近湖区西边倒有不少新近开发的楼盘及大型超市如好又多等，应该还是挺适合居住生活的地方。楼盘价格大约在3000到6000之间。漫步在湖间小道，虽然游人不多，亲身感受到清新的湖风及阵阵风浪声，顿时兴致盎然，不犹回想起诗人般生活及古老的诗词等，当时一首简短打油诗油然而生以记录当时的心情。。。附录如下：《游象湖》太阳西边照，看到友人笑；漫漫人生路，快乐最重要。

第二天
一早坐上游2线公交车，车费够便宜无论多远仅1元，大约50分钟就来到著名的秋水广场，看到新建的南昌新区，深切的感受到南昌人想建设好南昌，大力发展好南昌的大思路，以及官方大力宣扬的口号大气、开放、诚信、图强所浓缩的精髓。站立在秋水广场，远眺浩瀚的赣江，享受着独特的音乐喷泉，遥望对面的腾王阁，别有一番韵味。

秋水广场

来到南昌，就不得不想到著名的八一起义，由此南昌才有红色之城之称。下午，继续坐游2公交车，来到闹市区的八一纪念馆，大约排10分钟的队，就能领取到免费的门票。进入纪念馆，人们纷纷扰扰，可有序而不喧哗，首先映入眼帘的是两幅起义军及领袖们的雕像，其气魄及豪气一样的令人征服。试想当时能有决心起来起义的人们，是需要很大的勇气及信心的，也许还有一股置生死于度外的无奈及冒险，从而大气凛然。。。。

门票

然后逐步参观了一些珍贵的历史照片及起义的策划、实施，以及起义后革命的走向等历史记录图片等等，详细阅读了历史教课书都提到的起义、会师重要历史事件的主要经过。。。好好重新学习了一段历史，深深感受到革命的成功来之不易，其中印象最深的是陈毅的誓师词，其中深刻的表达了信心、决心、勇气以及一股信念，现在看来他们当时似乎在拿生命作赌注，整整等了20年后，参加八一革命的人们才真正的看到胜利的曙光，看到那些名录表，无名的孤魂野鬼似乎可真不少。。。。

雕像一

雕像二

第三天
游玩了两天后，该领略南昌的美食及繁华的生活啦！一早就继续坐公交来到八一广场及繁华的市中心，八一广场，人流如织，但除了有个纪念塔外，没什么深刻映象，拿天安门、上海人民广场相比，差距不少，毕竟商业氛围、人们生活水平就如此。

八一纪念塔

然后有幸能去南昌最繁华的万达广场电影院体验了一场《水啸雾都》的影片，其实票价并不便宜，达65元，与上海、南京等市中心影院价格几乎一致，但看的人也还不少，心中不免有点疑惑，也许正好感上中秋节日或者影院本来就不多？影院效果挺不错，空间也挺大，电影情节也够吸引人。。。。

徘徊在广场附近的街道，感觉一般，街道不是很整洁、宽敞，氛围也一般，不时能看到一些穿着一般的老人、妇人、小孩在街道中驻足或穿梭，不过虽然没有地铁，交通还算方便。。。

第四天
为了进一步了解，南昌繁华的一面，一早就坐上公交，来到胜利路步行街，也许胜利路在南昌人看来挺繁华，但亲身体验一把后，感觉也一般，比南京的湖南路、无锡的中山路等都有段距离，顺便看了一下其有名的洪客隆超市，其中日常商品种类、价格与上海、南京等大超市相差无几，但人流似乎一般。。。

中午与友人一起来到蛤蟆街，腐败了一把，吃了一顿美食，价廉味道也不错，可惜听友人讲本地特色菜很少，大部分是外来的。不过自己早上吃到的炒米粉及瓦灌汤还算印象深刻。。。

餐中聊到南昌人的特点，其中谈到南昌人喜欢说泡、爱面子、说大话，自己未能深刻感觉到，也许需继续了解吧。。。

第五天
由于住在青云浦区，就顺便去了趟八大山人纪念馆，交通挺方便，去过的领导也不少如江、周等，其实那地方挺小，就是一个院子，不过门票得20元。几百年前明朝皇帝朱元璋的一位后裔(不知什么孙辈)，在满人进关后，辞官不做，来到南昌，潜心作画，画中以写物为主，以画寄托其对王朝灭忘的哀思，对民族的热爱，其画影响了中国近现代很多画家如张大千等等，所以留下一笔遗产，其名八大山人及书写都很独特。由于对书画不是很了解，参观大约1个半小时就结束啦，其中参观的人也不是很多。

八大山人像

返回上海
最后一天，早上8:30左右坐92次动车组返回上海，火车舒适方便，于12点左右到达南站，顺利结束本次旅行。

总结
总体感觉南昌之行顺利、愉快，在此感谢为我这次旅行提供支持、帮助的友人及其家人朋友等等，收获颇多，感慨甚多，让我有机会深深的回顾那段难忘的历史，以激励自己的信心、勇气与决心等，同时感受到现代南昌这个城市，虽然与沿海城市相比，城市建设、人文气息、工业化水平等有待发展，市民生活水平、素质等属于非常典型的中部偏低水平，但正与其口号宣称的那样大气、开放、诚信、图强发展着，潜力较大，祝福南昌，祝福每一位用心生活的人们。

一点个人感觉，不知是否偏颇？有待进一步了解。

浅谈WebKit之JavaScriptCore/V8篇

2008-09-25T19:30:00.000+08:00

WebKit作为一个浏览器引擎，其中Javascript实现包括JavaScriptCore和V8，为了能更全面的了解WebKit，我们需要深入的了解Javascript实现的基本原理、其在WebKit中的作用以及与其他部分之间的交互，同时与Gecko中的Javacript实现作初步的对比。让我们开始了解WebKit之Javascript实现JavaScriptCore、V8之旅吧。

一、Javascript实现的作用
正与浅谈Gecko关键部分之六认识javascript实现及应用部分对什么是javascript的描述那样，在WebKit中其Javascript实现，同样相当于一个符合ECMAScript标准的动态库，其往往依附于浏览器引擎，由浏览器引擎来提供运行环境，并控制或发起javascript实现进行编译、解析执行脚本、垃圾回收等，同样需提供对浏览器引擎扩展的支持如Dom Binding等；

由于Web2.0的提出，动态网页的交互如运行ajax更加的频繁，Javascript脚本运行的总体效率以及安全往往成为浏览器内核的关键，而其Javascript实现就担负着如此重任。

二、JavaScriptCore实现特点
相对于其他的Javascript实现，JavaScriptCore提出了虚拟机的概念，在编译脚本时生成高效的bytecode，bytecode统一在一个虚拟机的环境中执行。而其高效的虚拟机实现常称为SquirrelFish，通过Announcing SquirrelFish、Introducing SquirrelFish Extreme可更进一步了解关于SquirrelFish的相关内容。

三、V8实现特点
Fast Property Access
To reduce the time required to access JavaScript properties, V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes. This basic idea is not new - the prototype-based programming language Self used maps to do something similar. (See for example, An Efficient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes). In V8, an object changes its hidden class when a new property is added.

Dynamic Machine Code Generation
V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. Property access is handled by inline cache code that may be patched with other machine instructions as V8 executes.

During initial execution of the code for accessing a property of a given object, V8 determines the object's current hidden class. V8 optimizes property access by predicting that this class will also be used for all future objects accessed in the same section of code and uses the information in the class to patch the inline cache code to use the hidden class. If V8 has predicted correctly the property's value is assigned (or fetched) in a single operation. If the prediction is incorrect, V8 patches the code to remove the optimisation.

Efficient Garbage Collection
V8 reclaims memory used by objects that are no longer required in a process known as garbage collection. To ensure fast object allocation, short garbage collection pauses, and no memory fragmentation V8 employs a stop-the-world, generational, accurate, garbage collector. This means that V8:

stops program execution when performing a garbage collection cycle.
processes only part of the object heap in most garbage collection cycles. This minimizes the impact of stopping the application.
always knows exactly where all objects and pointers are in memory. This avoids falsely identifying objects as pointers which can result in memory leaks.

In V8, the object heap is segmented into two parts: new space where objects are created, and old space to which objects surviving a garbage collection cycle are promoted. If an object is moved in a garbage collection cycle, V8 updates all pointers to the object.

四、JavaScriptCore、V8如何与WebCore交互
在WebCore::Frame的数据结构中包含数据成员KJSProxy* m_jscript;而在Chrome的代码中调整为JSBridge* m_jscript;而针对不同实现JavaScriptCore、V8，分别有：
class KJSBridge : public JSBridge {
public:
KJSBridge(Frame* frame) : m_proxy(new KJSProxy(frame)) { }
virtual ~KJSBridge() { delete m_proxy; }
........................
private:
KJSProxy* m_proxy;
};

class V8Bridge : public JSBridge {
public:
explicit V8Bridge(Frame* frame);
virtual ~V8Bridge();
.......................
private:
V8Proxy* m_proxy;
};
V8Bridge::V8Bridge(Frame* frame) {
m_proxy = new V8Proxy(frame);
}
V8Bridge::~V8Bridge() {
delete m_proxy;
}

而不同的KJSProxy与V8Proxy分别对应不同的Javascript实现，它们分别实现了与WebCore之间的共同接口，其主要数据结构分别如下:
class KJSProxy {
Frame* m_frame;
KJS::ProtectedPtr< KJS::JSDOMWindow> m_globalObject;
int m_handlerLineno;
.........................................
};

class V8Proxy {
Frame* m_frame;
v8::Persistent<v8::context> m_context;
v8::Persistent<v8::object> m_global;
// Special handling of document wrapper;
v8::Persistent m_document;
int m_handlerLineno;
...........................
};
具体不同Javascript实现如何实现与WebCore的接口，需了解不同Javascript实现逻辑；

如对Javascript实现逻辑及基本原理感兴趣，可具体参考其提供的api及sample等等；

至于Dom Binding的实现，JavaScriptCore与V8通过通过同样的方式来实现，可参考浅谈WebKit之WebCore篇中所描述的Javascript实现如何与WebCore集成等；

具体Dom Binding的实现可参考generate-bindings.pl生成的代码，其中的内容一定会让你受益非浅，同时为将Javascript实现嵌入到其他应用中去提供非常有益的参考。如对window的实现，特别是open方法的实现，很值得研究研究。。。

五、初步对比JavaScriptCore、V8、SpiderMonkey等
具体JavaScriptCore、V8、SpiderMonkey、TracMonkey执行效率对比如何，不同的测试方法会有不同的测试结果，在这里不再阐述。

就个人了解而言，觉得JavaScriptCore关于对象的方法、属性的安全访问控制方面略有欠缺；

SpiderMonkey作为最早一批实现Javascript的引擎，其代码使用C语言来实现，稍现复杂，没有象后来的实现如JavaScriptCore、V8等借鉴了最新的虚拟机技术如JVM等；

V8作为新近推出的Javascript实现，正与其特点所描述，拥有很多优势，同时基于C++实现，充分利用了C++ template，代码相对简洁，便于学习使用；

关于TracMonkey请参考Firefox to get massive JavaScript performance boost

六、参考资源
Wiki Javascript
V8
Announcing SquirrelFish
Introducing SquirrelFish Extreme
SpiderMonkey Internals
Tamarin

浅谈WebKit之WebCore篇

2008-09-20T14:09:00.000+08:00

最近自从Google推出Chrome浏览器之后，浏览器受到人们更加广泛的关注，网上时而会出现这样那样的评价，作为一个浏览器内核爱好者，希望能乘着大家都关注的东风，能对浏览器内核有更深入的理解，进而能更好的进行Web开发及利用。

Chrome浏览器的代码量其实是非常庞大的，要想对其有深入的理解，仅仅编译编译调试调试，是很难深入下去的。让我们还是从其主要部分如多进程管理通信、WebKit、V8、Skia、WinHttp、Sanbox等着手分析其主要流程及数据结构，或许能达到事半功倍的效果，而WebKit是其中非常重要的一部分，是Chrome的核心引擎部分，其他部分都是基于它来集成的，深入了解了WebKit，对Chrome的理解就会迎刃而解，再说WebKit作为一个相对独立的浏览器引擎在Safari、iPhone、Adobe AIR等中都有应用，非常值得大家深入的研究研究。

就像前面的文章所说，WebKit主要包括三个部分WebCore、JavascriptCore及Ports部分，让我们先从WebCore部分出发吧。。。。

一、WebCore所包含的主要内容
1、从源代码目录结构来看
WebCore目录主要包括如下目录：
bindings 包含将Dom Binding给JavascriptCore方面的代码，同时包含依据idl接口描述文件，自动生成对应于JavascriptCore的Binding实现的脚本等内容；

bridge 主要包含NPPlugin方面的接口访问等内容；

css 主要包括与css方面相关的内容如解析、不同css规则的定义与实现、css Binding给JS的接口定义等内容；

dom 主要包括dom方面相关的内容如不同dom元素的定义与实现、dom Binding给JS的接口定义等内容；

html 主要包括html方面相关的内容如不同html元素的定义与实现、HTMLTokenizer及HTMLParser等内容；

loader 主要包括装载资源如html页面、css、js及image等方面内容；

page 主要包括描述一个Web页面所涉及的内容如page、frame、frameview、frametree、setting、history、chrome、chromeclient等内容；

rendering 主要包括如何使用样式，组织布局、显示html元素等方面内容；

plugins 主要包括浏览端如何实现NPPlugin方面的内容；

svg 主要包括与svg方面相关的内容；

xml 主要包括与xml方面相关的内容如xml parser、XPath、XSLT等；

platform 主要包括与不同平台或外部库相关的内容如graphics(图形输出方面)、network(网络处理方面)、image-decoders(解析不同图片格式方面)等；

2、主要数据结构
为了更加简单有效的描述浏览网页的内容及过程，WebKit为了明显区分不同方面的内容，采取了不同的namespace如webcore、javascriptcore、webkit等，webcore方面的主要数据结构有：
webcore::page、webcore::frame、webcore::FrameLoader、webcore::FrameView、Document、DOMWindow、KJSProxy、DocumentLoader、ResourceHandle、ResourceRequest、ResouceResponse、MainResourceLoader、RenderObject、RenderView等；主要数据结构描述如下：

WebView及WebFrame与page、frame之间的关系

图一

FrameLoader、DocumentLoader、DocLoader类结构

图二

主要Document类结构

图三

FrameView类主要结构

图四

总的说来，WebCore包含了浏览器引擎的核心部分如处理html、dom、css、svg、获取资源、渲染页面过程控制、回调/通知外壳程序以及与Javascript实现的Binding等等；

二、一个Http请求在WebCore中的主要流程

1、当调用webkit_web_view_open(url)时会触发core(webView)->mainFrame()->loader()->load(uri)(即调用FrameLoader.load)来发起一个Http页面请求；

FrameLoader.load方法的主要处理过程如图：

图五

2、一旦发起ResourceHandle::start，就会由网络库向web服务器发起一个http请求；

3、而MainResourceLoader作为一个ResouceHandleClient，提供了诸如didReceiveData()、didReceiveResponse()等回调接口以供网络库调用，一旦从web服务器获得相关数据后网络库部分则会调用相关接口如didReceiveData等；

4、MainResouceLoader::didReceiveData的主要回调处理过程如下图：

图六

5、通过回调didReceiveData()方法，进而调用Node.attach()方法，这样就会解析生成document，同时会创建frameview、domwindow等；

6、创建的frameview会触发layoutTimerFired时间Timer，进而调用layout()方法，从而触发RenderObject的创建、布局等，同时或许会invalidateRect，进而触发操作系统图形库的paint消息事件；

7、由程序主消息处理循环接收paint消息事件，进而获取对应frame，获取或创建GraphicContext，然后调用frame->view()->paint(&ctx,...)，从而触发对应RenderObject树进行重画处理，这样一个完整的页面就会逐步的显示出来。

三、网络库、图形库、Javascript实现与WebCore的集成

为方便扩展及模块化，WebCore在处理浏览页面的过程中，往往使用了类似java或gecko中接口的概念，一般先定义一组公共接口或基类，然后由不同模块来实现。

如网络处理部分由WebCore提供一个ResourceHandle类，而在不同的目录如cf、curl、qt、soup、win等中在不同网络库的支持下对ResourceHandle类提供不同的实现，待编译时择机选择对应目录下的实现，这种方式从架构的角度看比较简单，但往往不能让程序同时使用多个网络库，进而由程序动态切换使用不同网络库实现，而gecko在xpcom的基础上提供了对于这种扩展形式的支持；其中Chrome对ResouceHanle类的实现基于WinHttp网络库。

同样WebCore对图形库的集成，也是采取这种方式来实现，如由WebCore提供一个GraphicsContext类，然后在不同的目录如cairo、cg、qt、win、wx中在不同的图形库支持下对GraphicsContext提供不同的实现。其中Chrome对GraphicsContext类的实现基于Skia图形库。

WebCore中实现的dom、html、svg、css等，往往需要通过一定的方式输出给Javascript的实现如JavascriptCore、V8，以便JS Engineer能认识这些dom元素等，并且能调用其中的方法，这种方式叫做Binding，为了便于将WebCore中相对固定的dom、html、svg、css接口等极其方便的Binding出去，WebKit使用了极其高效及神奇的方式来实现。

首先定义一组非标准的idl接口，然后通过运行一组perl脚本如generate-bindings.pl、CodeGenerator.pm、CodeGeneratorJS.pm等，就可根据idl接口定义，生成一组符合指定Javascript实现规则的脚本对象类。这样极大的减轻了开发人员的投入及编码错误的发生。

这一点与gecko中将不同的xpcom接口Binding给Javascript实现有本质上的差别，在gecko中通过xpconnect及一组classinfo来维护原生元素与JS对象之间的关系，不同原生元素对应的JS对象的创建及属性方法的Binding完全依赖于xpconnect的实现及classinfo的定义，要添加删除修改Binding的属性与方法，只需修改classinfo；而WebKit中Binding，相对简单明了，不同原生元素对应的JS对象的属性与方法由idl接口文件来定义，而具体实现则交给威力强大的generate-bindings.pl来对应生成实现的代码，这样编译时就可以轻松实现Binding。。。

四、参考资源

The WebKit Open Source Project

体验新鲜出炉的Google Chrome浏览器

2008-09-05T10:55:00.000+08:00

2008年9月2日新一款浏览器终于诞生了，她的名字叫做Chrome，出自名门之家Google，早在N年前就听说Google想推出自己的浏览器，但经过多年的励精图治，其庐山真面目终于大白于天下，一时间网上各种测评、预言等等满天飞，经过这几天的学习研究，作为一个开源浏览器内核爱好者，从自身的角度来学习观察它，现将自己初步了解的Google Chrome浏览器总结如下：

一、学习Google Chrome Comic
Google为了有效宣传Chrome，通过漫画的形式来表达自己对当前浏览器的一些看法，以及他们的实现方案即Chrome，总结起来其主要内容如下：

1、Stability，Testing and the Multi-process Architecture
其中着重描述浏览器稳定性的要求及其独特的多进程架构，同时强调Chrome经过Google搜索引擎抓到的大量不同页面测试，其稳定性拥有独特的优势，这一点是其他浏览器的测试无法比拟的；

从技术的角度来讲，采取多进程架构来实现浏览器，目前来讲确实是独一无二的，是其他浏览器无法比拟的，但多进程架构本身在Yahoo!Widget及Apache等早有成功的应用案例，技术难度没有太多的创新，相对多线程架构来讲，增加了大量IPC方面的内容，其实IPC的实现与应用在OS的实现当中拥有大规模的应用。

但多进程架构是否真的象Google所宣称的那样稳定，会不会带来诸如CPU使用过高，整个浏览器资源是否太多？特别是window句柄是否过多?因为浏览器毕竟是个图形界面程序，而不仅仅是网络程序。

通过对其Process Models初步了解，其体系上也考虑到诸如Process-per-site-instance、Process-per-site、Process-per-tab、Single process等方式的选择，但其整体效用如何还需实践的考验，当然其出发点还是够强大的，正如N年前他们设计浏览器时所宣称的那样，浏览器就是一个互联网平台，作为一个互联网平台所能显示的页面及应用越来越多，其稳定性应该是首要解决的问题，他们采取的方案就是向OS学习，采取多进程，由一个主进程来管理浏览器的一切。

2、Speed，WebKit and V8
从漫画当中，我们可看到Google对浏览器的方方面面都早有相当程度的研究，但WebKit渲染内核是否速度最快，其实值得商榷，但其代码简洁，方便学习开发，倒觉得真的很对。

至于V8对javascript的实现是否真的很快也很难讲，虽然它对javascript的实现方式有所调整，但是否真的有那么高效率很难讲，毕竟似乎没听说过它在其他地方使用过并有良好表现。

其中网上就有很多人对其对其它javascript的实现如SpiderMonkey、JavascriptCore的评价特别是垃圾回收方面有很大的争议。

3、Search，UI
这方面Chrome本身应该没有太大的创新，虽然其提出标签页放在最上方，但其好多想法早在Firefox、Opera中有所实现。

4、Security，Sanboxing and safe Browsing
对于安全的考虑，其中sanbox及phishing等方面，Firefox早有相应的处理机制，只不过其sanbox可扩展到进程层，有了一定的提升，但其本质还是基于同源策略等，同时根据V8的介绍其中提供了对对象方法、属性权限的控制管理，这一点比JavascriptCore要强大，不过SpiderMonkey其实早有提供，至于其具体Security实现是否也有诸如Firefox中的SecrurityManager还须继续观察。

5、Gears，Standards and Open source
其中特别提到对Web应用的扩展是基于Gear来实现，由于前期对Gear的实现扩展方式未曾了解，可能以后须加强对这方面的学习。

但总的说来，其扩展性应该与Firefox相比，还是有很大差距，Firefox中提供了一整套的xpcom、extension、xul等可以让开发者从浏览器的方方面面来扩展，但Chrome因为其渲染部分使用了WebKit，要让开发者象扩展Firefox那样方便的扩展Chrome浏览器应该几乎不可能。目前来看要扩展Chrome需要使用Gear或相当通用的NP Plugin技术。

二、切身体验使用Chrome
2008年9月3日一早第一时间就下载试用了Chrome浏览器，感觉其体现了Google一贯的界面简单，操作简便的风格，并且省掉了很多操作如全屏、打印预览等，一时间觉得让人无所适从，同时页面加载速度及内存占用等方面并没有太突出的表现，特别是打开20个以上的页面后，再在不同页签之间切换，往往有停顿的感觉及空白页面的现象出现，这一点在Firefox3中那怕是50个页签也没有出现类似的现象。

通过地址栏在不同页签中打开20个不同的网站，对比Chrome及Firefox3的使用情况发现，Chrome的加载速度至少比Firefox3慢20%，而整体占用CPU及内存资源，Chrome比Firefox至少多20%，对计算机系统的影响也较大，在加载完网页后不进行任何鼠标操作的情况下，Chrome主进程或Plugin进程还继续占用大量CPU，而Firefox3中则几乎不占用CPU，或许Chrome整体架构或架构对Flash Plugin等方面的支持还存在或多或少的问题。

总之毕竟是第一个测试版本，能有不崩溃及正常使用的效果，比上次第一个Safari版本发布的效果好多啦，特别是对中文、英文等不同语言的支持方面。从初步使用的感受来看，应该还是挺不错的，应该可打80分以上。

三、初步研究Chrome源代码及相关网站
第一时间阅读了其开发网站Chromium developer Documentation中的相关内容，其中对相关内容的说明可谓专业而详细但不够全面，不愧为Google主推的Open Source，有兴趣的话可以好好阅读阅读。

其中对于Chrome的编译与调试一篇更是特别实用，按照其中的说明经过30-50分钟就可轻松的编译出一个Chrome，这一点在Firefox、WebKit等开源项目中是很难办到的，同时其中包含许多第三方库的编译，而不象一般的开源项目往往需要将第三方包从其他地方下载再编译，充分的说明了Google在Open Source方面的大力支持，对开源社区来讲应该是个福音，它极大的方便了开源项目的开发，从这点讲我们应该感谢Google。

通过初步分析其源代码及其架构说明，Chrome浏览器的主要特别之处在于多进程通讯、管理及V8，并将WebKit嵌入到其中。

而与WebKit相关的网络库使用的是WinHttp、图形库使用Google自己提供的skia，而不是苹果的CoreGraphic或者Cairo等，同时对WebKit的Port方面也是自己提供的一套Interface，这样看来Chrome对WebKit的使用主要是Render Layout及页面处理流程方面。

至于其他模块诸如libxml、libxslt、libjpeg、libpng、sqlite、pthread等与WebKit中使用的相一致。今后若有时间可对其进行进一步的分析。当然其中包含很多Google自己提供的V8、Gear等等。

四、总结
通过对漫画及相关文档的学习研究及实践等，虽然Google强调其开源、稳定、安全、扩展等特性，但其架构本身对Web方面并不象Gecko那样非常开放，Gecko通过对xpcom、xul的支持大大的扩展了Html及其应用支持，这一点Gecko应该还有相当的优势。

虽然从Google看来这正是其看不上Gecko内核而采取WebKit内核的原因，因为相对简单的WebKit内核还在Android方面也有优势，而Google对RIA方面的支持，也许没那么大，其支持方式应该更像Adobe AIR一样，而不象Gecko那样支持xul一样。

从整个Chrome浏览器中体现了Google一贯的作风，简单，代码也要简单，而Gecko它太复杂，复杂得让人难以掌控。

自从Google推出Chrome之后，各种评论特别多，尤其是Google与Mozilla的关系，以及Firefox的发展，有些人悲观地预计3年后Firefox将被Chrome超越甚至让人遗忘。

但是通过初步的学习研究，个人感觉Chrome的实现方式与Firefox的实现方式还是有本质上的差别，Firefox以前获得大家认可的优势如安全、快速、易扩展等优势依然存在，同时很早以前Mozilla的开发者就认识到其在开放平台及易扩展方面的巨大前景及无人可敌的优势，也许Mozilla的优势就在这里，只要坚守住啦，目前看来Google、Microsoft都短时间内难以超越Mozilla这一点。

一点个人看法，希望能激起大家一点共鸣，大家都能更好的利用Web技术。

好好研究研究Chrome，她毕竟是个新生儿，并出自名门之家。。。。。

五、参考资源
Google Chrome Home

Chromium Blog
V8

在windows上编译WebKit

2008-08-27T13:28:00.000+08:00

通过编译WebKit，可以让我们更进一步的了解、使用WebKit，从中了解WebKit使用哪些外部库，其中包含哪些主要内容等等。初次在windows上编译WebKit，是件比较麻烦的事情，需要注意的问题比较多，再加上相关文档不是很全面。从这个角度看，WebKit的编译系统，相对Gecko的编译系统，要粗糙很多。

下面简单汇总一下自己编译WebKit的过程及所遇到的问题解决方法等

一、按照下面由WebKit.org提供的内容准备编译环境、获取源代码等
Installing the Developer Tools
Getting WebKit
Building WebKit

其中首次获取源代码后需要特别注意的是一定要安装WebKit Support Libraries及运行WebKit/WebKitTools/Scripts/update-webkit成功。

其中WebKit Support Libraries主要包括缺省编译时需要使用的外部库CoreGraphics.lib、CoreFundation.lib、CFNetwork.lib，它们对应Safari所使用的Mac风格图形库及网络库；

而通过分析update-webkit脚本，得知它主要是下载一个WebKitAuxiliaryLibrary.zip并安装到指定目录，其中包括Unicode方面的icuin.lib及icuuc.lib、xml2及xslt方面的libxml2.lib和libxslt.lib、线程相关的pthreadVC2.lib、SQLite相关的SQLite3.lib等外部开源库等；

二、按照下面由Avishkar Autar提供的一篇Blog，修改直接从VS IDE编译WebKit
Avishkar Autar's Blog-Compiling Webkit On Win32
其中详细描述了相关注意事项及相应路径的修改。

三、解决编译过程中可能出现的常见问题
1、问题描述：
vc++2005 error PRJ0002 的问题错误的结果 1 (从“C:\WINDOWS\system32\cmd.exe”返回)

解决方法：
选中解决方案，选择属性->配置属性->清单工具->输入和输出->嵌入清单，把是改成否。

2、问题描述：
对VC 2005 error C2220:警告被视为错误-没有生成“object"

解决方法：
参考FIX:VC2005编译错误：1 error C2220: 警告被视为错误 - 没有生成“object”文件
选中解决方案，选择属性->配置属性->c/c++->常规->将警告视为错误，把是改成否。

3、问题描述：
正在创建库WebCore.lib : fatal error LNK1106: 文件无效或磁盘已满: 无法查找到 0x51F6CD51

解决方法：
参考FIX:LNK1106:: 无法查找到 0x76364 无效或磁盘已满解决此问题, 添加 /IGNOREIDL 链接选项。
在VisualStudio.NETIDE, 设置此链接器选项请按照下列步骤操作：
a. 打开属性页对话框对于项目。
b. 展开链接文件夹。
c. 单击要查看嵌入的 IDL 属性页嵌入的 IDL 。
d. 将忽略嵌入的 IDL 属性设置是。

四、总结分析
通过分析WebKit\WebKitTools\Scripts\build-webkit脚本，可知其在windows环境的编译过程主要是完成VS解决方案WebKit/win/WebKit.vcproj/WebKit.sln中的内容，其中已完成相关基本配置，这样说来其编译系统还是相对比较简单的，但由于需要使用比较多的外部库，并且没有将外部库的编译整合到WebKit的编译系统中，这样往往需要编译或下载、配置(如设置头文件、库文件的路径等)对应版本的外部库。

同时WebKit核心本身编译出来就是一个动态库，而象WinLanucher、FindSafari、DumpRenderTree等外围测试程序反而比较多，编译时也会出现一些问题，对一个初次接触的人来讲往往比较困惑。

编译成功后，可运行脚本WebKit/WebKitTools/Scripts/run-safari通过Safari来使用刚才编译的WebKit动态库，具体可参考Running WebKit。

但愿大家都能轻松愉快的编译出WebKit。。。

认识了解WebKit

2008-08-25T15:03:00.000+08:00

WebKit作为一个浏览器引擎，其第一Release版本在2003年1月发布，虽然出现的相对比较晚，但以其一些优越的特性，获得了诸如Google、Apple、Adobe、Yahoo等公司的青睐，似乎大有赶超Gecko的势头，带着究竟什么是WebKit？其主要特点有哪些？如何应用它？它与其他浏览器内核有哪些不同等疑问，开始认识了解WebKit。。。

一、什么是WebKit?
WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.

WebKit is an open source application framework that provides a foundation upon which to build a web browser. WebKit was originally derived from the Konqueror browser’s KHTML software library by Apple, Inc. for use as the engine of Mac OS X’s Safari web browser, and has now been further developed by Apple, Nokia, Google and others. The framework is now used by Omniweb, Shiira, iCab, Adobe AIR, Iris Browser, mobile phones (including the iPhone), Nokia’s Series 60 browser, and Google’s Android platform.

WebKit's HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE.

二、WebKit主要特点及其目标

Web Content Engine: The project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. However, we also want to make it possible to embed WebKit in other applications, and to use it as a general-purpose display and interaction engine.

Open Source: WebKit should remain freely usable for both open source and proprietary applications.

Performance: Maintaining and improving speed and memory use is an important goal. We never consider performance "good enough", but strive to constantly improve. As web content becomes richer and more complex, and as web browsers run on more limited devices, performance gains continue to have value even if normal browsing seems fast enough.

Portability: The WebKit project seeks to address a variety of needs. We want to make it reasonable to port WebKit to a variety of desktop, mobile, embedded and other platforms. We will provide the infrastructure to do this with tight platform integration, reusing native platform services where appropriate and providing friendly embedding APIs.

Compatibility: For users browsing the web, compatibility with their existing sites is essential. We strive to maintain and improve compatibility with existing web content, sometimes even at the expense of standards. We use regression testing to maintain our compatibility gains.

Standards Compliance: WebKit aims for compliance with relevant web standards, and support for new standards

Security: Protecting users from security violations is critical. We fix security issues promptly to protect users and maintain their trust.

WebKit is an engine, not a browser: We do not plan to develop or host a full-featured web browser based on WebKit.

WebKit is not the solution to every problem: We focus on web content, not complete solutions to every imaginable technology need.

三、WebKit主要组成
WebKit作为一个浏览器内核引擎，正如上面所描述，其主要内容专注在浏览器的核心部分Javascript的实现(JavaScriptCore)、布局渲染的实现(WebCore)以及对外接口的支持。

Gecko内核提供了一整套的与浏览器相关的解决方案如包括对NSPR、XPCOM、Network、Extension、XUL等的支持与实现等，但WebKit往往专注于核心部分，其他部分由外壳程序或其他公共库来实现，如其对Http请求的实现可由外部的公共库如libcurl、cf、soup等来提供实现，其本身不提供Http协议实现方面的代码，而Gecko中的Http请求完全由Gecko中的Network部分来实现。

为了跨越更多平台及图形库，WebKit提供了cairo、gtk、mac、win、qt、wxwidget等对外接口的支持，这方面并不比Gecko逊色多少。

对外部嵌入程序而言，WebKit提供了具有浏览器功能的、同时与外壳程序相对应的平台或图形库相关的动态库。如在Safari中WebKit内核仅以一个webkit.dll的形式出现。相对Gecko内核而言，虽然其功能比较少，但其使用起来简单方便，实现代码相对简洁，性能也不错。

四、参考资源
The WebKit Open Source Project
WiKi WebKit
Comparison of layout engines

浅谈Gecko关键部分之十四Build System

2008-08-20T20:49:00.000+08:00

Mozilla作为一个开源组织，为我们提供了完整的源代码，以便我们进行编译、调试等，为了能真正的运用Gecko内核，我们需要自己动手从源代码中进行编译，进而进行调试，从而真正了解、运用Gecko内核，以致修改、改进Gecko内核，或者自己编写出符合Gecko内核编写规则的应用等。下面提供一些参考资源，以便大家完成编译、调试等。

参考资源

浅谈Gecko关键部分之十三Xulrunner

2008-08-17T11:08:00.000+08:00

Gecko内核作为一个浏览器内核，为了能充分利用其已有的功能，Mozilla提供了一个可作为运行环境平台的Xulrunner，来扩展Gecko内核的应用。那么究竟什么是Xulrunner、如何实现一个Xulrunner应用程序、它和Firefox、ThunderBird等有什么区别、目前有哪些应用基于Xulrunner等等，通过下面的学习研究，希望能逐步的解答这些疑问。

一、什么是Xulrunner?
XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. It will provide mechanisms for installing, upgrading, and uninstalling these applications. XULRunner will also provide libxul, a solution which allows the embedding of Mozilla technologies in other projects and products.

其实质上是一个运行环境，类似于java虚拟机、Adobe AIR、Yahoo! Widget等，只不过它目前支持xul、xpcom、js、html等，而其他的运行环境大都有其对应的支持格式及实现方式等。有了Xulrunner，为开发Rich Internet application提供另一种实现方式。

Xulrunner基于Gecko内核，充分利用了其功能及实现方式，而Gecko内核的功能、性能及实现方式等在Firefox中得到了充分的体现与运用。这样Xulrunner应用程序基本上完全可以应用Firefox所拥有的功能。

二、如何实现一个Xulrunner应用程序
1、下载、安装Xulrunner;

2、创建应用目录结构，设置应用application.ini及chrome manifest；
application.ini内容大致如下：
[App]
Vendor=***
Name=Bamboo
Version=1.0
BuildID=2008052906
Copyright=Copyright (c) 1998 - 2008 mozilla.org
ID={ec6039f7-c60a-784f-9b0e-23b3a9e67323}
[Gecko]
MinVersion=1.9
MaxVersion=1.9
[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1
[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit

其中ID表示xulrunner应用的唯一ID，在编写extension时须指定该extension能够应用的目标程序，在其install.rdf的targetApplication项的ID中指定已知的应用ID(也即xulrunner应用在其application.ini中指定的ID)。如Firefox的应用ID为{ec8030f7-c20a-464f-9b0e-13a3a9e97384}。

3、创建xul、js文件；

4、设置应用选项；
在pref.js中指定Xulrunner应用程序启动的主窗口，如
pref("toolkit.defaultChromeURI", "chrome://myapp/content/main.xul");

5、运行Xulrunner应用程序；
.\xulrunner\xulrunner.exe application.ini

具体参考
Getting Started with XULRunner

三、Xulrunner和Firefox、ThunderBird等有什么区别?
Xulrunner作为一个运行环境，以供他人开发基于Xulrunner、基于Gecko内核的应用程序，从Gecko1.9以后，从严格的意义来讲，Firefox、ThunderBird等是基于Xulrunner而开发的，也是一个Xulrunner应用，只不过它得到Mozilla官方的支持，它是浏览器。

Mozilla在开发Firefox、Xulrunner、Gecko内核的过程中，不断的相互扩充，相互优化，相互促进，往往一个Firefox主要版本都对应一个Xulrunner版本，Xulrunner、Firefox对某一特性的支持程度有时有一些略微不一致，往往是由于对应版本未及时更新而造成的。

自Firefox3.0以来，通过firefox.exe -app application.ini的调用方式同样可以运行一个Xulrunner应用，只不过此时该Xulrunner应用的Gecko内核是当前Firefox对应Gecko内核。

到目前为止不同组织开发了许多基于Xulrunner的应用，如比较著名的有Songbird、Joost、Miro等等。

具体可参考
XULRunner Hall of Fame

四、开发Xulrunner应用程序与Embedding Gecko有什么不同？
以基于Xulrunner的方式开发应用，可以充分利用Gecko内核的所有功能(包括xul、xpcom、js等等)，入手比较简单，对开发者而言，只须专注实现自身所关心的部分，但要想真正开发出好的应用，需要对Gecko内核的方方面面拥有较深入的理解，难度较大，虽然其符合许多W3C标准，但Gecko内核的各个方面都自成一个体系(特别是xpcom)，与其他的库及开发平台的接口相对较少。同时Mozilla目前也推荐开发人员以运行平台的方式来利用Gecko内核。

通过Embedding Gecko的方式来利用Gecko内核，其实现方式和可利用的外部库等都比较灵活，不一定只限于与Gecko相关的实现方式或外部动态库，其往往将Gecko内核作为一个相对独立的外部库使用，但由于目前Gecko内核在Embedding方面的接口有限，不能让外部程序充分利用Gecko内核的功能，从而限制了外部程序对其利用，同时如只利用Gecko内核中浏览页面的部分功能，而需要嵌入整个Gecko内核，有点得不偿失。

究竟是使用Xulrunner的方式还是使用Embedding Gecko的方式来利用Gecko内核？
这就存在一个取舍的问题，如只须嵌入浏览页面的功能，嵌入IE内核或Webkit内核，肯定方便很多，嵌入Gecko内核，稍现复杂，但嵌入的功能都相对有限；想更进一步了解嵌入Gecko内核的内容，可参考浅谈Gecko关键部分之十二Embedding一节。

如使用Xulrunner的方式来利用Gecko内核，则须完全拥抱Xulrunner平台，可利用的功能丰富强大，需要学习研究的难度曲线较大，但是Mozilla毕竟是一个开源组织，其是否能提供一个高质量的可商用的运行环境，存在一定风险，有可能没有Microsoft、Adobe等商业公司提供的平台那样得到更广泛的支持。虽然如此，但其开放程度及对Web技术趋势的创新是独一无二的，再说目前其提供的文档越来越规范，应用越来越多。

五、总结
总的说来，如想真正深入的了解Web技术或浏览器，使用Xulrunner是个非常好的选择，但代价可能较高，如一旦真正掌握，则至少Web技术实力会很强；

如只是利用Web技术或浏览器，完全可抛开Gecko内核，利用IE内核或Webkit内核，来运用Web技术，但对Web技术的真正把握可能不是很深入；

作为一个开源爱好者，想更深入了解Web技术或浏览器，作手学习研究使用Firefox、Xulrunner等Gecko内核相关应用程序，是个不错的选择，因为它提供了很多非常不错的Web技术及工具如ajax、firebug、xul、venkman等；经过一定时间的运用，一定会收获颇多！

六、参考资源
Mozilla Developer center -XULRunner
Wiki XULRunner
What XULRunner Provides
XULRunner FAQ

奥运真的来啦！

2008-08-09T08:35:00.000+08:00

2008年8月8日20时，令人期盼以久激动人心的时刻终于来到，第29届北京奥林匹克运动会在北京鸟巢体育馆开幕啦！

经过洋洋洒洒4个多小时的激情澎湃之后，开幕式结束了，令人回味无穷。。。。

一、鲜明的主题，展示出中华民族灿烂辉煌的历史文化画卷
充分利用灯光道具的奇特效果，以历史画卷的形式，向全世界人民展现中华民族的重大历史时刻、思想文化现象等如击鼓、太极、丝绸之路、清明上河图、长城、京剧、木偶等，构思奇特，令人赞叹；

二、灯火辉煌，渲染北京，照耀中华，展示追逐奥运之梦
利用中华传统焰火，以历史足迹的形式，展现中华儿女百年追逐奥运之梦。客观而现实，令人感慨，回想起亲身经历的2001年7月13日奥运申办成功后的北京不眠之夜，天安门、西单、王府井等到处都是热烈狂欢的人们，尽情展现追逐奥运之情，犹如今日，感慨、欣喜;

三、令人感觉平淡的会歌及点火仪式
回想起以前汉城、洛杉机、巴塞罗那、悉尼、雅典等近现代奥运会歌及点火仪式，心中重新唤起对奥林匹克运动的激情，对奥林匹克精神的敬仰、向往。而我们的会歌及点火仪式，似乎构思一般，没有充分体现出奥林匹克核心精神如激情、自然、创新、执着、更高、更快、更强等。。。

也许奥林匹克精神本来就是泊来品，来自古老的西方，熊熊烈火能在古老的中华大地点燃，本身就象罗格、何振梁等所说本届奥运会是独一无二的，结点就在于此吧。

也许我们有太多令人值得回味的历史画卷，令人痴迷，沉醉其中，几乎忘了外界的一切，或者想将外部的一切也融入其中。

也许东西方的融合之路才逐步真正开始，近现代我们的激情、我们的创新、我们的自信、我们的文化、我们的思想、我们的体制等等正逐步追赶西方，正象夸父追日，有点真实而惭愧，但愿融合之路能令世人受益，让老百姓切切实实的受益，解放思想，提升生活质量，共同面对世界，实现共同之梦，真正实现One World One Dream，我们改变自己，改变世界。

我们不卑不亢，不留恋过去，忘掉耻辱，昂首迎接现在，拥抱世界，面对挑战，真实而自然，以更高、更快、更强的心态去创造美好生活，再现辉煌。。。。

一点感悟，可有偏颇？！但愿能激起一丝思考。。。

浅谈Gecko关键部分之十二Embedding

2008-08-05T18:46:00.000+08:00

随着Gecko内核的广泛使用，人们会期望Gecko内核能作为一个相对独立的拥有能访问Web、解析Html、渲染页面等浏览器基本功能的动态库甚至作为一个ActiveX或GtkWidget以供其他程序将其嵌入，就像大家熟知的MyIE作为一个外壳程序将IE内核以ActiveX的方式嵌入到其中，这样外壳程序相对简单，往往基于应用层，而内核则专注于html、css、dom等浏览器核心部分的处理，一旦能将浏览器内核以相对固定相对简单的接口形式提供给外部程序使用，则会大大拓展其应用包括动态脚本语言如python、perl、ruby都可能将其应用其中，其他的外壳程序也会应运而生。其实IE内核及Safari内核Webkit都提供了相对简单固定的接口供外部调用，这样才有了MyIE及Safari。那么Gecko内核是否也有类似的接口，外部程序又是如何嵌入的，这些与IE内核及Webkit等有什么差别呢？

一、认识Embedding接口
Gecko内核作为相对独立的部分嵌入到外部程序中，在本质上外部程序与Gecko内核的关系其实很类似Plugin与Gecko内核的关系，外部程序与Gecko内核需要分别实现一些接口，各负其责，以供对方调用，这样两者相互结合实现所要的功能。不过Gecko内核官方目前提供给外部调用的接口封装得不是很简单，使用起来也不是非常的方便，但通过对GTKMozEmbed、winEmbed等的了解，Gecko内核部分往往通过nsWebBrowser来实现public nsIWebBrowser、nsIWebNavigation、
nsIWebBrowserSetup、nsIDocShellTreeItem、nsIBaseWindow、nsIWebBrowserPersist、nsIWebBrowserFocus、 nsIWebProgressListener等接口，以代表一个浏览器页面浏览实例；

而外壳程序部分需要实现nsIWebBrowserChrome、nsIEmbeddingSiteWindow、nsIWebProgressListener、nsISHistoryListener、nsIContextMenuListener等接口以代表一个浏览器页面浏览外壳，供Gecko内核调用。

其中nsWebBrowser初始化后通过setcontainerWindow来设置其nsIWebBrowserChrome containerWindow为其对应的外壳实现，然后通过InitWindow、Create等方法可真正创建一个浏览器页面浏览实例，而外壳实现通过设置其nsIWebBrowser webBrowser为前面初始化的nsWebBrowser实例，这样两者可互为引用，同时外壳部分可向nsWebBrowser添加一些如WebProgress、ContextMenu等listener，以供Gecko内核nsWebBrowser需要时调用通知。

另外外壳部分需要实现接口nsIWindowCreator，并通过调用window watch service的方法setWindowCreator来告诉window watch service由外壳部分来createChromeWindow，以保证内核在由页面脚本通过window.open来打开新窗口时统一由外壳部分来创建新开的窗口。

上面提到的是Gecko内核为了实现Embedding，需要由内核部分与外壳部分分别实现的基本接口及相关调用关系，其中Gecko内核还提供有诸如NS_InitEmbedding、NS_TermEmbedding等XPCOM方面的接口以供外壳部分充分利用Gecko内核提供的XPCOM强大组件管理等功能。

为了更方便外壳程序的调用，Gecko也提供了诸如GtkMozEmbed widget及MozApp、MozView、 MozViewListener等，其实质仍属于上面提到的外壳部分，只不过更加的方便用户使用罢了。

二、外部程序如何嵌入Gecko内核
为了能真正了解如何将目前的Gecko内核嵌入到外部程序中，最好还是先参考Roll your own browser - An embedding HowTo按照其提供的编译方式，了解TestGtkEmbed、mfcEmbed等实现。通过对这些实例的了解才能对嵌入Gecko内核有一定的了解。

外部程序嵌入Gecko内核的主要步骤如下：
1、通过NS_InitEmbedding初始化内核；
2、通过 do_CreateInstance(NS_WEBBROWSER_CONTRACTID, &rv)创建mWebBrowser；
3、创建实现nsIWebBrowserChrome、nsIEmbeddingSiteWindow接口实例mpBrowserImpl；
4、创建绑定窗口
mpBrowserImpl->Init(mpBrowserFrameGlue, mWebBrowser);

mWebBrowser->SetContainerWindow(NS_STATIC_CAST(nsIWebBrowserChrome*, mpBrowserImpl));

nsCOMPtrsetup(do_QueryInterface(mWebBrowser));
if (setup)
setup->SetProperty(nsIWebBrowserSetup::SETUP_IS_CHROME_WRAPPER,PR_TRUE);

rv = mBaseWindow->InitWindow(nsNativeWidget(m_hWnd), nsnull,0, 0, rcLocation.right - rcLocation.left, rcLocation.bottom - rcLocation.top);
rv = mBaseWindow->Create();

5、添加监听
void mWebBrowser->AddWebBrowserListener(weakling, NS_GET_IID(nsIWebProgressListener));

6、设定WindowCreator、preference及promptservice等；

7、装载页面mWebNav＝nsCOMPtrsetup(do_QueryInterface(mWebBrowser));
if(mWebNav)
mWebNav->loadURI();

8、通过NS_TermEmbedding卸载内核，退出程序；

三、与IE内核、Webkit等嵌入方面的差别
同样作为浏览器内核，其实有很多文章就Gecko内核、IE内核、Webkit等多方面进行过比较如Comparison of layout engines。但就嵌入易用方面来讲，它们之间差别还是蛮大的，个人认为IE内核充分利用windows com技术，作为一个独立的ActiveX，其拥有很好接口封装，对windows用户来讲，大大提高了其易用性复用性；

Webkit内核本身一开始就专注于浏览器内核部分如KHTML、KJS，其提供给windows、gtk、mac等方面的接口也相对完毕；

Gecko内核往往不仅仅专注于浏览器内核如HTML、Javascript等方面，同时它还提供了XPCOM、XUL，从大的方面看，嵌入Gecko内核访问通用的html类的Web网站，只利用了其中一部分功能，其XUL、XPCOM等功能几乎可以不用，这样一来也是一种浪费，所以目前Embedding方面的接口，既要考虑到XPCOM方面，又要考虑到用户嵌入内核的易用性，显然没有IE内核及Webkit内核，简单明了，要想嵌入Gecko内核，需要对其进行深入的了解，这样反而降低了嵌入的意义。

顺便提一下，Avant/Orca Browser创始人宣称花了3年多的时间才将Gecko内核研究透彻，弄出个基于Gecko内核的浏览器Orca Browser，但其利用方式，不是基于Embedding的，而是基于Xulrunner的，这样既迎合了Gecko本身，同时能充分利用其强大功能，可谓一举两得，但是要想用好它，可要花上3、5年功夫不可。

四、总结
其实目前通过Embedding的方式使用Gecko内核的还不是很多，使用起来也比较困难，需要较深入的了解XPCOM等内核知识，比较好的实例也就只有上面提到的TestGtkEmbed、mfcEmbed等，可喜的是Mozilla最近似乎想重新加强其对Embedding方面的支持。详见Embedding/NewApi 及Chris Blizzard's blog。

另外Second life提供了一组接口以更加方便嵌入Gecko内核。详见uBrowser and LLMozLib。

四、参考资源
Mozilla project Embedding Mozilla
Mozilla developer center-Embedding Mozilla

Mozilla Embedding FAQ
Gecko Embedding Basics
Mozilla embedding APIs overview

浅谈Gecko关键部分之十一Extension

2008-08-02T07:33:00.000+08:00

Extension扩展或称Add-on外挂这些日子随着Firefox3的发布，逐步走入人们的视野，并且有些Extension确实赋有强大的功能，其中不乏有google、yahoo!等这样的大公司打造，甚至有人由此提出Firefox3掀起新的浏览器开发应用模式。那究竟什么是Extension？如何编写Extension?编写Extension需要哪些知识？它与plugin、xpcom等开发有什么不一样？为了解答心中疑问，下面分别就这些问题予以学习研究探讨。

一、什么是Extension?
Extensions add new functionality to Mozilla applications such as Firefox and Thunderbird. They can add anything from a toolbar button to a completely new feature. They allow the application to be customized to fit the personal needs of each user if they need additional features, while keeping the applications small to download.

它从小方面看，其实就是为Firefox等添加一些小的功能，如在菜单栏、地址栏、状态栏等添加一些小的按钮以扩展功能，有些类似于为IE等浏览器的工具栏、菜单栏等添加新的选项。

但从本质上看由于Gecko内核提供了xul、xpinstall、xpconnect、javascript、xpcom、rdf等相关技术，使得可通过extension的方式几乎可以扩展浏览器方方面面的内容(这一点完全可从Firfox Add-ons繁多种类的extension中窥见其一班)，更为特别的是整个浏览器Firefox本身几乎就是通过extension方式来实现的，完全超越了传统的扩展IE等浏览器的方式，同时gecko内核提供了包括extension资源标识、卸载安装等一系列支持，以便快速便捷为浏览器开发extension。

Gecko内核有这种对extension全方位的支持，仅此就完全超越了opera、safari、ie等传统浏览器内核，进而开拓出一种新的RIA（Rich Internet Application，富互联网应用系统）应用方式，虽然没有象microsoft、adobe等公司对xaml、flex那样的商业支持，但Gecko内核在RIA应用开发方面的技术研究、实现方式探索、还有开放方面等，都是首屈一指的。

二、如何编写Extension?
编写一个简单的Extension其实非常的简单，参考Building an extension一步一步的来设定extension资源标识rdf文件、chrome及manifest等包固定目录结构、编写js及xul文件、打包发布即可。

其中较为关键的在于xul文件中对xul标签overlay的使用，简单来的说来就是extension想在firefox浏览器的菜单栏或状态栏等什么位置添加上你的extension内容。具体对xul标签overlay的使用可参考XUL overlays。

尽管js文件在xul文件中可以加载，但是extension作为对firefox浏览器的扩展，这些overlay xul文件，一般也是在浏览器主窗口文件browser.xul加载时一块加载的。这样如果你的extension有一些初始化的需求，只须在js文件中添加window.addeventlistener('load', initfunc,false)即可。

三、编写Extension需要哪些知识？
编写一个简单的extension需要的知识似乎不要太多，但是编写出一个切实可用的extension，必须对以下方面下番功夫不可。

首先对Firefox本身的实现需要有一定的认识，如对browser.xul、browser.js的了解等，了解extension的运作机制如什么时候启动extension、如何响应用户事件等。

其次对xul、html、js、xpconnect需要有基本的认识，了解extension的基本构成元素，进而了解Gecko内核为extension提供的可用资源，同时重点关注自身extension所涉及的相关内容如xpcom组件、plugin、css、dom等等。

最后充分利用已有工具如venkman、dom inspect、firebug、xpcomviewer等以提供开发效率。

四、extension与plugin、xpcom等的区别
extension作为一种对浏览器的扩展机制，而不是对Gecko内核的扩展机制，而plugin、xpcom往往扩展Gecko内核的基础内容，可看成是对Gecko内核的扩展。其中plugin的扩展往往与页面上某一块区域内容显示相关，而xpcom往往扩展Gecko内核基本组件等。

为了扩展浏览器应用(浏览器其实只是Gecko内核应用的一个典型代表)，extension则完全可以使用Gecko内核提供的各种机制及技术，同时其本身也可扩展Gecko内核如提供独立的plugin、xpcom组件来扩展浏览器应用。这样说来extension开发，也可包括plugin、xpcom等等方面的开发，就看你所扩展的应用需求啦。

五、总结
Firfox Add-ons中提供了种类繁多的extensions给大家使用，其中不免有令人耳目一新的东西，令人感慨万千，进而发出互联网应用竟然可以这样的感慨。有了对extension的认识，我们就可以着手阅读他人所写的extension，更深入的了解Gecko内核，编写自己的extension，挖掘属于自己的互联网应用。

总之对Gecko内核了解得越深，编写起extension来就越得心应手，其实写这一系列浅谈Gecko的文章也就是为了了解Gecko内核，能编写extension，进而开拓属于自己的Gecko内核应用、互联网应用。

六、目前所关注的Firefox extensions
Dom Inspector
Firebug
Venkman
Xpcomviewer
IE Tab
Split Browser

Weave //有空可用用Mozilla主推的在线共享书签等
PicLens //一个超酷的3D在线图片、视频管理
HttpFox//一个很好的http分析
Gladder//一个蛮好用的代理
Extension Developer
Delicious

DownloadHelper//可从多个站点下载视频和图片
Feed Sidebar //显示实时书签
。。。。。。。。。。

七、参考资源
Mozilla developer center -Extensions
Building An extension
Extension Frequently Asked Questions
Setting up extension development environment
Code snippets

Mozilla developer center-XUL Overlays
XUL Tutorial:Overlays

WIKI Firefox extensions(Add-on)
WIKI List of Firefox extensions

浅谈Gecko关键部分之十XUL

2008-07-29T20:50:00.000+08:00

Gecko内核作为一个功能强大的浏览器内核，其提出XUL(XML User Interface Language)，并且由该语言来实现整个浏览器Firefox界面部分，XUL的实现从另个角度扩充了浏览器内核渲染引擎的内涵，因为它不仅仅可渲染HTML，同时可以象渲染HTML一样渲染xul，这样将XUL与HTML同等看待的浏览器内核实在独无仅有，从这个角度讲Gecko内核的渲染机制比IE、Webkit、Opera等浏览器内核要强大好多倍，因为它们目前本身仅仅支持HTML的渲染。虽然windows推出的XAML、adobe推出的Flex/Laszlo、yahoo widgets等都具有类似功能，但毕竟还没有与浏览器完全整合在一起。这样看来XUL作为Gecko内核的一部分具有根本而独特的作用，那就让我们抽时间来好好了解了解这个XUL。

一、什么是XUL?
XUL (XML User Interface Language) is Mozilla's XML-based language that lets you build feature-rich cross platform applications that can run connected or disconnected from the Internet. These applications are easily customized with alternative text, graphics and layout so they can be readily branded or localized for various markets.

二、XUL的实现机制
为了充分的达到利用XML+JS来实现图形界面程序，XUL作为一门类似HTML的语言，其中定义了一组标签、事件处理机制、渲染方式等，这些定义没有得到W3C等国际标准组织确认，仅由Mozilla组织定义并实现，解析处理一个xul文件的过程与处理html文件的主要过程是类似的，只不过在content、layout等方面有较大的不同，同时xul文件中可以嵌入html标签，将xul标签与html标签完全融为一体来处理，其主要处理过程完全类似浅谈Gecko关键部分之四The life of an html http Request中所描述的。

关于XUL具体定义的标签、CSS、事件处理等等，内容非常庞大，可具体参考下面提供的参考资源。

三、参考资源
WIKI XUL
Mozilla developer center-xul
XUL Reference
The Joy Of Xul
Xul Overlay
XUL Tutorial
XUL PLANET

WIKI XAML
WIKI Adobe Flex
WIKI Yahoo! Widget

浅谈Gecko关键部分之九Plugin

2008-07-28T18:25:00.000+08:00

Plugin作为一种对浏览器内核扩充的方式，为丰富浏览器应用提供了更加广阔的空间，如大家熟知的flash、java applet、window media player、vlc、adobe pdf等插件已经在人们的不知不觉中走到人们的生活当中，那么究竟什么是plugin？为firefox写的plugin能在其他浏览器中使用吗？如何为浏览器写plugin？浏览器实现plugin的机制及其基本原理如何？等等这些问题一直困扰在心头，现就这几方面来了解了解Gecko内核中的plugin实现等。

一、什么是plugin?
大家以前应该接触过一些关于plugin插件的概念，如eclipse就提供了很好的插件机制，以扩展ide的功能，apache也提供了丰富的插件机制，以丰富http server的处理请求。他们都有一个共同的特点就是以独立动态库的形式存在，动态库提供的输出接口应该满足主程序所规定的一些要求，以向主程序描述自身的特性及主要功能；而主程序也提供一组公共函数接口以供动态库调用，这样协同作业以完成任务。

在Gecko内核中plugin通过扩展html标签embed、object的MIMEtype类型的方式来拓展显示在一个页面中指定区域的内容。如大家熟知的application/x-shockwave-flash、application/x-java-applet、application/x-vlc-plugin等等，每一个plugin须说明自身所能支持的mime类型。一旦页面中遇到指定标签embed或object的mime类型，gecko内核就会搜索它目前所能支持的mime类型及对应的plugin，然后调用plugin中输出的接口由plugin来完成指定区域内的内容显示。

在Gecko内核中，就扩展的方向及方式的不同，plugin与xpcom拥有本质上的差别，plugin以扩展页面embed/object标签 mime类型的方式存在，往往与页面布局渲染相关，而xpcom是以扩展不同的组件种类，以实现不同内部功能的方式存在，它往往有更大的扩展空间包如字符串管理、线程管理、p2p传输管理等。他们的应用场景有本质上的差别，一般说来plugin相对内核而言更加独立如可以有独立的线程管理、内存管理、渲染方式等，而xpcom往往是内核中的一个组成部分。

Gecko内核plugin机制的实现接口Netscape Plugin Application Programming Interface
简称为NPAPI，它提供了相当完备的跨平台的接口框架，其中包括对Stream、Security、Scripting等方面的支持，目前包括Firefox、Opera、Safari、部分IE等浏览器都支持符合NPAPI接口标准的插件来扩展浏览器的功能。

二、如何编写plugin？
为了能编写plugin，首先需要了解其主要API，下面四个函数接口往往需要由plugin实现并export出去，可由外部即浏览器内核调用。
NPError WINAPI NP_Initialize(NPNetscapeFuncs* pFuncs);
当该plugin动态库第一次加载后浏览器内核会调用该方法，其中参数为当前内核提供给plugin调用的函数接口，plugin往往会将这些接口保存下来，以待以后使用；

NPError WINAPI NP_GetEntryPoints(NPPluginFuncs* pFuncs);
浏览器内核初始plugin动态库后，会调用该方法以获取该plugin实现的接口函数，内核会根据具体情况的不同来调用该plugin提供的不同接口函数；

NPError WINAPI NP_Shutdown();
当浏览器内核需要释放该plugin动态库时会调用该方法以告诉plugin其将会被释放；

char* NP_GetMIMEDescription(void);
浏览器内核通过该方法可获得该plugin支持的MIME类型，以便在解析页面embed/object标签时匹配其Type是否由哪个plugins来支持；

typedef struct _NPPluginFuncs {
uint16 size;
uint16 version;
NPP_NewUPP newp;
NPP_DestroyUPP destroy;
NPP_SetWindowUPP setwindow;
NPP_NewStreamUPP newstream;
NPP_DestroyStreamUPP destroystream;
NPP_StreamAsFileUPP asfile;
NPP_WriteReadyUPP writeready;
NPP_WriteUPP write;
NPP_PrintUPP print;
NPP_HandleEventUPP event;
NPP_URLNotifyUPP urlnotify;
JRIGlobalRef javaClass;
NPP_GetValueUPP getvalue;
NPP_SetValueUPP setvalue;
} NPPluginFuncs;

typedef struct _NPNetscapeFuncs {
uint16 size;
uint16 version;
NPN_GetURLUPP geturl;
NPN_PostURLUPP posturl;
NPN_RequestReadUPP requestread;
NPN_NewStreamUPP newstream;
NPN_WriteUPP write;
NPN_DestroyStreamUPP destroystream;
NPN_StatusUPP status;
NPN_UserAgentUPP uagent;
NPN_MemAllocUPP memalloc;
NPN_MemFreeUPP memfree;
NPN_MemFlushUPP memflush;
NPN_ReloadPluginsUPP reloadplugins;
NPN_GetJavaEnvUPP getJavaEnv;
NPN_GetJavaPeerUPP getJavaPeer;
NPN_GetURLNotifyUPP geturlnotify;
NPN_PostURLNotifyUPP posturlnotify;
NPN_GetValueUPP getvalue;
NPN_SetValueUPP setvalue;
NPN_InvalidateRectUPP invalidaterect;
NPN_InvalidateRegionUPP invalidateregion;
NPN_ForceRedrawUPP forceredraw;
} NPNetscapeFuncs;
NPPluginFuncs、 NPNetscapeFuncs结构中的函数接口分别由plugin和浏览器内核提供实现，而让对方调用。每个接口的具体含义及什么时候调用可参考下面提到的相关资源。

三、Gecko内核的plugin实现机制及基本原理
Gecko内核作为外部调用plugin的主程序，它不仅提供一组NPNetscapeFuncs函数接口给plugin调用，同时需要管理所有的plugin动态库、针对不同embed/object创建不同的plugininstance以及相关安全、创建窗口句柄、释放资源等。

在Gecko内核中提供了如下几个主要头文件、接口及类来完成相关任务。
\mozilla\modules\plugin\base\public\Npapi.h
\mozilla\modules\plugin\base\public\Npupp.h
\mozilla\modules\plugin\base\public\Npruntime.h
这几个头文件包含实现plugin所需要的函数接口、常量定义、数据结构定义等；

nsIPluginTag.idl
主要代表一个plugin动态库基本信息包括文件名、描述等；
nsIPluginTagInfo.idl/nsIPluginTagInfo2.idl
主要代表一个embed/object标签所描述的内容如MIME类型、参数、宽高等；
nsIPlugin.idl
主要描述一个plugin动态库所对应的initialize、shutdown、getMIMEDescription、getValue及创建plugin实例方法createPluginInstance，相当于plugin动态库加载后该plugin所提供的函数入口等；
nsIPluginInstance.idl
主要描述一个plugin动态库所实现的一个plugin实例所对应的函数接口，如initialize、start、stop、destroy、setWindow、newStream、getValue、handleEvent等；
nsIPluginHost.idl
主要描述如何装载plugin动态库、实例化EmbededPlugin、FullPagePlugin、检查指定MIME类型是否有对应plugin来实现等；

由类nsPluginHostImpl来代表"@mozilla.org/plugin/manager;1"、"@mozilla.org/plugin/host;1"来管理plugin等；它主要实现了接口nsIPluginHost、nsIPluginManager2等，提供了
void loadPlugins();
nsIPlugin getPluginFactory(in string aMimeType);
void instantiateEmbeddedPlugin(in string aMimeType, in nsIURI aURL, in nsIPluginInstanceOwner aOwner);
void setUpPluginInstance(in string aMimeType, in nsIURI aURL, in nsIPluginInstanceOwner aOwner);
void stopPluginInstance(in nsIPluginInstance aInstance);
等主要方法；

由类ns4xPlugini来实现nsIPlugin接口，其中维护了上面提到的函数接口
NPPluginFuncs fCallbacks;
PRLibrary* fLibrary;
NP_PLUGINSHUTDOWN fShutdownEntry;
/**
* The browser-side callbacks that a 4.x-style plugin calls.
*/
static NPNetscapeFuncs CALLBACKS;

在nsPluginHostImpl.cpp中通过static nsActivePluginList *gActivePluginList;来维护一组当前活动的plugin
class nsActivePluginList
{
public:
nsActivePlugin * mFirst;
nsActivePlugin * mLast;
PRInt32 mCount;
................................
};

struct nsActivePlugin
{
nsActivePlugin* mNext;
char* mURL;
nsIPluginInstancePeer* mPeer;
nsRefPtr mPluginTag;
nsIPluginInstance* mInstance;
PRTime mllStopTime;
PRPackedBool mStopped;
PRPackedBool mDefaultPlugin;
PRPackedBool mXPConnected;
//Array holding all opened stream listeners for this entry
nsCOMPtr mStreams;
.........................................
};

由nsPluginHostImpl、ns4xPlugin及nsActivePluginList等类能够维护好plugin动态库的加载、创建一个新plugin实例等，哪究竟是由谁来加载动态库、创建新的plugin实例呢？

作为一个html embed/object标签，其对应的元素为nsHTMLObjectElement，其继承自nsGenericHTMLFormElement、nsObjectLoadingContent、nsIDOMHTMLObjectElement，其中nsObjectLoadingContent提供了下面主要的方法
nsObjectLoadingContent::LoadObject(const nsAString& aURI,
PRBool aNotify, const nsCString& aTypeHint, PRBool aForceLoad)

nsresult nsObjectLoadingContent::TryInstantiate(const nsACString& aMIMEType,
nsIURI* aURI)

而nsHTMLObjectElement往往对应有nsObjectFrame；其中包含有 nsRefPtr mInstanceOwner;

而nsPluginInstanceOwner中含有如下元素：
nsPluginNativeWindow *mPluginWindow;
nsCOMPtr mInstance;
nsObjectFrame *mOwner;
nsCOMPtr mContent;
nsCString mDocumentBase;
char *mTagText;
nsCOMPtr mWidget;
nsCOMPtr mPluginTimer;
nsCOMPtr mPluginHost;

有了对基本的数据结构理解之后这样在parser html内容时，会根据embed/object标签创建nsHTMLObjectElement、nsObjectFrame、nsPluginInstanceOwner等实例，进而在nsHTMLObjectElement的LoadObject方法驱动下逐步的调用TryInstantiate、Instantiate、InstantiateEmbeddedPlugin、TrySetUpPluginInstance、Create4xPlugin等等，从而完成一个plugin实例的生成等。

至于其Scripting、Stream、security方面的支持须进一步参考nsIDOMClassInfo、nsGenericHtmlObjectSH及nsIPluginStreamListener等；

四、总结
通过初步了解plugin的实现机制后，然后自己动手参照Mozilla提供的plugin examples及相关API，完成一个基本的Plugin难度其实并不大，但是如想利用plugin技术实现如3D、Stream Media、叠加等方面的效果，须更进一步的了解3D、Stream Media等方面的内容。其实支持Gecko内核的Plugin相当多，如主流的播放器、flash、java applet、silverlight等等都有浏览器插件，再加上支持Gecko内核的plugin一般也支持Opera、Safari，这样如果我们掌握了NPAPI Plugin技术，那么我们就可以充分运用已有的plugin或自己动手创建一个好用的plugin，这样会大大的扩展浏览器的应用，让我们拭目以待吧。。。。。

五、参考资源
WIKI NPAPI
Mozilla projects -plugins
Mozilla developer center -plugins
Netscape Gecko Plugin API Reference
Mozilla Plugin Support on Microsoft Windows

浅谈Gecko关键部分之八NSPR

2008-07-24T21:22:00.000+08:00

Gecko内核作为一个跨平台的内核，具有很强的跨平台系统处理能力，其中就缺不了Netscape Portable Runtime (NSPR)的功劳，要想深入的了解Gecko内核，就不得不了解了解NSPR，它提供了基础性系统性功能的封装，在此基础上才有了线程管理、内存管理、I/O管理等等，下面提供一些资料以供参考学习。

一、什么是NSPR?
The Netscape Portable Runtime, or NSPR, is a platform abstraction library that makes all operating systems it supports appear the same to Mozilla. NSPR provides platform independence for non-GUI operating system facilities. These facilities include threads, thread synchronization, normal file and network I/O, interval timing and calendar time, basic memory management (malloc and free) and shared library linking.

相关参考资源
NSPR WiKi
Mozilla NSPR HomePage
NSPR Reference

二、为什么了解NSPR?
除了Gecko内核是基于NSPR的，其他一些应用也是基于NSPR；它具有很强的稳定性、可复用性等，了解NSPR，对了解Gecko内核是不可或缺的，就像想了解Apache Http Sever，就必须对APR有所了解。

了解了NSPR，除了让我们能更好更快更清晰的了解Gecko内核，其实还可以让我们从另一个侧面更好的了解不同操作系统的主要差异如线程的实现、线程同步的实现、I/O管理的不同等等，从而提升我们对操作系统的认识，进一步的把握计算机技术。

相关参考资源
Apache Portable Runtime(APR) WiKi
Simple DirectMedia Layer(SDL) WiKi

浅谈Gecko关键部分之七安全及其实现

2008-07-20T15:47:00.000+08:00

很长一段时间以来Firefox以安全、小巧、快捷著称，从而逐步从饱受不安全批评的IE中抢夺到部分用户的支持，在用户心中确立了Firefox比IE更安全的想法，其实浏览器的安全一直受到人们的广泛关注，但往往不能做到百分百的完美，似乎总有一些遗憾的地方，正所谓道高一尺魔高一丈。为了更深入的了解浏览器技术，安全正可谓不得不面对的问题，也许它比较的复杂，涉及面比较广，还是让我们从安全问题的出现、Gecko内核的安全策略及其主要实现路径等方面来学习研究，以便达到以一窥十的效果。

一、安全问题的出现
浏览器作为一个通往互联网的入口，其可以连接访问的网站成千上万，并且类型也缤纷多彩，正是这一点突出了浏览器功能强大、实用的特点，进而确立其在互联网应用中不可缺失的地位，但同时也带来了人们的疑虑，我们刚才访问的网站是否下载了病毒、是否破坏了操作系统、提交的数据如用户名密码是否泄漏、访问的历史记录是否遭到外部网站的截取等等。这些问题从浏览器出现的一刻起就受到浏览器开发者的关注，到目前为止，有些浏览器还是受到人们广泛的质疑。

其实困扰人们心中的浏览器安全问题往往可分为两类：
对用户本地私有数据的保护
私有数据往往包含两方面，一方面在于操作系统的文件是否遭到访问、读写等，其实一旦存在这类漏洞，其危害是特别大的，往往会导致整个操作系统的不安全，我们以前通过IE访问不良网站时，经常会遭遇到木马等病毒的骚扰，其实问题的出现正是由于病毒利用了activex组件等方面的漏洞，从而重新配置操作系统，并下载病毒文件等。另一方面在于保护用户保存的Cookie、历史访问记录，提交的表单数据是否遭到非法访问，在同一浏览中同时打开的不同页面是否能相互访问，共享数据等。

其实在浏览器设计之初就充分考虑到这些方面的问题，特别在javascript设计之初，因为浏览器能够执行外部网站的操作往往来源于javascript脚本，一旦能控制住浏览器为脚本提供的接口的安全性，浏览器的安全问题就得到架构上保证，再加上javascript本身是脚本语言，这样为任何一句脚本语言提供执行前的检查提供了可能。正是基于这样的出发点，javascript的实现是基于sanbox技术的，脚本语言的执行是在一个安全的上下文中进行的，它所造成的危害是可控的如从理论上讲，javascript是不可以访问操作系统文件的，是不可以上传不由用户指定的任意文件的。当然其中很多相关的安全细则可参考相关js手册，其实现是由内核来提供保证的。

对用户提交给网站数据的保护
浏览器往往通过http协议来与网站进行数据交互，由于http协议属于应用层协议，交互的数据对网络层来讲是透明的，也是不安全的，作为一个能广泛使用的应用程序，为了满洲需对提供的银行帐户与密码进行加密等需求，浏览器必须提供一些数据加密措施来保证数据交互的安全。基于这一点及广泛标准的支持，Gecko内核采用了PKI开源应用模块(相对来说蛮独立)来保证数据加密的要求如对PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, TLS, SSL v2 and v3, X.509 v3 certificates等方面的支持，而没有使用目前很多项目都采用的OpenSSL来对SSL的支持，不过SSL作为一个标准，无论采取OpenSSL还是PKI，只不过是实现上的不同而已。

其中人们经常听说的反钓鱼技术，往往与此有点关联。
网络钓鱼 (phishing)是国际通用的新字，取phreak(偷接电话线的人)的前两个字母ph取代fishing(钓鱼)的f，是以社会工程学（也就是骗术）结合电脑科技的新犯罪手法。

网络钓鱼的目的是骗取受害人的网站上的帐号密码（网络银行或线上游戏）、信用卡资料以及个人资料，进行例如线上转帐、偷取游戏虚拟宝物、窥伺别人的email以及盗刷银行卡等违法行为。

钓鱼正以一种新的犯罪形式侵犯，在不断侵犯普通网民的合法利益，具体表现在伪装“网络银行”窃取用户的银行卡卡号和密码，转走用户在银行的存款；伪装成网络游戏的官方网站窃取用户的网游帐号，转走用户在游戏里面的虚拟货币或者虚拟装备；伪装成送QQ币的网站让用户输入QQ号和密码进而窃取QQ号……

其中Firefox应该是目前提供反钓鱼技术最好的浏览器，它不仅提供反盗取密码等网站，还提供反不安全、非法及含有黄色内容的网站。
其实现机制往往结合nsIContentPolicy接口及维护后台不安全网站列表来共同实现。

如须具体了解数据加密的内容，可更加深入的了解PKI OpenSource等方面的知识，这次主要学习研究对本地私有数据安全方面的内容。

二、Gecko内核的安全策略
为了保证数据的提交与行为的安全执行，Gecko内核中提供两种安全策略，Same-Origin Policy和Security Zones and Signed Scripts。

其中Same-Origin Policy的主要含义在于一段脚本只能访问具有同一来源的window及document的内容，同一来源包括同一主机、同一端口、同一协议，同时为了对扩展域名的支持，同一来源也指具有同一domain的不同window及document。

而Security Zones and Signed Scripts指的是为了给一段脚本更高的访问权限，需要由用户确认后来授权该脚本可以拥有更高的权限。其实现的方式有通过SignTool及安全Jar的方式来授权、提示用户由用户来确认的方式来授权。其中前一种相当复杂，普通用户使用较少，而后一种方式应用较多，并且可以由用户自己来配置一些对象的属性、方法的访问权限或自定义一些域名浏览器访问权限，下面示例一些权限设置。
user_pref("capability.policy.default.Window.open", "noAccess");

user_pref("capability.policy.policynames", "strict");
user_pref("capability.policy.strict.sites", "http://www.evil.org http://www.annoying.com"); user_pref("capability.policy.strict.Window.alert", "noAccess");
user_pref("capability.policy.strict.Window.confirm", "noAccess");
user_pref("capability.policy.strict.Window.prompt", "noAccess");

user_pref("capability.principal.codebase.p2.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p2.id", "http://192.168.1.200");
user_pref("capability.principal.codebase.p2.subjectName", "");

一段脚本可拥有的浏览器访问权限包括UniversalBrowserRead、UniversalBrowserWrite UniversalXPConnect、UniversalPreferencesRead、UniversalPreferencesWrite CapabilityPreferencesAccess、UniversalFileRead等，它们可以通过netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead");等方式来设置权限，如果用户的signed.applets.codebase_principal_support配置选项设为true，在设置权限时会提示用户是否设置该codebase权限。

三、安全主要实现路径
首先由javascript SpiderMonkey提供了一组安全方面的接口，以供脚本安全的检查，至于具体的安全规则则由xpconnect及securitymanager来实现，主要接口有JSPrincials、JS_CheckAccess、
JSObjectOps.checkAccess、JSClass.checkAccess、JS_SetPrincipalsTranscoder等；

然后由nsScriptSecurityManager来管理维护其提供的nsPricipal实例及相关的安全检查，其中在其初始化时完成如下主要操作：

nsresult nsScriptSecurityManager::Init()
{
nsresult rv = InitPrefs();//将用户自定义的pricipal组织起来
NS_ENSURE_SUCCESS(rv, rv);
。。。。。。。。。。。。。。。。
// Create our system principal singleton
nsRefPtr system = new nsSystemPrincipal();
NS_ENSURE_TRUE(system, NS_ERROR_OUT_OF_MEMORY);
rv = system->Init();
NS_ENSURE_SUCCESS(rv, rv);

mSystemPrincipal = system;
。。。。。。。。。。。。。。。
//-- Register security check callback in the JS engine
// Currently this is used to control access to function.caller
nsCOMPtr runtimeService =
do_GetService("@mozilla.org/js/xpc/RuntimeService;1", &rv);
NS_ENSURE_SUCCESS(rv, rv);

rv = runtimeService->GetRuntime(&sRuntime);
NS_ENSURE_SUCCESS(rv, rv);

//CheckObjectAccess成为安全检查的主要入口点
JS_SetCheckObjectAccessCallback(sRuntime, CheckObjectAccess);

sXPConnect->GetXPCWrappedNativeJSClassInfo(&sXPCWrappedNativeJSClass,
&sXPCWrappedNativeGetObjOps1,
&sXPCWrappedNativeGetObjOps2);

return NS_OK;
}

在实现的过程中会提供一些nsPrincipal实例如nsNullPrincipal、nsSystemPrincipal来表示不同的安全规则，同时每一个nsPricipal实例都包含一个JSPricipals接口实例，其内容可由JS_SetPrincipalsTranscoder来根据不同情况来设定，这样可以为不同的JSContext、JSClass、JSObject、JSFunction设置对应的JSPricipals，由它可以获得nsPrincipal实例，以了解真正的安全规则。

其中由SpiderMonkey JS Engineer内部或Xpconnect、nsScriptSecurityManager等外部在需要实施安全规则检查的地方如检查xpcom组件接口参数发起JS_CheckAccess的执行，其中会调用上面提到的回调函数CheckObjectAccess，以触发nsSecurityManager来统一对安全的检查，起到sanbox的作用。具体的nsPricipal及nsSecurityManager的管理可参考\mozilla\caps\src\nsPricipal.cpp及nsScriptSecurityManger.cpp等，至于如何为JS对象设置一些JSPricipals则需要更深入对函数JS_SetPrincipalsTranscoder的调用与实现作一些了解。

四、参考资源
Mozilla Security Review and Best Practices Guide
The Same Origin Policy
Signed Scripts in Mozilla
Configurable Security Policies
JSAPI User Guide
Open Source PKI Projects

浅谈Gecko关键部分之六认识javascript实现及应用

2008-07-13T01:22:00.000+08:00

作为一个目前应用范围非常广的脚本语言javascript，或许每一个程序员都听说过并使用过，但据部分统计，许多程序员对javascript的认识存在一定误解，认为它非常简单，会写javascript简直算不了什么，并且认为它在Web开发中的地位根本没有如php、ruby等开发语言及所谓的框架那么实用好用，以致没有重视javascript在Web开发中所应有的作用。为寻求Gecko内核究竟是如何实现javascript以及它在内核中的地位究竟如何，乃至进一步探讨一下javascript的发展方向，下面分别就什么是Javascript、它在Gecko中的实现及其扩展、应用等方面作一些学习研究总结，以致从整体上对javascript有更清晰的认识。

一、什么是javascript?
javascript是一门动态、弱类型、基于原型的脚本语言，其核心部分包含对脚本的编译、解析、执行、反编译、垃圾回收及标准类/类型如 bool、string、number的实现等；然后在此基础通过将已经符合DOM标准的文档DOM接口按照javascript接口定义及声明的方式绑定/导出到 javascript运行环境中，以丰富javascript的内涵，其本质相当于有了java虚拟机后，通过import不同类型的类库来扩展 java语言的应用。

目前javascript比较独特的地方在于它自身没有一个完整独立的运行环境，其往往依附于浏览器，由浏览器来提供运行环境，并控制或发起javascript进行编译、解析执行脚本、垃圾回收等，其核心部分相当于一个符合ECMAScript标准的动态库，以供浏览器来调用，这样看来其本质是为了对浏览器主要部分的扩展及更灵活运用的支持，从MVC的角度来看，javascript相当于浏览器中的控制部分，其应用场景往往具有一定的局限性、独特性的；而通用的脚本语言如perl、python、 ruby等都提供了完整独立的语言运行环境及线程管理等，并且提供了良好的扩展机制以丰富语言的内涵。

在Gecko内核中xpconnect扮演为javascript提供运行环境及扩展的角色，其不仅将符合DOM标准的接口扩展到javascript运行环境中去，同时将大部分xpcom接口也扩展到整个javascript运行环境中，这一点在其他浏览器如Safari、IE是没有的，这样就奠定了 javascript在整个Gecko内核中不仅可访问文档的DOM接口，同时可以访问极大部分xpcom接口，进而可以使用javascript编写 xpcom组件，以供其他xpcom组件访问。从架构的角度看Gecko内核对javascript的扩展提供了极大的支持，但由于Gecko内核中有一部分重要组件是由javascript来实现的，从而绑定javascript成为Gecko内核的核心部分，虽然这样给程序的开发带来了极大的方便性，但也带来了调试等方面的不便。

二、javascript在Gecko中的实现及其扩展
为了更好的扩展及模块化，Mozilla对 javascript的实现是以SpiderMonkey+xpconnect的方式来实现的，其中SpiderMonkey主要是按照 ECMAscript的方式来实现javascript语言的核心部分，其提供了一组公共JSAPI以供外部调用，SpiderMonkey是相当独立的一部分，它可以单独编译，可以嵌入到其他程序中去，下一个版本可能会整合Tamarin相关的内容；

而xpconnect作为一个xpcom服务类组件，具有sington特性，从javascript 语言的角度来看，它为javascript提供了运行环境，同时按照SpiderMonkey提供的JSAPI对其进行了扩展；从xpcom角度来看，xpconnect将很大一部分xpcom接口以javascript的接口方式绑定出去，以便其能在javascript的运行环境中以 javascript的方式来引用xpcom组件及接口。其复杂程度是相当大的，因为它既要按照ECMAScript标准的要求考虑到脚本语言方面的控制如动态性、安全方面等，同时它要尽可能将xpcom组件方面的接口绑定出去给javascript脚本使用，并且两者的内存管理、对象生命周期的管理机制是完全不同的，再加上javascript及xpcom本身具有一定的动态特性。因此，xpconnect部分也就成为内存泄漏及效率提升方面的重点关注对象。

SpiderMonkey按照ECMAScript标准提供的主要外部接口有：
Starting up相关JS_NewRuntime、JS_NewContext、JS_NewObject、JS_InitStandardClasses
Defining objects and properties相关JS_DefineObject、JS_DefineProperties
Defining functions and classes相关JS_DefineFunctions、JS_InitClass
Execute/Call function相关JS_EvaluateScript、JS_ExecuteScript、JS_CallFunctionName
Shutting down相关JS_DestroyContext、JS_DestroyRuntime、JS_ShutDown
其具体实现及应用可以参考后面提供的网址。

xpconnect is a technology which enables simple interoperation between XPCOM and JavaScript.
其主要内容有
将用c/c++实现的xpcom组件接口(包含标准的DOM、CSS接口等)绑定出去给javascript运行环境使用。
为了统一方便使用，Gecko内核提出供一组nsDOMClassInfo子类，如nsWindowSH、nsLocationSH、 nsElementSH、nsDocumentSH等，作为Script Helper类，他们实现了接口nsIXPCScriptable及nsIClassInfo。

每当xpconnect需要将原生c/c++xpcom组件对象绑定给javascript使用时，它可通过 InitClassesWithNewWrappedGlobal或WrapNative方法来处理，但都会调用到 XPCConvert::NativeInterface2JSObject方法，这个方法主要处理过程是：
首先获取该组件对象对应的nsDOMClassInfo子类实例，整个Gecko内核拥有很多Script Helper nsDOMClassInfo子类实例(其往往在初始化时存储在一个Hash表中，并建好相关查询索引)；

然后利用获取的Script Helper nsDOMClassInfo子类实例的PreCreate方法来创建该组件对应的jsObject，同时会创建XPCWrappedNative类实例，在其中保存好mScriptableInfo信息，其如nsCOMPtr mCallback往往为nsDOMClassInfo子类实例，

如需要会为其创建prototype原型对象以便后面共享，这时需要向javascript运行环境提供一组回调API，其主要函数在 mozilla\js\src\xpconnect\Xpcwrappednativejsops.cpp中如 XPC_WN_Helper_AddProperty、XPC_WN_Helper_DelProperty、 XPC_WN_Helper_NewResolve等，通过观测这些回调函数发现他们往往首先会通过传递过来的jsObject获取 XPCWrappedNative对象，然后获取其ScriptableInfo,根据相关flag来决定是否调用Script Helper 实例中对应的方法，而Script Helper实例往往在初始时就已经知道原生绑定出去的xpcom组件能支持的一些xpcom接口，进而可以对原先不认识的接口、属性、方法、参数，进行 QueryInferface，进行WrapNative处理，将结果返回给js使用。

其中需要注意的是有些组件或类对象没有直接实现nsIClassInfo，哪么nsCOMPtr info ＝do_QueryInterface(aComObj);是如何获得Script Helper nsIClassInfo 实例呢？

费了九牛二虎之力，终于发现Gecko内核中使用了一些诡异的办法来到达目的的。示例如下：

定义一个Macro
#define NS_DOM_INTERFACE_MAP_ENTRY_CLASSINFO(_class) \
if (aIID.Equals(NS_GET_IID(nsIClassInfo))) { \
foundInterface = NS_GetDOMClassInfoInstance(eDOMClassInfo_##_class##_id); \
if (!foundInterface) { \
*aInstancePtr = nsnull; \
return NS_ERROR_OUT_OF_MEMORY; \
} \
} else

而extern nsIClassInfo* NS_GetDOMClassInfoInstance(nsDOMClassInfoID aID);就是根据ID到sClassInfoData数组中去匹配即可，这个数组在初始化时就填充完毕，其不同ID值对应不同的 nsIClassInfo 实例如nsWindowSH、nsDocumentSH实例等。

而在\mozilla\dom\src\base\nsGlobalWindow.cpp中通过
// QueryInterface implementation for nsGlobalChromeWindow
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION_INHERITED(nsGlobalChromeWindow)
NS_INTERFACE_MAP_ENTRY(nsIDOMChromeWindow)
NS_DOM_INTERFACE_MAP_ENTRY_CLASSINFO(ChromeWindow)
NS_INTERFACE_MAP_END_INHERITING(nsGlobalWindow)
来设定do_QueryInterface时对nsIClassInfo的支持。
另外还有一些类也是通过该方式来对nsIClassInfo的支持。

三、javascript在Gecko中的应用
在Gecko内核及Firefox本身的实现中使用了很多javascript代码，其中不仅仅是对基本javascript语言及DOM 接口的使用，同时充分利用了上面提到到xpcom绑定出去的组件接口，假如对xpcom及其绑定原理不是很清楚，也就对Firefox当中许多js看不懂，往往让人纳闷Gecko内核中的js为什么会多出这么多非ECMAScript所定义的关键字如Components、interfaces、classes等，其具体含义是什么？虽然XULPlant.org对其中有一定的说明，但还是显得抽象，不具体。在有了上面最基本的认识后，如需全面掌握Gecko内核究竟向javascript绑定导出了多少接口、属性及方法等，可具体参考文档\mozilla\dom\src\base\nsDOMClassInfo.cpp的nsDOMClassInfo::Init()方法中一大段关于nsIDOMClassInfo方面的初始化。如
DOM_CLASSINFO_MAP_BEGIN(Window, nsIDOMWindow)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMWindow)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMJSWindow)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMWindowInternal)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMEventTarget)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMViewCSS)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMAbstractView)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMStorageWindow)
DOM_CLASSINFO_MAP_END

DOM_CLASSINFO_MAP_BEGIN(Location, nsIDOMLocation)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMLocation)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMNSLocation)
DOM_CLASSINFO_MAP_END

DOM_CLASSINFO_MAP_BEGIN(XMLHttpRequest, nsIXMLHttpRequest)
DOM_CLASSINFO_MAP_ENTRY(nsIXMLHttpRequest)
DOM_CLASSINFO_MAP_ENTRY(nsIJSXMLHttpRequest)
DOM_CLASSINFO_MAP_ENTRY(nsIDOMEventTarget)
DOM_CLASSINFO_MAP_ENTRY(nsIInterfaceRequestor)
DOM_CLASSINFO_MAP_END

这样就对Firefox browser.js中的类似下面的代码就不觉得迷糊啦。
const nsCI = Components.interfaces;
const nsIWebNavigation = nsCI.nsIWebNavigation;
window.XULBrowserWindow = new nsBrowserStatusHandler();
window.QueryInterface(nsCI.nsIInterfaceRequestor)
.getInterface(nsIWebNavigation)
.QueryInterface(nsCI.nsIDocShellTreeItem).treeOwner
.QueryInterface(nsCI.nsIInterfaceRequestor)
.getInterface(nsCI.nsIXULWindow)
.XULBrowserWindow = window.XULBrowserWindow;
window.QueryInterface(nsCI.nsIDOMChromeWindow).browserDOMWindow = new nsBrowserAccess();

四、总结
经过上面的学习研究，觉得不管是javascript基本语法及应用方面，还是其具体实现方面，还有xpconnect实现方面等，都可单独写一本书来描述，其内容实在太多，并且比较复杂，以后可多花点心力来继续了解他们。但是为了更好的了解其实现过程，能充分发挥javascript优势，不妨多用用DOM Inspecter及javascript debuger venkman等工具。

五、参考资源
Wiki Script language
WiKi Javascript
Core Javascript1.5 Guide
XPConnect(Scriptable Components)
The Mozilla DOM Hacking Guide
JavaScript-DOM Prototypes in Mozilla
JSAPI User Guide
SpiderMonkey Internals
SpiderMonkey Thread Safety
SpiderMonkey Garbage Collection Tips
How to embed the javascript engine
Tamarin

浅谈Gecko关键部分之五认识HTML、DOM、CSS、XML、XHTML、SVG等标准

2008-07-07T20:02:00.000+08:00

在了解Gecko内核是如何响应用户输入的Web地址，如何渲染、显示包含文字、图片、动画甚至视频的画面给用户的整个过程之后，假如我们深思一下，Gecko内核为什么要这样解析、渲染这个Web地址对应的内容？为什么不那样解析？它在解析、渲染的时候会受到约束吗？它可以自由发挥吗？答案是肯定，它所受的约束也就是我们熟知的W3C标准，它是尽可能按照标准来办事的，当然标准当中也肯定有未尽之事，所以它也有一定的自由发挥空间。正是有了如此众多的W3C标准，让我们的互联网应用是如此的丰富多彩，IE、Safari、Opera等浏览器都基本按照标准办事，所以我们编写的符合标准的Web页面可以在如此多的浏览器上被解析、渲染显示出来，并且效果基本一致。标准也就是协议，所以我们要想深入的了解Gecko内核，必须深入的了解它所支持的标准。下面初略的介绍一下HTML、DOM、CSS、XML、XHTML、SVG等标准。

一、HTML
HTML, an initialism of HyperText Markup Language, is the predominant markup language for web pages. It provides a means to describe the structure of text-based information in a document — by denoting certain text as links, headings, paragraphs, lists, and so on — and to supplement that text with interactive forms, embedded images, and other objects. HTML is written in the form of tags, surrounded by angle brackets. HTML can also describe, to some degree, the appearance and semantics of a document, and can include embedded scripting language code (such as JavaScript) which can affect the behavior of Web browsers and other HTML processors.

具体可参考
HTML Wiki
HTML 4.01 Specification
HTML 5 Specification

二、DOM
The Document Object Model (DOM) is a platform- and language-independent standard object model for representing HTML or XML and related formats.

A web browser is not obliged to use DOM in order to render an HTML document. However, the DOM is required by JavaScript scripts that wish to inspect or modify a web page dynamically. In other words, the Document Object Model is the way JavaScript sees its containing HTML page and browser state.

具体可参考
DOM Wiki
DOM2 Html Specification

三、CSS
Cascading Style Sheets (CSS) is a stylesheet language used to describe the presentation of a document written in a markup language. Its most common application is to style web pages written in HTML and XHTML, but the language can be applied to any kind of XML document, including SVG and XUL.

具体可参考
CSS Wiki
CSS Specification

四、XML
The Extensible Markup Language (XML) is a general-purpose specification for creating custom markup languages.^[1] It is classified as an extensible language because it allows its users to define their own elements. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet,^[2] and it is used both to encode documents and to serialize data. In the latter context, it is comparable with other text-based serialization languages such as JSON and YAML.^[3]

具体可参考
XML Wiki
XML Specification

五、XHTML
The Extensible Hypertext Markup Language, or XHTML, is a markup language that has the same depth of expression as HTML, but also conforms to XML syntax.

具体可参考
XHTML Wiki
XHTML Specification

六、SVG
Scalable Vector Graphics (SVG) is an XML specification and file format for describing two-dimensional vector graphics, both static and animated. SVG can be purely declarative or may include scripting. Images can contain hyperlinks using outbound simple XLinks.^[2] It is an open standard created by the W3C's SVG Working Group.

具体可参考
SVG Wiki
SVG Tiny1.2 Specification

七、总结
面对如此众多的W3C标准，特别是W3C上发布的标准文档，我们往往会看得云里雾里，毕竟这些标准文档是所谓的专家学者所写，够严谨全面的。为了便于日常运用，我们只要把握两条即可1、懂得其基本用途及主要要素； 2、必要时刻需仔细研读之，定会收获众多，她们就像我们的良师益友，平时没事的时候可常习之。

浅谈Gecko关键部分之四The life of an html http Request

2008-07-05T10:32:00.000+08:00

从用户的角度来看，一个浏览器其实是相当简单的，用户输入一个Web地址，然后按回车，等不了多久，一个具有丰富内容的画面就会出现在用户面前，其中包含五彩缤纷的排列整齐的文字、图片、动画甚至视频，用户通过点击自己感兴趣的地方，新的内容画面就会呈现在用户面前，这样用户就可以只需简单的点击一下鼠标就可以在互联网上自由遨游啦。现在回想起来，也许正是浏览器当初在设计的时候充分考虑到用户的易用性才导致互联网的蓬勃发展，正像谷歌提供搜索一样简单易用并且非常实用，这样说来，互联网的发展离不开浏览器，是她带领人们走向了互联网，回顾历史让我们感慨万千，那么浏览器主要做了些啥？她为什么能支持如此丰富的内容？她的发展方向在哪里？为了解答心中的疑问，首先让我们初步了解Gecko内核是如何完成从用户输入Web地址，直到内容丰富的画面显示出来的整个过程，这个过程涉及的面比较广，目前我们主要关心关键过程、关键点及相关的关键类的实现，争取能有个整体的而又完整的印象。

一、创建nsWebShellWindow实例，准备处理输入的WebURI地址；
因为接收用户打开一个新URI的情况比较多，如通过脚本中的window.open或直接在地址栏中输入或者在新开的一个窗口打开或者在新建的一个页签打开等等，通过对这一系列的打开一个页面的外围场景进行处理后，内核都会新建一个或利用原有的nsWebShellWindow实例来处理整个打开URI的过程。其包含的主要成员有nsComPtr mWindow，代表一个原生窗口，将要打开的页面可在其中显示内容如文字、图片等；nsComPtr mDocShell，代表一个协调者，它管理整个打开URI的过程，其实现类nsDocShell也就成为整个Gecko内核的核心部分，它不仅接收处理打开URI请求，同时提供接口以反馈相关信息给外部如提示正在打开某某地址等。在nsWebShellWindow的Initialize()方法中通过mWindow = do_CreateInstance(kWindowCID, &rv);来创建mWindow，通过mDocShell = do_CreateInstance("@mozilla.org/webshell;1");来创建设置mDocShell为打开URI做好前期准备。

二、准备装载指定URI的内容；
首先由协调者nsDocShell的LoadURI方法来发起装载的请求，经过一番安全或请求Policy等方面的设定后创建nsCOMPtr uriLoader=do_GetService(NS_URI_LOADER_CONTRACTID, &rv);
nsCOMPtr channel;
rv = NS_NewChannel(getter_AddRefs(channel),
aURI, nsnull, nsnull, static_cast(this), loadFlags);
由uriLoader->OpenURI(aChannel, (mLoadType == LOAD_LINK), this);来统一继续处理所有的URI请求，其中会创建一个临时的nsCOMPtr loader =new nsDocumentOpenInfo(aWindowContext, aFlags, this);同时将loader作为一个nsIStreamListener来接收请求而来的数据，以分析请求而来的文档类型如text/html、xml等以决定后续不同的处理，然后由rv = channel->AsyncOpen(loader, nsnull);来真正向Web服务发出请求，并通过异步的方式来处理接收数据，这里往往会涉及到以前提到的线程处理等，总之至此基本的准备动作应该都已准备好，就等待Web服务端返回数据啦。

三、根据接收的数据类型创建Document及相关ContentViewer;
根据异步数据的获取，获取数据的线程向MainThread发出nsInputStreamReadyEvent事件，由主线程来处理相关事件，其往往会调用到nsInputStreamPump中去，其关键调用如下：
nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *stream)
{
LOG(("nsInputStreamPump::OnInputStreamReady [this=%x]\n", this));

// this function has been called from a PLEvent, so we can safely call
// any listener or progress sink methods directly from here.

for (;;) {
if (mSuspendCount || mState == STATE_IDLE) {
mWaiting = PR_FALSE;
break;
}

PRUint32 nextState;
switch (mState) {
case STATE_START:
nextState = OnStateStart();
break;
case STATE_TRANSFER:
nextState = OnStateTransfer();
break;
case STATE_STOP:
nextState = OnStateStop();
break;
}
...........

mState = nextState;
}
return NS_OK;
}

当STATE_START时，表示已获取部分初始数据，其中OnStateStart()会调用作为Channel的streamListener的OnStartRequest方法，此时streamListener为uriLoader临时创建的nsDocumentOpenInfo实例loader，由它来处理，其方法OnStartRequest进而由nsDocumentOpenInfo的DispatchContent方法来尝试决定能否处理该文档类型，一旦决定可以处理该类型，进而由nsDSURIContentListener的DoContent来调用nsDocShell的方法CreateContentViewer来创建Document及Viewer，其中主要进行代码包括：
{
..........................................
// Instantiate the content viewer object
nsCOMPtr viewer;
nsresult rv = NewContentViewerObj(aContentType, request, mLoadGroup,
aContentHandler, getter_AddRefs(viewer));

NS_ENSURE_SUCCESS(Embed(viewer, "", (nsISupports *) nsnull),
NS_ERROR_FAILURE);
............................................
}
nsresult
nsDocShell::NewContentViewerObj(const char *aContentType,
nsIRequest * request, nsILoadGroup * aLoadGroup,
nsIStreamListener ** aContentHandler,
nsIContentViewer ** aViewer)
{
nsCOMPtr aOpenedChannel = do_QueryInterface(request);

nsresult rv;
nsCOMPtr catMan(do_GetService(NS_CATEGORYMANAGER_CONTRACTID, &rv));
if (NS_FAILED(rv))
return rv;

nsXPIDLCString contractId;
rv = catMan->GetCategoryEntry("Gecko-Content-Viewers", aContentType, getter_Copies(contractId));

// Create an instance of the document-loader-factory
nsCOMPtr docLoaderFactory;
if (NS_SUCCEEDED(rv))
docLoaderFactory = do_GetService(contractId.get());

if (!docLoaderFactory) {
return NS_ERROR_FAILURE;
}

// Now create an instance of the content viewer
// nsLayoutDLF makes the determination if it should be a "view-source" instead of "view"
NS_ENSURE_SUCCESS(docLoaderFactory->CreateInstance("view",
aOpenedChannel,
aLoadGroup, aContentType,
static_cast(this),
nsnull,
aContentHandler,
aViewer),
NS_ERROR_FAILURE);

(*aViewer)->SetContainer(static_cast(this));
return NS_OK;
}

这里主要会根据contentType的不同创建不同的Document对象，它由nsContentDLF::CreateInstance来实现。其主要代码如下

nsCOMPtr doc;
nsCOMPtr docv;
do {
// Create the document
doc = do_CreateInstance(aDocumentCID, &rv);//针对htmldocumnt、xuldocument、imagedocument的不同会对应不同的DocumnetCID
if (NS_FAILED(rv))
break;

// Create the document viewer XXX: could reuse document viewer here!
rv = NS_NewDocumentViewer(getter_AddRefs(docv));
if (NS_FAILED(rv))
break;
docv->SetUAStyleSheet(gUAStyleSheet);

doc->SetContainer(aContainer);

// Initialize the document to begin loading the data. An
// nsIStreamListener connected to the parser is returned in
// aDocListener.
rv = doc->StartDocumentLoad(aCommand, aChannel, aLoadGroup, aContainer, aDocListener, PR_TRUE);
if (NS_FAILED(rv))
break;

// Bind the document to the Content Viewer
rv = docv->LoadStart(doc);
*aDocViewer = docv;
NS_IF_ADDREF(*aDocViewer);
} while (PR_FALSE);

其中需要注意的是在StartDocumentLoad的时候会创建一个mParser = do_CreateInstance(kCParserCID, &rv);作为DocListener，以供后面解析文档内容用；同时会创建nsCOMPtr sink，以供后面组织文档内容用；创建ContentSink的主要代码逻辑如下：
// create the content sink
nsCOMPtr sink;

if (aSink)
sink = aSink;
else {
if (IsXHTML()) {
nsCOMPtr xmlsink;
rv = NS_NewXMLContentSink(getter_AddRefs(xmlsink), this, uri,
docShell, aChannel);

sink = xmlsink;
} else {
nsCOMPtr htmlsink;

rv = NS_NewHTMLContentSink(getter_AddRefs(htmlsink), this, uri,
docShell, aChannel);

sink = htmlsink;
}
NS_ENSURE_SUCCESS(rv, rv);

NS_ASSERTION(sink,
"null sink with successful result from factory method");
}

mParser->SetContentSink(sink);
// parser the content of the URI
mParser->Parse(uri, nsnull, (void *)this);
}

一旦初步组织好nsDocShell、Document、Viewer、Parser、ContentSink之间的关系后，在nsDocumentOpenInfo调用DispatchContent时将返回的DocListener也即nsParser实例赋值给nsDocumentOpenInfo的m_targetStreamListener，以供后续使用，同时告诉Parser、ContentSink作好解析、组织文档准备；

另外通过nsDocShell的Embed方法，初始化DocumentViewer，其主要实现如下：
nsDocShell::SetupNewViewer(nsIContentViewer * aNewViewer)
{
..........................
mContentViewer = aNewViewer;
nsCOMPtr widget;
NS_ENSURE_SUCCESS(GetMainWidget(getter_AddRefs(widget)), NS_ERROR_FAILURE);

nsCOMPtr deviceContext;
if (widget) {
deviceContext = do_CreateInstance(kDeviceContextCID);
NS_ENSURE_TRUE(deviceContext, NS_ERROR_FAILURE);
deviceContext->Init(widget->GetNativeData(NS_NATIVE_WIDGET));
}

nsRect bounds(x, y, cx, cy);

mContentViewer->Init(widget, deviceContext, bounds);
..........................
}

DocumentViewerImpl::InitInternal(nsIWidget* aParentWidget,
nsISupports *aState,
nsIDeviceContext* aDeviceContext,
const nsRect& aBounds,
PRBool aDoCreation,
PRBool aInPrintPreview,
PRBool aNeedMakeCX /*= PR_TRUE*/)
{
.......................................
if (aParentWidget && !mPresContext) {
// Create presentation context
if (mIsPageMode) {
//Presentation context already created in SetPageMode which is calling this method
}
else
mPresContext =
new nsPresContext(mDocument, nsPresContext::eContext_Galley);
NS_ENSURE_TRUE(mPresContext, NS_ERROR_OUT_OF_MEMORY);

nsresult rv = mPresContext->Init(aDeviceContext);
if (NS_FAILED(rv)) {
mPresContext = nsnull;
return rv;
}

if (aDoCreation && mPresContext) {
// The ViewManager and Root View was created above (in
// MakeWindow())...

rv = InitPresentationStuff(!makeCX, !makeCX);
}
................................................
}

DocumentViewerImpl::InitPresentationStuff(PRBool aDoInitialReflow, PRBool aReenableRefresh)
{
..............................................

// Create the style set...
nsStyleSet *styleSet;
nsresult rv = CreateStyleSet(mDocument, &styleSet);
NS_ENSURE_SUCCESS(rv, rv);

// Now make the shell for the document
rv = mDocument->CreateShell(mPresContext, mViewManager, styleSet,
getter_AddRefs(mPresShell));

mPresShell->BeginObservingDocument();//mDocument->AddObserver(mPresShell);
..............................................

}

nsDocument::doCreateShell(nsPresContext* aContext,
nsIViewManager* aViewManager, nsStyleSet* aStyleSet,
nsCompatibility aCompatMode,
nsIPresShell** aInstancePtrResult)
{
*aInstancePtrResult = nsnull;

NS_ENSURE_FALSE(mShellsAreHidden, NS_ERROR_FAILURE);

FillStyleSet(aStyleSet);

nsCOMPtr shell;
nsresult rv = NS_NewPresShell(getter_AddRefs(shell));
if (NS_FAILED(rv)) {
return rv;
}

rv = shell->Init(this, aContext, aViewManager, aStyleSet, aCompatMode);
NS_ENSURE_SUCCESS(rv, rv);

// Note: we don't hold a ref to the shell (it holds a ref to us)
NS_ENSURE_TRUE(mPresShells.AppendElementUnlessExists(shell),
NS_ERROR_OUT_OF_MEMORY);
shell.swap(*aInstancePtrResult);

return NS_OK;
}
这样同时准备好与显示相关的nsDeviceContext、nsPresContext、nsPresShell，其中需要留意的是nsPresShell对象是作为nsDocument实例对象的一个Observer，同时也是nsViewManager实例对象的一个Observer；至此初始化完nsPresShell，并加入到nsViewManager的管理机制中去，为后面创建新的nsView对象及进行布局安排、显示内容作好准备。

四、解析、组织文档内容，同时作好布局准备
继续查看nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream *stream)方法中的STATE_TRANSFER时，表示已获取相关文档数据，此时会继续利用uriLoader临时创建的nsDocumentOpenInfo，由它的方法OnDataAvailable来继续处理获得的数据，其实现如下：

NS_IMETHODIMP nsDocumentOpenInfo::OnDataAvailable(nsIRequest *request, nsISupports * aCtxt, nsIInputStream * inStr, PRUint32 sourceOffset, PRUint32 count)
{
// if we have retarged to the end stream listener, then forward the call....
// otherwise, don't do anything
nsresult rv = NS_OK;
if (m_targetStreamListener)
rv = m_targetStreamListener->OnDataAvailable(request, aCtxt, inStr, sourceOffset, count);
return rv;
}
此时其m_targetStreamListener值也即上面创建出来的nsParser实例，
这样正好一环套一环，任务转交给了上面准备好的nsParser；
Gecko内核中的Parser有HtmlParser以解析html文档；xmlParser以解析符合xml格式的文档如xul、svg；CssParser以解析Css文档等。解析器通过Tokenizer来认识文档中的标识，然后结合不同文档类型预定义的Atom及ContentSink来组织想要的文档结构。整个HtmlParser的解析过程还是蛮复杂的，不过无论解析的过程怎样，其结果就是会适时的调用ContentSink中的主要方法，如OpenHead、OpenBody、CloseBody、OpenForm、CloseForm、OpenContainer、CloseContainer、StartLayout、ProcessLINKTag、ProcessSCRIPTEndTag、ProcessSTYLEEndTag等；

其中需要留意的是在构建文档结构的同时往往需要对不同的Content Node 创建对应Frame对象，同时针对不同的Frame，还时可能还需要构建nsView，如nsBoxFrame，在一些条件下需要调用方法CreateViewForFrame来创建一个nsView实例，其主要代码如下：
{
// Create a view
nsIView *view = viewManager->CreateView(aFrame->GetRect(), parentView, visibility);
if (view) {
// Insert the view into the view hierarchy. If the parent view is a
// scrolling view we need to do this differently
nsIScrollableView* scrollingView = parentView->ToScrollableView();
if (scrollingView) {
scrollingView->SetScrolledView(view);
} else {
viewManager->SetViewZIndex(view, autoZIndex, zIndex);
// XXX put view last in document order until we can do better
viewManager->InsertChild(parentView, view, nsnull, PR_TRUE);
}
}

// Remember our view
aFrame->SetView(view);
}

NS_IMETHODIMP_(nsIView *)
nsViewManager::CreateView(const nsRect& aBounds,
const nsIView* aParent,
nsViewVisibility aVisibilityFlag)
{
nsView *v = new nsView(this, aVisibilityFlag);
if (v) {
v->SetPosition(aBounds.x, aBounds.y);
nsRect dim(0, 0, aBounds.width, aBounds.height);
v->SetDimensions(dim, PR_FALSE);
v->SetParent(static_cast(const_cast(aParent)));
}
return v;
}

同时对于一些nsView还需要通过其nsIView::CreateWidget方法来创建原生的窗口，主要代码如下

nsresult nsIView::CreateWidget(const nsIID &aWindowIID,
nsWidgetInitData *aWidgetInitData,
nsNativeWidget aNative,
PRBool aEnableDragDrop,
PRBool aResetVisibility,
nsContentType aContentType,
nsIWidget* aParentWidget)
{
nsView* v = static_cast(this);

v->LoadWidget(aWindowIID))
..................................
mWindow->Create(aNative, trect, ::HandleEvent, dx, nsnull, nsnull, aWidgetInitData);
..............................
}
在mWindow->Create中会接着调用如nsWindow::StandardWindowCreate、BaseCreate等；
其中参数::HandleEvent会在创建原生窗口时保存在nsWindow的属性成员mEventCallback中;这个函数句柄在原生窗口的处理函数中经过一定处理后往往根据一定上下文而去调用它，它会处理如WM_SIZE、WM_PAINT等主要消息，后面的处理会引用到。

五、显示文档内容
在上面解析、组织文档结构时，当调用OpenBody时会适时调用StartLayout，其主要代码如下
{
nsPresShellIterator iter(mDocument);
nsCOMPtr shell;
while ((shell = iter.GetNextShell())) {
// Make sure we don't call InitialReflow() for a shell that has
// already called it. This can happen when the layout frame for
// an iframe is constructed *between* the Embed() call for the
// docshell in the iframe, and the content sink's call to OpenBody().
// (Bug 153815)

PRBool didInitialReflow = PR_FALSE;
shell->GetDidInitialReflow(&didInitialReflow);
if (didInitialReflow) {
// XXX: The assumption here is that if something already
// called InitialReflow() on this shell, it also did some of
// the setup below, so we do nothing and just move on to the
// next shell in the list.
continue;
}

nsRect r = shell->GetPresContext()->GetVisibleArea();
nsCOMPtr shellGrip = shell;
nsresult rv = shell->InitialReflow(r.width, r.height);

}

由nsPresShell的InitialReflow方法来启动布局，主要作用是根据文档元素的类型、属性的不同，而决定是否需要重新布局该文档元素及其子元素，一旦觉得有必要重新布局则调用nsPresShell的PostReflowEvent方法，它通过向主线程MainThread发送一个ReflowEvent，一旦MainThread接收到该ReflowEvent，其会由对应nsPresShell的DoFlushPendingNotifications方法来处理，其最终根据当前的nsView及原生窗口的不同，在windows平台上它会对原生的窗口句柄进行InvalidateRect或UpdateWindow处理，按照windows图形管理的逻辑，系统会根据相关条件，及时向该原生窗口句柄发送原生的WM_PAINT消息，而对处理原生的窗口消息，一般会由窗口创建时提供的窗口回调函数来处理，经过一番处理判断后会触发调用nsWindow::DispatchWindowEvent，进而会调用上面提到的mEventCallback所对应的公共的函数，其实现如下：
//
// Main events handler
//
nsEventStatus PR_CALLBACK HandleEvent(nsGUIEvent *aEvent)
{
//printf(" %d %d %d (%d,%d) \n", aEvent->widget, aEvent->widgetSupports,
// aEvent->message, aEvent->point.x, aEvent->point.y);
nsEventStatus result = nsEventStatus_eIgnore;
nsView *view = nsView::GetViewFor(aEvent->widget);

if (view)
{
view->GetViewManager()->DispatchEvent(aEvent, &result);
}

return result;
}
进而由nsViewManager::DispatchEvent统一来处理事件，这时经过一些处理，往往需要重新渲染相关View，而渲染View的主要代码如下：

void nsViewManager::RenderViews(nsView *aView, nsIRenderingContext& aRC,
const nsRegion& aRegion)
{
if (mObserver) {
nsView* displayRoot = GetDisplayRootFor(aView);
nsPoint offsetToRoot = aView->GetOffsetTo(displayRoot);
nsRegion damageRegion(aRegion);
damageRegion.MoveBy(offsetToRoot);

aRC.PushState();
aRC.Translate(-offsetToRoot.x, -offsetToRoot.y);
mObserver->Paint(displayRoot, &aRC, damageRegion);
aRC.PopState();
}
}
而上面提到的nsPresShell实例往往作为nsViewManager的一个Observer，这样工作就这样转交给nsPresShell来处理。而nsPresShell的Paint方法的主要内容如下：

PresShell::Paint(nsIView* aView,
nsIRenderingContext* aRenderingContext,
const nsRegion& aDirtyRegion)
{
AUTO_LAYOUT_PHASE_ENTRY_POINT(GetPresContext(), Paint);
nsIFrame* frame;
nsresult rv = NS_OK;

if (mIsDestroying) {
NS_ASSERTION(PR_FALSE, "A paint message was dispatched to a destroyed PresShell");
return NS_OK;
}

NS_ASSERTION(!(nsnull == aView), "null view");

frame = static_cast(aView->GetClientData());
nscolor backgroundColor;
mViewManager->GetDefaultBackgroundColor(&backgroundColor);
for (nsIView *view = aView; view; view = view->GetParent()) {
if (view->HasWidget()) {
PRBool widgetIsTransparent;
view->GetWidget()->GetHasTransparentBackground(widgetIsTransparent);
if (widgetIsTransparent) {
backgroundColor = NS_RGBA(0,0,0,0);
break;
}
}
}

if (!frame) {
if (NS_GET_A(backgroundColor) > 0) {
aRenderingContext->SetColor(backgroundColor);
aRenderingContext->FillRect(aDirtyRegion.GetBounds());
}
return NS_OK;
}

nsLayoutUtils::PaintFrame(aRenderingContext, frame, aDirtyRegion,
backgroundColor);

return rv;
}

相关主要工作又转交给nsLayoutUtils::PaintFrame；其主要工作就是通过 nsDisplayListBuilder builder来建立一个nsDisplayList list，并调用nsDisplayList::Paint方法，其实现如下：

void nsDisplayList::Paint(nsDisplayListBuilder* aBuilder, nsIRenderingContext* aCtx,
const nsRect& aDirtyRect) const {
for (nsDisplayItem* i = GetBottom(); i != nsnull; i = i->GetAbove()) {
i->Paint(aBuilder, aCtx, aDirtyRect);
}
nsCSSRendering::DidPaint();
}

在其中的for循环中会根据DisplayList Item构成的不同，会调用不同frame的Paint方法等，如
nsDisplayText::Paint(nsDisplayListBuilder* aBuilder,
nsIRenderingContext* aCtx, const nsRect& aDirtyRect) {
static_cast(mFrame)->
PaintText(aCtx, aBuilder->ToReferenceFrame(mFrame), aDirtyRect);
}
通过这样一个流程，就会显示出相关内容给用户。

六、总结分析
通过上面初步的整理，对整个过程有了初步的了解，其中关键在于了解到LoadURI的发起、nsIStreamListener数据的接收、nsParser及nsContentSink对文档的组织构成、nsPresShell结合nsFrame、nsView、nsViewManager、nsWindow对内容的显示。总的说来整个过程是相当的复杂，毕竟自从Web服务端获取数据后在内核中需要不断的动态创建很多对应的类对象，但关键流程的流转在于对nsInputStreamReadyEvent事件和ReflowEvent两个事件的处理，有了这样基本的认识之后，对于css文档、image文档、js文档、plugin的处理，应该有了扎实的基础准备，至于具体每一html标签、xul标签具体对应哪些Node、Frame、Widget还须具体结合自身的不同加以分析。

七、参考网址
The Life Of An HTML HTTP Request

浅谈Gecko关键部分之三线程管理及主要线程

2008-06-27T22:04:00.000+08:00

作为一个浏览器内核，Gecko所要完成的任务是非常繁杂的，其主要任务就是根据用户提供的资源地址，通过http协议从Web服务器中取得页面文档，然后解析其内容，最后根据一定的约定在浏览器指定区域中显示出页面，其中往往涉及网络编程及图形界面编程，而大家通常都知道的是网络编程中的连接、读取数据等往往需要考虑到服务器端的情况，一般采用异步方式来确保有效处理服务端返回的数据包括连接不成功、错误处理等；而图形界面的处理往往需要采用一个主消息循环及回调函数的方式来处理用户的动作，为了给用户提供平滑的操作及兼顾后台服务器的不确定性，一个可行的浏览器内核必须充分利用多线程来协调处理复杂的应用场景，只有这样才能高效的完成其所要完成的任务，如果能够初步了解Gecko内核的线程模型及相关线程管理的知识，对了解Gecko是非常有帮助的，下面初步了解Gecko是如何进行线程管理及其主要线程实现。

一、Gecko线程模型
为了统一接口编程，Gecko将其线程模型按照组件的方式来处理，定义的接口主要有nsIRunnable、nsIEventTarget、nsIThread、nsIThreadManager、nsIThreadPool，其中nsIThreadManager由nsThreadManager来实现，它主要用于来管理所有的nsThread，包括创建nsThread实例，并通过维护一些系统原生线程的属性可以判断同一段代码是在什么线程的上下文中调用，从而可作出不同的处理，如GetIsMainThread可以判定当前执行线程是否为主线程，这一点在Gecko中应该得到了充分的应用，同时nsThreadManager的实例属于sington模式，在第一次启用XPCOM组件时由NS_InitXPCOM3实例化出来，以供以后管理nsThread使用；

nsThread代表一个一般意义上的原生线程，在其构造函数中会初始化它并启动原生线程，它同时增加了EventQueue及ThreadObserver的概念，其函数入口为nsThread::ThreadFunc，在线程的整个周期中也即nsThread::ThreadFunc中不断的处理外部线程或本身向其EventQueue中Dispatch来的Event，同时每处理一个Event之前都会检查其是否存在Observer，如存在则先让Observer调用其OnProcessNextEvent来处理该Event，然后调用Event本身提供的run方法，这样增加了nsThread处理Event的灵活性；同时nsThread统一由nsThreadManager来创建，通过调用其Shutdown方法来结束该线程；并提供了一组外部接口来进行线程管理操作，如
NS_NewThread、NS_GetMainThread、NS_DispatchToMainThread、NS_ProcessNextEvent等以供不同线程调用，同时保证线程安全；

nsThreadPool代表一组线程，当外部向其Dispatch一个Event时它先会向其中的EventQueue添加该Event，然后它会根据设置的参数来决定是否分配一个nsThread来处理该Event，一旦创建了一些nsThread则将其维护在mThreads队列中，同时向该nsThread Dispatch这个nsThreadPool实例以让该nsThread去执行该nsThreadPool的run方法，这样可保证线程池中的每个nsThread的执行体都是nsThreadPool中的run方法，在其run方法中会根据是否空闲等条件自动ShutDown一些暂时不用的nsThread，以达到线程池的目的，即当任务事件Event繁多的时候多开启一些线程来处理，一旦任务完成则释放大部分空闲线程，保持一小部分线程以等待新任务的分配及提交；nsThreadPool在异步读取网络流数据的时候会经常用到，以后有机会可具体分析其应用场景；

二、Gecko主要线程
MainThread是Gecko的主线程，也即进程启动时的执行序列，它主要处理图形界面的消息循环以及其他线程向它Dispatch过来的Event，这样可以有机的结合图形界面的处理及网络数据的读取、解析、渲染等。MainThread线程充分利用了Gecko线程模型特点，既能处理原生的窗口消息，又可及时处理其它线程通知给它的Event，其执行主体往往是Gecko的核心，据初步统计其执行时间往往占整个程序执行时间的90%以上，其效率的高低直接决定了是否会让用户产生阻塞停顿的感觉。其主要实现逻辑是在启动XPCOM当中会在nsThreadManager初始化时自动产生一个nsThread实例mMainThread，它代表进程启动时的执行序列，待该执行序列完成其他基本准备后，在nsBaseAppShell::Init中将其Observer设置为nsBaseAppShell实例本身，具体参考如下：

nsresult nsBaseAppShell::Init()
{ // Configure ourselves as an observer for the current thread:
nsCOMPtr threadInt = do_QueryInterface(NS_GetCurrentThread()); NS_ENSURE_STATE(threadInt);
threadInt->SetObserver(this);//mObserver=>this
nsCOMPtr obsSvc = do_GetService("@mozilla.org/observer-service;1");
if (obsSvc) obsSvc->AddObserver(this, NS_XPCOM_SHUTDOWN_OBSERVER_ID, PR_FALSE);
return NS_OK;
}

NS_IMETHODIMP nsBaseAppShell::Run(void)
{
nsIThread *thread = NS_GetCurrentThread();
NS_ENSURE_STATE(!mRunWasCalled); // should not call Run twice mRunWasCalled = PR_TRUE;
while (!mExiting) NS_ProcessNextEvent(thread);
NS_ProcessPendingEvents(thread);
return NS_OK;
}

PRBool NS_ProcessNextEvent(nsIThread *thread, PRBool mayWait)
{
nsCOMPtr current;
if (!thread) {
NS_GetCurrentThread(getter_AddRefs(current));
NS_ENSURE_TRUE(current, PR_FALSE);
thread = current.get();
}
PRBool val;
return NS_SUCCEEDED(thread->ProcessNextEvent(mayWait, &val)) && val;
}

NS_IMETHODIMP nsThread::ProcessNextEvent(PRBool mayWait, PRBool *result)
{
..........
nsCOMPtr obs = mObserver;
if (obs) obs->OnProcessNextEvent(this, mayWait && !ShuttingDown(), mRunningEvent);

mEvents->GetEvent(mayWait && !ShuttingDown(), getter_AddRefs(event));
*result = (event.get() != nsnull);
nsresult rv = NS_OK;
if (event) {
++mRunningEvent;
event->Run();
--mRunningEvent;
}
else if (mayWait)
{ .........}

if (obs) obs->AfterProcessNextEvent(this, mRunningEvent);
..........
return rv;
}

其中关键点在于MainThread的mObserver是nsAppShell实例，那么它的OnProcessNextEvent都作了些啥呢？主要是根据情形调用其ProcessNextNativeEvent方法，其实现如下：

PRBool nsAppShell::ProcessNextNativeEvent(PRBool mayWait)
{
PRBool gotMessage = PR_FALSE;
do
{
MSG msg; // Give priority to system messages (in particular keyboard, mouse, timer, // and paint messages).
if (PeekKeyAndIMEMessage(&msg, NULL) ::PeekMessageW(&msg, NULL, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE) ::PeekMessageW(&msg, NULL, 0, 0, PM_REMOVE))
{
gotMessage = PR_TRUE;
if (msg.message == WM_QUIT)
{
Exit();
}
else {
::TranslateMessage(&msg);
::DispatchMessageW(&msg);
}
}
else if (mayWait) {
// Block and wait for any posted application message
::WaitMessage();
}
} while (!gotMessage && mayWait);
return gotMessage;
}
这个函数是否觉得非常的面熟？？？

nsSocketTransportService作为异步处理socket读写的线程，在程序启动就会实例化，有时间可以仔细看看\mozilla\network\base\src\nsSocketTransportService2.cpp，其主要代码应该与一般多线程网络程序差不多。

至于其他关于TimerThread、ThreadPool及javascript垃圾回收线程等以后有时间再来分析。

三、参考网址
The Thread Manager
XPCOM:nsIThreadManager

浅谈Gecko关键部分之二内存分配使用回收

2008-06-20T21:25:00.000+08:00

2008年6月17日Firefox3Release版本已正式发布啦，可喜可贺，毕竟经历3年多的努力Mozilla社区终于又能给大家带来一些震撼、新希望，甚至冲动，其中包含很多人性化的东东以及最近几年发展起来的很多有趣的extensions，并且经过一些比较，似乎这个版本部分解决了困扰人们很久的内存使用大多及内存泄漏的问题，是否完全能化解人们心中的疑问可能还有待时间及实践来证明。借助人们很关注的问题，今天也来了解了解相关的内存分配使用回收问题。内存的使用及防止泄漏是c/c++程序员非常关心的问题，一旦有泄漏发生往往都感觉到非常头痛，所以我们也很有必要关心这方面的问题，看看Firefox这些Hacker们究竟是如何来面对这些问题的。

一、内存管理的主要方式
为了尽可能合理高效的使用内存，不同的系统使用了一些各具特色的内存管理机制，1、以java为代表的garbagecollector，所有的资源经由虚拟机来分配、回收，大大降低了java程序员对内存管理的困扰，但也带来了程序速度启动变慢，占用内存较多的问题，特别在程序使用了多种资源后，当然这种机制还在脚本语言如javascript、python、perl等的实现中也得到充分的使用，并且通过一些优化算法，已经达到了很好的效果；2、以linux内核为代表Slab allocation机制，它通过一些缓存及固定长度分配器来有效解决由于多次及不固定长度内存分配可能带来的内存碎片问题；3、以apache为代表的内存池机制，它往往会先malloc一大块内存，以供后续程序内存申请使用，特别在内存分配申请频繁的情况下大大降低程序对系统层的内存申请次数，同时可以起到类似部分garbagecollector的作用。

二、主要Gecko内存管理机制
1、组件的生命周期可简单归纳为首先在factory的createInstance中通过new出一个类实例，然后通过queryInterface进行接口转换及维护mRefCnt，并检查mRefCnt是否为0，如是则delete该实例，主要实现原理可参考XPCOM组件相关开发资料，对应源代码可参考\mozilla\xpcom\glue\nsISupportsImpl.h及\mozilla\xpcom\glue\nsISupportsUtils.h等。当然也有部分类override operator new方法，但往往都是作清零的处理，根本没涉及到更深层的内存管理，而new/delete动作往往分别直接对应系统层的malloc/free方法，所以几乎没有上面提到的垃圾回收、Slab及内存池的使用，当然对javascript的实现是肯定会有相关垃圾回收机制的，但它的出发点往往为了满足脚本语言的要求。

2、对于一些字符串及数组的内存使用往往采用NS_Alloc/NS_Free等，其实现代码对应于XPCom的FrozenFunctions中指定的AllocFunc/FreeFunc，其由\mozilla\nsprpub\pr\src\malloc\Prmem.c中对应的PR_Malloc及PR_Free来实现，其中根据是否使用use_zone_allocator来检查直接调用系统malloc及free还是采取一定类似内存池及slab allocation的方法来统一管理内存的分配。其具体实现代码可详见\mozilla\nsprpub\pr\src\malloc\Prmem.c及Prmalloc.c等。对于NS_Alloc/NS_Free的使用，往往用在一些atoms、tags等当中，总的说来使用不是很多。。

3、为了防止组件之间的循环引用，引入了nsICycleCollector来单独处理这个问题，以尽可能的避免无法释放由于程序逻辑造成的内存冗余，具体实现可参考\mozilla\xpcom\base\nsCycleCollector.cpp；同时为了让程序占系统内存达到一定比例后，采用momory reporter机制要求系统flush/swap一些内存，供程序继续使用；另外结合nsGarbageCollector及nsLeakDetector来扫描stack检测是否存在内存泄漏。

4、网上关于gecko的内存使用的讨论非常多，现提供一些相关资料以供大家参考，从多方面了解gecko内存管理等方面的问题，从自己的角度来了解它，以拓展我们的思路。

浅谈Gecko关键部分之一XPCOM组件

2008-06-13T20:26:00.000+08:00

为了便于统一认识下面将Gecko统称为Firefox内核引擎而不仅仅代表渲染引擎，为了能更加有效的加深对它的理解，能够从本质上了解它的构成，下面从个人认为最为关键的几个部分来分析了解它，争取通过对这几个关键部分的了解总结能让自己从六百万行Gecko代码中逃脱出来，进而产生一点点一览纵山小的感觉，以致对Gecko的认识有本质上的提升。现首先从XPCOM组件开始，因为它是Gecko的基础，就像COM对于windows，没有从根本上对XPCOM的理解与把握就不可能对Gecko有深入的理解，同时对XPCOM的理解也只是对Gecko理解的入门。

一、究竟什么是XPCOM？
XPCOM is a cross platform component object model. It has multiple language bindings, letting the XPCOM components be used and implemented in JavaScript, Java, and Python in addition to C++.它是一个组件对象模型，与Windows中的COM非常类似，如果以前深入接触过COM的朋友，应该对XPCOM的认识会很轻松，个人认为它相对COM来讲可能相对简单点，毕竟它不涉及到线程管理、内存管理，从大体来讲它仅仅包括最基本的对象生命周期管理模型，当中涉及到类工厂、Sington等模式的应用。可能由于XPCOM刚开始在90年代初设计的时候，对组件对象模型的认识还比较浅显，所以它采用了最基本的引用计数形式来管理组件对象，没有更深层次的与内存管理、线程管理结合起来，可能正是由于这个原因在Gecko的代码中经常看到相关的注释提醒作者注意这个变量是referenced，而不会真正的参与到真实对象的生命周期管理，以防止对象间循环引用，从而给可能的内存泄漏埋下了祸根。

二、为什么需要XPCOM？
也许这样问有人或许觉得很白痴。不过个人觉得如能真正理解为什么需要XPCOM，那么针对形式各异的XPCOM组件运用也就会见怪不怪啦。需要XPCOM这个模型个人认为应该是基于接口编程的真实需要，基于接口编程能够有效的实现对业务对象基于平台、基于语言及实现形式的扩展。Gecko作为一个跨平台的内核引擎，倘若没有这种基于接口的模型会使系统变得更加的庞杂，也许为了更加简单及统一Gecko已将XPCOM这一对象模型发挥引用得淋漓尽致，基本上能抽象独立出来的逻辑业务如Timer、Thread、EventQueue、http等等都通通定义成含有相对固定接口的对象模型。其实作为一个大型复杂系统，个人认为这样做是很有必要的。

现举两三例来说明，试想不同的平台如windows、linux等都有不同的图形界面接口，其中有的是原生的如xlib、windows原生接口，也有抽象层的如gtk、qt、wxwidget、mfc等，作为一个可以支持多种图形界面接口的内核，首先在结合自身需要及原生图形界面接口的基础之上抽象出诸如nsIBaseWindow、nsIWidget、nsIMenu、nsIEventSink等等公共的接口，然后针对不同平台的具体实现分布在mozilla\widget\src\不同的qt、windows、gtk2、mac目录中，这样直接明了统一。同时值得留意的是mozilla\widget\src\build\目录下有一个nsWinWidgetFactory.cpp，其主要职责在于根据编译选项选定的平台注册对应目录下实现的组件，以供其他组件调用。其主要内容为：
static const nsModuleComponentInfo components[] =
{
{ "nsWindow",
NS_WINDOW_CID,
"@mozilla.org/widgets/window/win;1",
nsWindowConstructor },
{ "Child nsWindow",
NS_CHILD_CID,
"@mozilla.org/widgets/child_window/win;1",
ChildWindowConstructor },
{ "Clipboard",
NS_CLIPBOARD_CID,
// "@mozilla.org/widget/clipboard/win;1",
"@mozilla.org/widget/clipboard;1",
nsClipboardConstructor },
{ "Clipboard Helper",
NS_CLIPBOARDHELPER_CID,
"@mozilla.org/widget/clipboardhelper;1",
nsClipboardHelperConstructor },
{ "AppShell",
NS_APPSHELL_CID,
"@mozilla.org/widget/appshell/win;1",
nsAppShellConstructor },
{ "Toolkit",
NS_TOOLKIT_CID,
"@mozilla.org/widget/toolkit/win;1",
nsToolkitConstructor },
{ "Look And Feel",
NS_LOOKANDFEEL_CID,
"@mozilla.org/widget/lookandfeel;1",
nsLookAndFeelConstructor },
{ "Transferable",
NS_TRANSFERABLE_CID,
// "@mozilla.org/widget/transferable/win;1",
"@mozilla.org/widget/transferable;1",
nsTransferableConstructor },
{ "HTML Format Converter",
NS_HTMLFORMATCONVERTER_CID,
"@mozilla.org/widget/htmlformatconverter;1",
nsHTMLFormatConverterConstructor },
};

NS_IMPL_NSGETMODULE(nsWidgetModule, components)

其实Gecko的实现代码中与此类似的有很多很多，如我们大家了解的MIMI类型有很多如html、xml、svg、txt、jpeg、gif、png等等，首先抽象出nsIDocument，然后依据其类型的不同分别实现其对应的逻辑，具体可参考\mozilla\content\base\public\nsIDocument.h；\mozilla\content\html\document\src\nsHTMLDocument.cpp，nsImageDocument.cpp；\mozilla\content\xul\document\src\nsXULDocument.cpp等；再如我们了解浏览器实现的协议有http、ftp等，为了统一不同协议的实现框架及能扩展到不同的协议，首先抽象出一组接口如nsIURL、nsIStreamListener、nsIStreamLoader、nsIChannel、nsIRequest、nsIRequesetObserver等，然后在不同的目录如http、ftp、file中按公共接口框架实现其逻辑，Gecko利用这种协议接口框架还扩展了about、data、resource等协议模式，如果了解了其公共接口框架并初步了解其中一个协议的实现方式，我们就可很方便的扩充到未实现的协议或自定义的协议实现。Gecko利用XPCOM模型为我们提供了很多很多类似的公共接口框架，以便扩展，其实总的说来，对于Gecko来讲这种方式几乎无处不在，正是这样的架构设计创造了Gecko的强大、丰富而具有生命力。有兴趣的朋友可以按这个基本思路从其代码实现中找到诸如扩展一个html标签、一个css属性、一种文件格式等等实现范例，以掌控其设计精髓以致扩展它为我们所用。

三、XPCOM主要特性
在XPCOM提供了丰富的功能的基础上，个人认为其主要特性有1、需要深入了解其引用计数对象管理机制及内存管理，特别在与跨语言方面如javascript、python等的实现与交互时，须防止跨边界的内存泄漏；2、很多组件通过xpconnect已实现与javascript的交互<其实这是Gecko非常重要的一部分，以后有机会再专题分析>，大大丰富了用c/c++实现的组件的应用场景，当然XPCOM组件也提供了与python、java方面的扩充与交互，不过支持程度没有javascript强，因为毕竟XPCOM组件与javascript的交互是Gecko的基石；3、为了充分利用组件对象模型，Gecko的实现中使用了大量的Sington、Observer、adapter等设计模式，如在nsDocShell中关于nsIWebProgress、AddProgressListener、nsIInterfaceRequestor等相关实现中得到充分的体现。其中Sington模式的使用有时往往具有鲜明的特点。其一般实现为XXXService，如WindowWatcher、CommandLineHandle、UriLoader等等。
///*****************************************************************************
// nsDocShell::nsIInterfaceRequestor
//*****************************************************************************
NS_IMETHODIMP nsDocShell::GetInterface(const nsIID & aIID, void **aSink)
{
NS_PRECONDITION(aSink, "null out param");

*aSink = nsnull;

if (aIID.Equals(NS_GET_IID(nsIURIContentListener))) {
*aSink = mContentListener;
}
else if (aIID.Equals(NS_GET_IID(nsIScriptGlobalObject)) &&
NS_SUCCEEDED(EnsureScriptEnvironment())) {
*aSink = mScriptGlobal;
}
else if ((aIID.Equals(NS_GET_IID(nsIDOMWindowInternal)) ||
aIID.Equals(NS_GET_IID(nsPIDOMWindow)) ||
aIID.Equals(NS_GET_IID(nsIDOMWindow))) &&
NS_SUCCEEDED(EnsureScriptEnvironment())) {
return mScriptGlobal->QueryInterface(aIID, aSink);
}
else if (aIID.Equals(NS_GET_IID(nsIDOMDocument)) &&
NS_SUCCEEDED(EnsureContentViewer())) {
mContentViewer->GetDOMDocument((nsIDOMDocument **) aSink);
return *aSink ? NS_OK : NS_NOINTERFACE;
}
else if (aIID.Equals(NS_GET_IID(nsIPrompt)) &&
NS_SUCCEEDED(EnsureScriptEnvironment())) {
nsresult rv;
nsCOMPtr wwatch =
do_GetService(NS_WINDOWWATCHER_CONTRACTID, &rv);
NS_ENSURE_SUCCESS(rv, rv);

nsCOMPtr window(do_QueryInterface(mScriptGlobal));

// Get the an auth prompter for our window so that the parenting
// of the dialogs works as it should when using tabs.

nsIPrompt *prompt;
rv = wwatch->GetNewPrompter(window, &prompt);
NS_ENSURE_SUCCESS(rv, rv);

*aSink = prompt;
return NS_OK;
}
else if (aIID.Equals(NS_GET_IID(nsIAuthPrompt))) {
return NS_SUCCEEDED(
GetAuthPrompt(PROMPT_NORMAL, (nsIAuthPrompt **) aSink)) ?
NS_OK : NS_NOINTERFACE;

}
else if (aIID.Equals(NS_GET_IID(nsISHistory))) {
nsCOMPtr shistory;
nsresult
rv =
GetSessionHistory(getter_AddRefs(shistory));
if (NS_SUCCEEDED(rv) && shistory) {
*aSink = shistory;
NS_ADDREF((nsISupports *) * aSink);
return NS_OK;
}
return NS_NOINTERFACE;
}
else if (aIID.Equals(NS_GET_IID(nsIWebBrowserFind))) {
nsresult rv = EnsureFind();
if (NS_FAILED(rv)) return rv;

*aSink = mFind;
NS_ADDREF((nsISupports*)*aSink);
return NS_OK;
}
else if (aIID.Equals(NS_GET_IID(nsIEditingSession)) && NS_SUCCEEDED(EnsureEditorData())) {
nsCOMPtr editingSession;
mEditorData->GetEditingSession(getter_AddRefs(editingSession));
if (editingSession)
{
*aSink = editingSession;
NS_ADDREF((nsISupports *)*aSink);
return NS_OK;
}

return NS_NOINTERFACE;
}
else if (aIID.Equals(NS_GET_IID(nsIClipboardDragDropHookList))
&& NS_SUCCEEDED(EnsureTransferableHookData())) {
*aSink = mTransferableHookData;
NS_ADDREF((nsISupports *)*aSink);
return NS_OK;
}
else if (aIID.Equals(NS_GET_IID(nsISelectionDisplay))) {
nsCOMPtr shell;
nsresult rv = GetPresShell(getter_AddRefs(shell));
if (NS_SUCCEEDED(rv) && shell)
return shell->QueryInterface(aIID,aSink);
}
else if (aIID.Equals(NS_GET_IID(nsIDocShellTreeOwner))) {
nsCOMPtr treeOwner;
nsresult rv = GetTreeOwner(getter_AddRefs(treeOwner));
if (NS_SUCCEEDED(rv) && treeOwner)
return treeOwner->QueryInterface(aIID, aSink);
}
else {
return nsDocLoader::GetInterface(aIID, aSink);
}

NS_IF_ADDREF(((nsISupports *) * aSink));
return *aSink ? NS_OK : NS_NOINTERFACE;
}

四、XPCOM相关参考资源

认识了解Mozilla,Gecko,FireFox

2008-06-07T20:21:00.000+08:00

最近关于浏览器的新闻很多如Firefox3RC2已经发布了，过不了多久许多Fans翘首以盼很久的Firefox3正式版本也就粉墨登场啦；IE8、Safari、Opera都正热火朝天的发Beta版，似乎真有浏览器大战的架式；这不国内的Maxthon也想更换或调整其浏览器内核，看样子浏览器开发可正引领目前IT技术发展的一个潮流，再加上所谓AIR平台的发展，简直赚足了人们的眼球，大有当年Java刚出现时所展现的风光及所向披靡。

哪其中究竟有什么值得我们这些具有贫瘠IT技术引领创新能力的阿斗所特别需要关注的呢？
首先作为一个IT技术应用成员，觉得大家应该好好重视这个现象包括浏览器开发、web2.0、手机开发等，因为它或许会决定你我今后5年或10年的IT技术及应用发展方向，直接决定我们的生存方式及能否生存。其中原因应该在于Web的发展日益与人们的生活分不开，它需要更新，需要发展<可以自己从最基本的想想看>。

其次这次所谓的浏览器大战的始作俑者应该是Mozilla，这个基金会与浏览器的出现及Web的发展有作千丝万缕的关系(大家有兴趣可以搜索一下浏览器的发展就知道啦)，并且Mozilla开发所涉及的方面也是最为全面的如浏览器、AIR、手机等方面，而Mozilla的重中之重应该就是Gecko内核，所以我们很有必要深入了解认识一下它们Mozilla、Gecko及Firefox，包括它们的过去、现在及将来。

下面初步的认识了解一下它们
一、Mozilla严格说应该是一个开源基金会，不是一家公司，它应该具备世界上开源组织所特有一些特性如非盈利为目的、开源，有一群狂热的IT牛人在捣鼓着，不过目前它应该得到谷歌的大力支持，也许谷歌自己不单独开发浏览器也就是因为Mozilla。有空可去其官方网站
http://www.mozilla.org/foundation/瞧瞧。。。

二、Gecko应该说是 a layout engine originally created by Netscape Communications Corporation for the Mozilla application suite and now used in all applications developed by Mozilla, including later Netscape Navigator releases.它包含浏览器及AIR平台的核心，其主要实现支持标准有

HTML 4.0
CSS Level 1 (partial support for CSS 2 and 3)
JavaScript 1.7
DOM Level 1 and 2 (partial support for DOM 3)
XML 1.0
XHTML 1.1
XSLT and XPath
MathML
XForms (via an official extension)
RDF
partially supports SVG 1.1

应该说要了解Firefox必须了解Gecko，目前版本为1.9a，是除IE内核Trident之外第二大浏览器内核，同时它具有独到的特点：跨平台，支持windows、类unix、Mac；对XUL的充分实现与支持，仅这一点就超越了以往界面实现方式，并且经过多年的测试及提升应该有了很好的执行效率，其实这也是AIR所创导的核心;当然它也支持SVG、RDF、XBL；还有更重要的是它是定义及实现javascript的鼻祖，并正引领着javascript虚拟机化(大家想想看java的虚拟机的威力)，一旦整合了jvm实现技术中的优缺点，其威力可真不少，再说jvm已经发展10多年啦，相关技术已稳定成熟，那些IT大牛们完全可以采取拿来主义，很有可能比jvm实现得还要好，这样的话也许以后一般的电脑完全真的只需要一个浏览器就可以搞定一切啦。Gecko中的两大主题content/layout/render、javascript发展的好坏直接决定其能否在浏览器大战中胜出，当然其他的浏览器或平台要想在浏览器大战中突出重围必须在这两者之间杀出一条血路，目前综合说来Gecko占有一定先发优势，同时是其他竞争者模仿、想超越的对象，所以对于我们来讲具有很大的参考学习作用，同时毕竟是开源的嘛。

三、Firefox 应该说仅仅是一个浏览器而已，它能够象IE一样满足大家上网冲浪的切实需求，同时它或许更安全更小巧；但由于它完全基于Gecko内核便于扩充，这不http://addons.mozilla.org/?application=firefox上就有各种各样好玩的东东等着大家去捣捣，也许会让你发出原来自己的浏览器竟然可以变成这样的感叹，这不Web应用开发两大巨头谷歌、雅虎公司已经在其中开发了不少应用，很值得看一看借鉴借鉴。或许正是这么多因素导致Firefox正引领着浏览器的使用及发展，毕竟使用浏览器上网的人非常非常多，具有个性化的上网活动也许正在形成，应该说Firefox正深深的紧密的参与其中。

其实国内听说了解Firefox也许不少，但经常使用Firefox的人相对来说还是蛮少的，真正了解Mozilla及Gecko的人也许就更少啦，但个人觉得Firefox、Gecko这两年发展可真快了，或许它就是未来的发展方向，抛点砖希望大家有空一起了解关注甚至研究研究Firefox/Gecko。

参考网址

新的启航，简单快乐的活着！

2008-06-01T21:57:00.000+08:00

今天第一次开始写点东西，希望能给平平庸庸的生活添点色彩、动力、希望。

今天同时也是儿童节，祝一些过成年人儿童节的朋友们节日快乐开心。虽然童年时代已经较远，蓦然回首，是否觉得岁月无情，蹉跎岁月犹如滚滚长江东去水；是否觉得我们的天空与童年时代的有太多的不同；是否觉得我们已不再年轻，不再有理想，不再简单而快乐着；是的，我们长大了，生活环境变了，欲望多了，压力大了，苦恼多了，变得不再那么的简单。

过去的就让它过去好啦，我们目前的生活还要继续，但愿能多点童心去发现认识这个世界，多带来一点点快乐，有空可与小朋友一起玩玩，想他所想，按他们喜欢的方式去生活，这不从电视上看到四川灾区的小朋友与外国大朋友一起玩耍是多么的开心与快乐？！也许世界本来就很简单，我们得坚强简单开心的活着。。。

作为技术从业人员，每天与似乎冷酷无情的什么语言、工具、Bug打交道，再好的童心也给泯灭啦！这不恕我建议大家把我们学习的语言、工具权且当作我们小时候玩的玩具好啦，找自己喜欢的，有时间就与小朋友一起去切磋，玩的不开心了，换个玩具，换些朋友一起玩；如果有捣鼓拆玩具的冲动，可别忘了带着小时的童心去捣鼓，过不多久，说不定您就变成了胜利大王，天下无敌呢。。。

好了，但愿大家面对枯燥的生活，多去捣鼓捣鼓，简单快乐至上。不过有点需要提醒自己的就是童年时代爱好学习或玩的习惯可千万不要丢了(这不有科学家研究发现3岁前我们的思维方式性格等就已基本成型，会无形中影响我们一生呢？何不充分调动起小时就养成的方法方式来面对现在的一切呢？！)，长大了我们必须到社会上去学习去玩，学的越快玩的越开还是一样的很值得骄傲开心哦！如果还能保持点童心，那可就锦上添花啦，说不定您就能变成故事小说中的老顽童呢。

让我们一起简单快乐的活着，人生苦短，从童年到成年，您感受到了吗？！