一、浏览器主要构成
浏览器的主要构成High Level Structure
浏览器的主要组件包括：
1) 用户界面－包括地址栏、后退/前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分
2) 浏览器引擎－用来查询及操作渲染引擎的接口
3) 渲染引擎－用来显示请求的内容，例如，如果请求内容为html，它负责解析html及css，并将解析后的结果显示出来
4) 网络－用来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上工作
5) UI 后端－用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口
6) JS解释器－用来解释执行JS代码
7) 数据存储－属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术
关于浏览器设计，有一个简洁的概念模型:
二、Webkit介绍
WebKit 是一个开源的浏览器引擎，与之相对应的引擎有Gecko（Mozilla Firefox 等使用）和Trident（也称MSHTML，IE 使用）。
绿色部分构成了WebKit的主要部分，形成自己的结构:
WebKit 主要包括三部分： WebKit ， WebCore ，以及 JavaScriptCore ，加上所使用的库，依托的平台，其基本的体系结构 (Architecture) 如下所示：
注意有的模块相对于下面的模块有突出，这是因为此模块与下面几个模块直接相关，比如 WebCore 模块就与JavaScriptCore 、 Libraries 和 Platforms 模块直接相关。
WebKit是一个渲染引擎，Chromium是一个浏览器，它们那么分别包含哪些不同的功能模块？
WebKit:
1. HTML解析:：负责HTML语言的解析
2. CSS解析：负责CSS的解析工作
3. 图片解码：支持不同编码格式的图片
4. JavaScript引擎：JavaScript语言的解析引擎，缺省的是JavaScriptCore，但是目前Google 的V8 JavaScript被广泛使用
5. 正则表达式
6. 布局：负责布局(layout)的计算和更新工作
7. 文档对象模型(DOM)：DOM是W3C定义的对象模型，该部分负责DOM树及其相应的接口
8. 渲染：与渲染相关的基础设施，例如渲染树，渲染层次树等等
9. SVG：对SVG的支持
10. XML解析：XML语言的解析
11. XSLT：XSLT语言的解析执行
12. URL解析器：URL规范的解析
13. Unicode编解码器：各种编码解码工作
14. 移植：WebKit中比较大的一部分，因为WebKit要工作需要不同平台上有具体的实现，因而不同的移植有不同的实现。chromium的移植很复杂，因为其支持跨平台，所以它的移植需要在windows，linux和mac上工作。
由上面的模块大致可以WebKit主要是跟网页的解析和渲染相关的工作，其不涉及浏览器的历史，书签，下载，cookie管理等等方面的工作。
更详细的webkit介绍：
http://www.infoq.com/cn/articles/webkit-for-developers
三、Chromium介绍
Chromium是一个建立在WebKit之上的浏览器开源项目，由Google发起的。该项目被创建以来发展迅速，很多先进的技术被采用，如跨进程模型，沙箱模型等等。同时，很多新的规范被支持，例如WebGL，Canvas2D，CSS3以及其他很多的HTML5特性，基本上每天你都可以看到它的变化，它的版本升级很快。在性能方面，其也备受称赞，包括快速启动，网页加载迅速等。
Chrome是Google公司的浏览器产品，它基于chromium开源项目，一般选择稳定的版本作为它的基础，它和chromium的不同点在于chromium是开源试验场，会尝试很多新的东西，当这些东西稳定之后，chrome才会集成进来，这也就是说chrome的版本会落后于chromium。另外一个就是，chrome里面会加入一些私有的codec，这些仅在chrome中才会出现。再次，chrome还会整合Google的很多服务， 最后chrome还会有自动更新的功能，这也是chromium所没有的。
Chromium功能:
1. Cookie管理器：cookie生命周期的管理
2. 历史管理器：历史记录的管理
3. 密码管理器：网页中密码登录信息管理
4. 窗口管理：多个Tab窗口的管理和切换
5. 地址栏：地址栏功能，智能地址填充与书签的协同工作
6. 安全浏览黑名单管理：安全浏览机制
7. 网络栈：与网络传输相关的工作，其有很多创新的东西
8. SSL/TLS：网络传输安全
9. 磁盘缓存：磁盘缓存页面及其替换策略等生命周期的管理
10. 下载管理器：管理下载相关
11. 粘帖板：clipboard的功能
12.书签管理：书签的组织和管理
13. URL解析器：同WebKit
14. Unicode编解码器：同WebKit
Chromium主要是实现浏览器相关的功能，如上面中的网络栈等等。其实以上只是一些浏览器基本功能，chromium实现的远不止这些，这其中包含沙箱模型，NaCl，扩展机制，硬件加速架构等等。这些我们将在之后的章节中逐一介绍它们。
URL解析器和Unicode编解码器在两者中都存在是因为它们都要使用到。
四、CEF3介绍
Chromium Embedded Framework 缩写为 CEF ，是个基于Google Chromium项目的开源Web browser控件，支持Windows, Linux, Max平台。除了提供C/C++接口外，也有其他语言的移植版。
因为基于Chromium，所以CEF支持Webkit & Chrome中实现的HTML5的特性，并且在性能上面，也比较接近Chrome。
CEF还提供的如下特性：自定义插件、自定义协议、自定义JavaScript对象和扩展；可控制的resource loading, navigation, context menus等等。
简单来说，就是方便为你的应用嵌入支持HTML的展示特性，比常规的引入IE控件的方式方便和稳定多了。
早在content API出现之前，CEF便已出现，其目的是提供嵌入式的框架，可以让渲染网页的功能方便地嵌入到应用程序之中。CEF依赖于chromium浏览器，所以chromium对HTML5的支持和性能上的优势，都得以继续在CEF中体现出来。但是，根据实际测试的结果来看，情况可能并非如此。首先，其对GPU硬件加速的支持不是很好，这时因为它会把GPU内存读回到CPU内存，速度非常慢；再次，因为基于chromium的内部结构，而它们经常变化，所以CEF经常需要发生变化，这对维护来说是件很头痛的事。
得益于content API的出现，CEF的作者也基于它开发了CEF3。CEF3在保持其提供的接口基本不变的情况下，借助content API的能力，其对HTML5和GPU硬件加速提供了较好的支持。它的核心变为调用content API的接口和实现content API的回调接口，来组织和包装成CEF3自己的接口以被其他开发者所使用。其好处是，CEF3的接口相对比较简单，使用起来方便，同时不需要实现很多content API的回调接口，但是缺点就是，如果需要使用content API的很多功能，CEF3的接口可能做不到，或者说只能通过直接调用content API接口来完成。
下面简单介绍一下CEF3的接口。
CefClient：回调管理类，包含5个接口用于创建其它的回调类的对象
CefLifeSpanHandler: 回调类，用于控制popup对话框的创建和关闭等操作
CefLoadHandler: 回调类，可以用来监听frame的加载开始，完成，错误等信息
CefRequestHandler: 回调类，用于监听资源加载，重定向等信息
CefDisplayHandler: 回调类，用于监听页面加载状态，地址变化，标题等得信息
CefGeolocationHandler: 回调类，用于CEF3向嵌入者申请geolocation的权限
CefApp: 与进程，命令行参数，代理，资源管理相关的回调类，用于让CEF3的调用者们定制自己的逻辑
CefBrowser: renderer进程中执行浏览相关的类，例如前进，后退等
CefBrowserHost: browser进程中的执行浏览相关的类，其会把请求发送给CefBrowser
CefFrame: 表示的是页面中的一个Frame，可以加载特定url，在该运行环境下执行JavaScript代码等得。
V8：CEF3提供支持V8extension的接口，但是这有两个限制，第一，v8 extension仅在Renderer进程使用；第二，仅在沙箱模型关闭时使用。
## Content API和WebKit2
Content API和WebKit2的接口都是基于跨进程的结构的，按我个人的理解，它们是互相影响而又互相吸收对方的优点，它们具有相同点，又有不同点：
1） Content API提供的是一套基于跨进程的架构模型（当然它也可以不是多进程的），这有利于browser（UI）进程的稳定，这同样对WebKit2适用；
2） Content API不仅如此，它里面包含chromium对于HTML5，GPU硬件加速，和沙箱模型等功能的支持，而WebKit2可能并非如此；
3） Content API是chromium提出的接口，而WebKit2是一个更加开放和公开的接口，被众多的WebKit移植所使用。
## 源文件目录
Content/public/app ,Content/public/browser, Content/public/render, Content/public/common,
Content/public/plugin, Content/public/utility
ContentAPI所包含的相关的目录，里面包含所有的
下面是混合应用案例：
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
