主题：【原创】Chrome程序初探（序） -- 素里太守
用IDL的地方还是挺多的，不一定都是CORBA。
CORBA这个东西就不说了~~~
[1] Web Browser
Google最新推出的产品Chrome是一个互联网浏览器（Web Browser）。目前市场上流行的浏览器，主要是微软的Internet Explorer（IE），Mozilla的Firefox，挪威人的Opera，还有Apple的Safari。
各家浏览器的市场份额，说法不一。截止2008年8月份，有的机构的统计数字说，IE的市场份额是78.30%，Firefox占16.36%， Safari占3.41%，Opera占0.81%。但是另外的机构说IE目前市场份额只有58.46%，而Firefox占31.40%。
但是大家公认的事实是，IE目前仍然是浏览器市场的龙头老大，占绝对优势，虽然最近几年有下降趋势。Firefox上升势头明显，Safari也在吸引更多用户。
Google的Chrome，会不会颠覆目前浏览器市场的格局，大家拭目以待。
[2] Web Browser的组成部分
Web Browser的工作，从概念上讲，分这么几件任务。
1. 用户输入一个网址（URL），Browser根据这个URL，与相应的网站（Web Site）建立HTTP或者HTTPS联系。
2. Browser下载相应网页（Web Page）。网页的数据大体上包括这么几个部分，a. HTML格式的内容，b. JavaScript的操作代码，c. 插件（Plugin）内容，譬如视频等等。
3. Browser把HTML格式的内容绘制出来，包括，a. HTML的布局，譬如左边是什么，顶部是什么，中间是什么。b. 根据用户设定，呈现文字，譬如字体是宋体还是楷书，大小尺寸，重体斜体等等。c. 显示不同格式的图片，譬如JPG，GIF，PNG等等。
4. Browser相应用户操作，尤其是处理由JavaScript程序控制的动作。譬如用户在浏览器界面上移动鼠标，有些图标会放大或缩小，颜色会变化等等。
5. 支持插件。插件是浏览器本身不自带的程序，譬如PDF文件阅读器，视频显示器等等。
第一步和第二步的工作咋一看来并不难，但是想提高速度，却并不是那么简单。通常的办法是多线程并发处理。Google Chrome比其它浏览器明显更快，据说是用了Edge push的技术。这个技术的细节，有待我们打开Chrome的源代码，仔细研究。
第三步和第四步的工作，由布局引擎（Layout engine）来完成。Layout engine又被称为绘制引擎（Rendering engine）。开发Layout engine的工作量大，难度也高，所以有时候软件工程师把Layout engine和浏览器混为一谈，这样的说法固然不准确，但是也从侧面说明了Layout engine在整个Web Browser系统中的地位。
[3] Layout engine
微软的IE，背后的Layout engine名曰三叉戟（Trident）。Firefox身后的Layout engine，叫Gecko。而Apple的Safari，以及Google的Chrome，用的Layout engine都是WebKit。
虽然IE占据的大部分市场份额，但是似乎谈论Trident的文章不是很多。Gecko的特点是小，有点像OS的微内核一样，扩展性很好。
最近几年，谈论WebKit的文章很多，估计与以下几个因素有关。
1. WebKit的前身是由开源的Linux项目组KDE设计开发的KHTML，后来Apple觉得这个产品不仅开源，而且架构设计简洁高效，所以就参与开发。再后来，在产品未来开发计划上，Apple与KDE产生分歧，于是各干各的，Apple把产品名字改为WebKit。
2. 基于WebKit，Apple公司于2003年推出MacOS平台的浏览器，Safari。
3. 2005年，WebKit源代码向公众开放。
4. 同年，Nokia推出S60平台的手机浏览器，其内部Layout engine，也是WebKit。
5. 同年，KDE宣布放弃KHTML，改用WebKit。
6. 2007年，Apple推出手机iPhone，引起轰动。iPhone自带的手机浏览器，也使用了WebKit。iPhone的浏览器，缩放自如，引人注目。
7. 2008年，Google推出浏览器Chrome，其内部Layout engine，也是WebKit。
[4] 嵌入式Layout engine
需要指出的是，作为一个Layout engine，WebKit的用途，并不限于浏览器，而是可以作为一个通用的UI界面平台。譬如，微软的电子邮件软件Outlook，虽然不是浏览器，但是其界面控制，是基于Layout engine。微软的Office软件，也是基于Layout engine。作为微软产品系列的子产品，它们无一例外地用了微软的Layout engine，Trident。
联想到我们目前开发手机软件，大多数直接调用手机OS的API，来绘制UI界面。每次手机软件有新版本推出，哪怕仅仅是把一个button，从手机屏幕的左边，挪到右边，都要修改软件源代码。修改完源代码后，都必须送运行商重新审定，测试。运行商审批通过后，还要让手机用户下载，重装。不仅周期长，而且给软件开发商，移动运行商，手机用户，三家都带来很大麻烦。
试想一想，如果我们在每个手机预装了Layout engine，今后每当手机应用软件开发商更新手机应用软件，不需要移动运行商审批检测，不需要手机用户下载重装。只需要向手机用户推送类似于HTML+JavaScript的内容数据即可。
换句话说，把内容本身与绘制内容的Layout engine分离，将极大降低手机应用软件的开发难度，极大缩短它们的更新周期。到那时，手机应用说不定就会极大繁荣。
当然也存在缺陷。如果手机应用软件开发商，更新其产品时，不需要预先送交移动运行商审批。站在运行商立场，如何保证应用开发商的新产品，从内容到质量符合运行商要求？如何保障运行商的利益不受侵蚀？
我的意思就是使用工具生成不同环境的特定信息文件，包括编译器相关的native的东西都可以处理。 这个东西其实在c++里面也有，我看过一些开源的小玩意就有。
只要规划好就ok了， dsw，sln什么的都可以生成么，反正都是文本文件。这样做确实方便了不同开发环境的用户，尤其是初学者，否则很多人可能拿到源代码根本无所适从。
在java应用里面也经常有类似的要求，针对不同平台编译发布不同版本。特别是开发手机类应用的时候，不同型号的手机差异相当，这时候就需要从分利用工具来做条件编译打包。有时候不同的开发人员有不同的开发环境需求，我们从版本工具拉下源代码以后，也是使用特定的脚本工具生成对应的IDE相关配置文件，开发人员直接导入自己ide就可以run了，而手工进行设置，不当费时间，还很有可能出错。
这些都是简单的重复体力劳动，为啥不让程序去做，要人去做？
找了一个弟兄，亦步亦趋地验证了太守的Building，可行。
1. Chrome源代码包的下载地址：
http://build.chromium.org/buildbot/archives/chromium.tgz
2. 解压， 然后机器上至少要有10G左右的空间，代码编译之后的大小大概在5-6G,另外需要C盘大概2-3G的空间安装windows 2008 SDK;(可以将SDK安装到其他目录)。
3. 开发工具：vs2005, 但是需要安装windows 2008 SDK,
http://www.microsoft.com/downloads/details.aspx?FamilyID=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
下载来的是一个setup.exe的网络安装包，如果安装成功，到开始->程序->Microsoft windows SDK v6.1 ->Visual studio registration->configuration tool 。运行这个程序，注册一下。
4. 编译：
用vs依次打开并build chrome\src目录下的BASE, NET, SANDBOX, WIBKIT, CHROME中同名的SOLUTION文件。（我选择的是编译release版本） 。基本上这样就不会有任何问题。
BASE,NET,SANDBOX 这三个工程编译的时间比较短一点，大概每个半个小时以内。
WIBKIT大概2个小时，CHROME大概2个半小时。
检查src\chrome\release目录，可以得到一个mini_installer.exe的安装文件。(chrome.exe,chrome.dll也有，不过是不能脱离release目录运行的依赖文件)。
That is all.
有没有好事者将Gecko集成到Chrome架构中，使Chrome具有双渲染引擎；更有甚者，集成IE 7的MSHTML.DLL到Chrome中。
就见ie tab
用了一下，和其他同时用的browser同一引擎的时候，非常容易崩溃。太守有兴趣给讲讲。
1.只支持两个引擎：Trident和Gecko。没有WebKit的事情。
2.初步印象与“傲游”的技术路线非常的类似，基本上是给IE包了个壳。证据：两个程序的进程中都观察到了ShDocVw.DLL和BrowseUI.dll。
发行速度挺快的，看样子10个月内正式版1.0有希望推出。
Chrome正式版不日即将推出，版本号1.0.154.36，实际上是0.4.154.33.
Note to Dev channel users: The Dev channel release will stay at 0.4.154.33. The current stable release is the same as the current Dev channel release without the Hotmail fix (which hasn't been tested enough to release to all users). An update is coming next week.