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 的头文件跟实现文件太分裂，有些是在同一目录下，有些是在不同目录下，这点还没有领会其真正用意。