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

本文属原创，转载请注明出处，违者必究

关注chromium群480089700，或者微信公众平台:程序员互动联盟(coder_online)，你可以第一时间获取原创技术文章，和（java/C/C++/Android/Windows/Linux）技术大牛做朋友，在线交流编程经验，获取编程基础知识，解决编程问题。程序员互动联盟，开发人员自己的家。