南昌游记

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篇

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篇

最近自从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年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