Chrome概念模型 - 2_wordpress 概念模型-CSDN博客

并发与线程（Concurrency and Threading)

Chrome的特征之一是它采用多进程架构。在实现这种架构时，面临一个最主要的障碍，就是创建一种进程间高效的通信方式。开发团队探索了几种现有的技术（像COM），最终决定使用命名管道。然而，在不同的系统上，管道很不一样，因此为了解决这个问题，他们开始创造一些东西，也就是众所周知的IPC（Inter-Process Communication）通道。

线程模型在实现层面是很复杂的。整体结构上，简单的来讲，有一个主进程处理用户交互，the browser, 操作系统调用和数据持久化。这个进程也就是“browser" 进程。browser 进程包括许多线程（如图4），每一个负责不同的任务，不过在这一层我们只需要关注I/O线程。I/O线程保持与所有已生成进程的联系，并处理与其它模块的所有通信（通过IPC）。

基本上，每当在浏览器中打开一个新的tab时，一个新的“渲染器”进程都会被创建。偶尔也有例外，比如，当一个URL以一种允许某些脚本操作它的方式打开时。另一种情况是，允许的进程数量已经达到上限，这种情况发生时，就会开始把一些tabs整合到一个进程中。

处于安全考虑，渲染进程被放入沙盒中运行，它包含有自己的渲染引擎实例，JavaScritp解释器， XML解析器和一些显示后端组件（即Skia和GDI）。

项目开发

Chrome的大部分子系统都被设计的比较独立，对外没有强依赖关系。两个相互交互的系统有一个约定的接口，它提供了较上一层所需要的服务，子系统的实现是不相干的。这是层次结构的主要优点，允许独立团队负责特定的子系统。例如，V8， Chrome的JavaScritp解释器就是由Google位于丹麦的团队开发的，它独立于浏览器本身。如果有合适的适配器，使V8能与上层通信，它就可以被插入到另一个浏览器中。

Google Chrome的网络栈同样可以由独立的团队处理。像V8，它只向在层次结构中位于它之上的一个组件提供服务，它本身是完全独立的，没有任何依赖关系。复杂该子系统的团队必须提供browser engine需要的核心功能，至于要不要提供一些额外的功能，以及如何实现就没有严格限制了。

也有相反的情况，Chromium项目使用了开源的XML解析器，libXML库，它不是自行开发的。Chromium没有重复发明轮子，而是把一个现有的，全功能的XML解析器插入到他们的层次结构中。

使用案例

获取一个不在cache中的基础网页（XHTML & CSS）

一个URL请求开始于用户在用户界面输入URL。URL请求被发送到browser, 随后browser检查看网页是否在缓存中。假定网页没有存储在缓存，browser紧接着会连接网络并获取URL数据。获取到的信息会被缓存起来以供将来使用。URL数据被送往WebKit渲染引擎，它对数据进行处理之后，分别把待渲染的文本和图形送到GDI和Skia。这些信息被绘制在一个关闭的屏幕“canvas"上。已绘制画布信息被返回到WebKit，然后WebKit把相应的位图返回给browser，随即呈现给用户。

拉伸一个浏览器窗口（Stretching a Browser Window）

缩放开始于用户使用他们的鼠标抓住窗口角落并进行拖放。缩放事件被发送到browser, browser检查用于存储由WebKit最近产生位图的后备存储。因为是扩展窗口事件，后备存储中的图的像素不够，所以需要一个扩展的网页视图。browser随后发送一个请求到WebKit, 以产生一个扩展的网页试图。WebKit把请求转发到GDI和Skia，由它们来渲染文本和图形。绘制好的画布被返回给WebKit，然后WebKit返回位图给browser，随即用扩展的网页视图填充新的窗口区域。

获取一个使用了JavaScript和JavsScript Cookie的网页

获取一个使用了JavaScript，而且包括一个JavaScript Cookie的网页的系列图与第一个请求系列图类似。URL请求开始于用户在输入界面输入URL。URL请求被发送到browser，browser检查网页是否在缓存。在该例子中，网页在缓存中，就没必要发送一个网络请求。网页数据被发送到WebKit, 如之前所述，GDI 和 Skia 分别渲染文本和图形。JavaScript被发送到V8进行解释；同时一个JavaScript Cookie请求被发出，并被传递到browser。browser处理Cookie请求并返回相应cookie（通常是一些用户参数）给WebKit，在传递到V8。接下来的步骤就和系列图5一样了。