Displaying A Web Page In Chrome

概念化的应用分层

参见原文档：http://goo.gl/MsEJX

每一个box代表一个抽象层。下层不依赖于上层。

• WebKit：渲染引擎。Safari，Chrome / Chromium均在使用。国内的则有百度浏览器，QQ浏览器，猎豹等。Port(即移植)是webkit的一部分，它负责整合与系统相关的服务，如资源下载，图像解码等。
• Glue：胶水层。负责把WebKit的数据类型转换为Chromium的数据类型（与android平台中的glue含义一致）。他属于webkit嵌入层。正是这一层的作用使得webkit可以嵌入到系统中。它也是Chromium和test_shell的基础。
• Renderer/Render host：Chromium的多进程部件。它处理通知及命令。
• WebContents：Content模块的主类，一个可以利用的组件。使用他就可以实现多进程渲染。更多细节请点击content module pages。
• Browser：代表浏览器窗口。它包含多个WebContent。
• Tab Helpers：一群独立对象。它们可以附着到一个WebContents上。

WebKit

我们使用开源的WebKit实现网页布局。这部分代码是从Apple拉取的，放在third_party/WebKit目录下（启用blink后不一样了亲。。。）。WebKit由两个引擎构成：WebCore和JavaScriptCore。WebCore负责网页布局；JavaScriptCore负责运行js代码。我们仅在测试的情况下才会运行JavascriptCore。正常情况，我们使用我们自己的V8引擎。它的性能比JavaScriptCore要好的多。我们没有使用WebKit这一层（Apple的称呼）。

WebKit Port (移植或适配层)

在底层，我们有自己的WebKit适配层（port）。与平台相关的功能接口均在这里面实现。这些代码位于WebKit目录下的chromium目录。其实，许多的移植是与os无关的。但像字体渲染是必须和平台绑定在一起的。

• 网络流量由多进程资源加载系统处理，而不是依赖于os。
• 图像使用为Android开发的Skia图形库。这是一个跨平台的图形库，处理所有的图像和图形。Skia代码位于/third_party/skia目录下。图形操作的入口位于/webkit/port/platform/graphics/GraphicsContextSkia.cpp中。

WebKit glue (胶水层)

Chromium应用使用不同于WebKit源代码的数据类型，代码风格，以及代码布局。WebKit glue提供一个更加方便的嵌入API。该API使用google代码类型，比如，我们使用std:string代替WebCore::String，使用GURL替换KURL。glue代码位于/webkit/glue目录下。glue的对象命名与WebKit的对象类似，但均以”Web”开头。比如，WebCore::Frame变成WebFrame。

WebKit glue层将Chromium代码与WebCore的数据类型分离，把WebCore对Chromium的影响降到最低。所以，WebCore中的数据类型绝对不会被Chromium直接使用。

“test shell”应用是一个“裸”的web浏览器，仅用于测试WebKit移植和glue代码。它使用glue接口与WebKit通信。Chromium也是这样做的。它向开发者提供一个更简便的测试新代码的方式，不需要关注众多复杂的浏览器feature，线程及进程。WebKit的自动化测试也是由这个应用跑的。但是，test shell的缺点就是它毕竟和Chromium不一样。content模块嵌入到一个叫“content shell”的应用中。

Render进程

Chromium的render进程通过glue接口嵌入WebKit port。它没有太多的代码：它的首要职责是作为连接browser的IPC channel另一端 - Renderer。

Renderer中最为重要的类是RenderView，位于/content/renderer/render_view_impl.cc。这个对象代表一个web页面（web page）。它处理所有的navigation相关的命令。这些命令可以来自Browser进程或者发向Browser进程。RenderView类继承自RenderWidget。RenderWidget提供绘制和输入事件的处理。RenderView与Browser进程间通过全局对象RenderProcess通信。

FAQ：RenderWidget和RenderView两者间有什么不同？

RenderWidget实现了glue层的抽象接口WebWidgetDelegate，以此映射到WebCore::Widget。这是屏幕上最基本的一个窗口。该窗口会接收输入事件并且绘制的结果也送到该窗口中。RenderView继承自RenderWidget。它是一个tab或一个弹出窗口的内容。它处理navigational性质的命令（导航命令？？）。RenderWidget仅在一种情况下可以独立于RenderView存在：web页面上的选择框。这些框通常带有向下的箭头。这个箭头用于弹出可选项。这个选择框性友用native窗口渲染。因为只有这样，选择框才能出现在其他元素的上面。这些窗口需要接收输入事件，但并没有一个分离的“web page”（即RenderView）来做这件事。

Renderer中的线程

每一个Renderer有两个线程。一个是render thread（即渲染线程）；另一个是主线程。像RenderView和WebKit代码均运行在这个线程里面。当Renderer需要与Browser通信时，消息先被发给主线程。主线程负责把消息转发给Browser进程。除了别的之外，这种机制也允许我们以同步方式向Browser发送消息。这种情况发生在一小部分操作时。这些操作通常需要等待浏览器的返回结果才可以继续。比如，通过js获取一个page的cookies。此时，Renderer线程就会阻塞。主线程把收到的所有消息入队直到收到正确的响应。这期间收到的任何消息均会被送到Renderer线程，走正常的处理流程。

Browser进程

低级对象（low-level browser process objects）

所有Renderer进程的IPC通信都是在Browser的I/O线程中完成的。这个线程也处理网络通信。该方案可以避免对用户交互的影响。

当主线程初始化完一个RenderProcessHost对象后，该对象会创建一个新的Renderer进程并分配一个ChannelProxy给Renderer（以命名管道方式）。该对象运行在浏览器的I/O线程里，监听该命名管道并自动把消息转发给RenderProcessHost对象（该对象在UI线程，即主线程里）。一个ResourceMessageFilter对象会被安装到Channel上，用于过虑特定的消息。这些特定的消息可以被I/O线程直接处理，如网络请求。这种过滤行为发生在ResourceMessageFilter::OnMessageReceived里。UI线程里的RenderProcessHost负责分发所有view相关的消息给相应的RenderViewHost。这种分发行为发生在RenderProcessHost::OnMessageReceived里。

高级浏览进程对象（High-level browser process objects）

View相关的消息来到RenderViewHost::OnMessageReceived中。这些消息有大部分在这里被处理掉。剩下的则被转发给RenderWidgetHost基类。这两个类分别映射到Renderer中的RenderView和RenderWidget。每一个平台均会有一个view class（RenderWidgetHostView[Aura|Gtk|Mac|Win]），实现到native view系统的整合。

WebContents对象位于RenderView/Widget之上。大多数消息在这个对象被方法调用消费掉。一个WebContents代表一个web page的内容。它是content模块的顶层对象。它负责在一个矩形视图（view）里显示一个web page。要查阅细节，请点击“Content Module Pages”。

WebContents对象被一个叫做TabContentsWrapper包含。该类位于chrome目录，代表一个tab（即标签页）。

两个说明性示例

Set Cursor（光标）消息的生命周期

暂无

鼠标点击消息的生命周期

暂无