【专业技术】Chromium浏览器的Content模块设计意图

Content 模块概述

“content”模块放在src \content里面，并使用多进程浏览器沙盒模块来呈现页面所需的核心代码。它包括所有的网络平台功能（如HTML5）和GPU加速。它不包括Chrome浏览器的功能，即扩展/自动填充/拼写等。它的目标是，任何嵌入者或者说使用者应该能够用它来开始建立一个浏览器，然后从中挑选Chrome功能。

动机是什么？

由于Chrome代码的不断壮大，功能不可避免地有时候会放在错误的地方，从而导致分层规则的不规范，以及不应该存在的依赖关系。它已经很难为开发者找出最好的方法，因为这些API和功能都在同一个目录下。为了避免这种情况发生，并增加核心部分的代码，Chrome采用多进程浏览器并对呈现页面的工作明确分工，把核心浏览器代码转移到src\content里面。

content 还是Chrome？

content应该只是呈现页面所需的核心代码。 Chrome功能由content提供的API来过滤IPC，以及得到事件通知。

举一个例子好了，下面是一个Chrome功能列表部分。它们并不在content里面，这意味着content的代码不应该知道他们，content只需要提供通用的API，Chrome的那些功能可以基于这些API来编写：

• Extensions
• NaCl
• ChromeFrame
• SpellCheck
• Autofill
• Sync
• Prerendering
• Safe Browsing
• Translate

体系结构图

上图显示了不同模块的层次结构。一个模块可以直接包括较低的模块代码。模块可以不包括一个比它更高模块的代码。这是通过DEPS规则强制执行实现的。模块可以实现嵌入者比如Chrome的API，使低于自己的模块可以调自己。这些API的实例是WebKit的API和content的API。

Content API

Content API 告诉我们如何基于content来间接调用浏览器。如果可能的话，Chrome功能尝试通过IPC过滤，监听事件来设置钩子。如果没有足够的上下文（比如WebKit的回调），或在回调是一次性的情况下，chromium有一个ContentClient接口，嵌入者（Chrome浏览器）实现好了的。 ContentClient在所有进程里都是可用的，一些进程也有自己的回调API，比如 ContentBrowserClient / ContentRendererClient / ContentPluginClient等等。

部分参考：http://www.chromium.org/developers/content-module