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来编写:
体系结构图
上图显示了不同模块的层次结构。一个模块可以直接包括较低的模块代码。模块可以不包括一个比它更高模块的代码。这是通过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