Chromium项目之content_shell简介(windows)

一、content_shell介绍

content shell是一个基于content api的简单测试程序, 它仅仅是一个壳，调用了content API并实现了部分必需的回调接口，可以用来测试和其他一些简单的功能。

由于chromium项目无比巨大，大到基本上无从下手,想要直接去了解chromium是一件非常痛苦的事情，所以官方提供了cef以及content_shell，而且content_shell又远比cef要简单得多。

 

 

二、content_shell项目结构

1、content_shell/app/shell_main.cc

这是content_shell.exe的程序入口,主要做一些初始化工作,例如初始化沙箱,然后就进入了content_main.cc,执行ContentMainRunner的Create, Initialize, Run等方法.

2、content_shell_crash_service/tools/content_shell_crash_service.cc

这是用来监视程序crash的,几乎这个项目里面的每个进程都会有这一块,跟breakpad一起工作,捕获程序的异常生成dump,这个对我们现在研究的content api没多大关系,略过吧.

3、content_shel_lib

content_shell的主要实现都在content_shel_lib,介绍content_shel_lib之前先说下content api.

1)、content_shel_lib/app

主要做资源加载、命令行的解释以及创建进程(renderer、gpu等)与进程息息相关的功能。

2)、content_shel_lib/browser

content shell的大部分功能逻辑都在这里实现，其中包括资源、界面、网络、下载、html5支持，js解析等等，url请求等等。

3)、content_shel_lib/common

实现一些公共的接口，进程、公钥等相关，renderer以及browser会频繁的调用到这个模块。

4)、content_shel_lib/renderer

       主要实现一些回调函数给browser调用。

5)、content_shel_lib/utility

封装一些接口提供给browser调用。

 

三、简单介绍下content api

Content API不仅提供了公开和稳定的接口，而且它从诞生以来一个重要的目标就是要支持所有的HTML5功能和GPU硬件加速功能，这可以让它的使用者们不需要很多的工作即可以得到好的HTML5支持和硬件加速机制。同时，借助于现有的多进程架构，一些chromium中的新功能例如沙箱模型等也在其中得到了支持.

Content API的相关的接口定义文件均在content/public目录下，按照功能分成六个部分：每个部分的接口一般也可以分成两类，第一类是嵌入者（embedder，这里可以是Chrome浏览器，CEF3和content shell）调用的接口，另一类是嵌入者实现的回调接口，被content API的内部实现所调用，例如参与实现的逻辑，事件的监听等。

下面详细介绍一下Content API包含哪些部分:

1）  app

这部分主要是跟应用程序或者进程的创建和初始化相关。

第一类，主要包括创建进程的初始化函数，content的初始化和关闭；

第二类，主要是实现回调函数，告诉嵌入者启动完成，进程启动，进程推出，沙盒模型初始化开始和结束等等。

2）  browser

第一类包括，对一些HTML5功能和其他一些高级功能实现的参与，例如resource，sensor，notification，speech recognition， web worker，download， web intents，等等;

第二类包括ContentBrowserClient，主要是实现部分逻辑，被Browser端（或者进程）调用，还有就是一些事件的回调函数.

3）  common

主要定义一些公共的接口，被render和browser共享，例如一些进程相关，参数，gpu相关等等

4）  render

第一类包含获取RenderThread的消息循环，注册v8 extension，计算JavaScript表达式等等

第二类包括ContentRendererClient，主要是实现部分逻辑，被Browser端（或者进程）调用，还有就是一些事件的回调函数

5）  utility

工具类接口，主要包括让嵌入者参与content API中的线程创建和消息的过滤。

6)gpu

创建gpu进程进行gpu加速

7）child

       具体功能有待研究，content_shell没有直接调用到此模块的接口。

 

四、关于content目录结构说明

• Embedder API is under src/content/public
• content/public should contain only interfaces, structs and (rarely) static functions
•  If a mojom is only used inside content, it should be in content/common
•  If it's an interface that is implemented or called by content's embedder, then it belongs in content/public/common.
• all code under content should be in the "content" namespace
• content implementation code should use other implementations directly and not go through the interface (i.e. code in content/renderer should use RenderViewImpl instead of content::RenderView)
• only expose methods in the public API that embedders need. If a method is only used by other code in content, it belongs in foo_impl.h and not foo.h.

 

以上几点来自于chromium官方文档，http://www.chromium.org/developers/content-module/content-api,

选了几点个人认为比较重要的贴出来。

 

 

五、content shell 与content api 的关系

1、 content_shell调用的所有接口的头文件都在content/public目录下

2、 content_shell还包含了content/common目录下的个别头文件，这些文件只是某些通用的功能的实现，并不属于content api。

3、 content_shell还包含了少数其他模块的头文件，base、build、components、cc、media、ui、sandbox、net、ipc、device、testing、url、mojo、storage、services、third_party、chromeos、grit、skia、v8、ppapi、mojo

4、 content_shell通过包含content api头文件调用相关api，api的实现的.cc文件在content目录下的其他目录(可能在public下，也可能在跟public同级的其他目录下)，通过lib方式使用。

5、 content api 的头文件跟实现文件太分裂，有些是在同一目录下，有些是在不同目录下，这点还没有领会其真正用意。