|
转载请注明原文地址：http://blog.csdn.net/milado_nju/article/details/7455373 # Content API及CEF3 ## 概述 相信你一定看过下面这张图（没看过的话去上官网阅读一下“how chromium displays web pages”）。
这是一幅介绍页面如果被渲染和显示的概括性的层次结构图。Renderer进程和Browser进程通过IPC来交换信息，具体的设施就是RendererHost和Renderer等相关类，其作用是把网页的内容（content）渲染成Tab的显示内容。一个Tab可能会包含多个页面的内容，因而它会管理Tab中的多个页面内容。Tab contents之上就是浏览器，Tab contents会把内容绘制在browser窗口的一个标签中。 Chromium把RendererHost及其以下部分称为Content，同时包括还有很多对HTML5功能实现的支持，contentAPI基于此两部分，包装成为一套公开的接口。Tab contents及以上部分称为Chrome（chrome的原意即是包装在网页内容之上的框）。浏览器中相关的功能仅仅在content API之上才有，而不存在于content API中。 上面的这个架构看起来没什么问题，但是，这对希望把chromium渲染网页的功能包装成接口，被内嵌到任何其他应用程序来说，就有着明显地不足。第一，在WebKit chromium移植中提供了一套公开的接口，但是它在renderer进程，没有很多chromium的提供的高级功能；第二，Chromium在browser进程中没有提供任何公开的接口，也就是说，如果基于RendererHost等开发一套嵌入式的接口，代价将是非常巨大的，因为这些内部使用的类及其接口是经常变动的（注意，确实变化的非常快）。
上图介绍的是WebKit的chromium移植接口和Content API在整个栈中所在的层次，“API boundary”是原来的WebKit的chromium移植所提供的公开接口，“Content API”表示的是新的content API所在的层次。层次上的向上移动带来了使用者的稳定性，HTML5功能的支持，GPU硬件加速功能，沙箱模型等的支持。这里稍微不同的地方是浏览器的功能在Content API之上，所以图片中的Application应该去除掉这一部分。图片来源于WebKit官网，略有修改。 下面我们来看一下chromium官网上所宣称引入Content API的两条原因： 1） 让Chrome的开发者们摆脱content内部的复杂工作原理和机制； 2） 给content和chrome划分清楚的界限来帮助开发者或者嵌入式的使用者们。 在了解了相关背景之后，上面的解释就相当简单明了了。 为了方便测试，chromium中有一个基于content api的简单测试程序content shell。它非常的简单，仅仅是一个壳，调用了content API并实现了部分必需的回调接口，可以用来测试和其他一些简单的功能。 CEF全称chromium embeddedframework，其目的是提供一套嵌入式的接口，最初的版本是基于早期的RendererHost和chrome浏览器的很多内部接口开发而来的，在新的CEF3中，其主要依赖于公开的Content API来实现的。 为了清晰地了解它们之间的的关系，下图描述了WebKit， content API，浏览器，content shell和CEF3的层次关系。Chrome浏览器，content shell和CEF3三者都是基于content API开发的，它们只是有不同的实现，服务于不同的应用场景而已。 后面的章节将重点介绍content API和CEF3，因content shell比较简单，故略过。
## Content API Content API不仅提供了公开和稳定的接口，而且它从诞生以来一个重要的目标就是要支持所有的HTML5功能和GPU硬件加速功能，这可以让它的使用者们不需要很多的工作即可以得到好的HTML5支持和硬件加速机制。同时，借助于现有的多进程架构，一些chromium中的新功能例如沙箱模型等也在其中得到了支持。 下面详细介绍一下Content API包含哪些部分。 Content API的相关的接口定义文件均在content/public目录下，按照功能分成六个部分：每个部分的接口一般也可以分成两类，第一类是嵌入者（embedder，这里可以是Chrome浏览器，CEF3和content shell）调用的接口，另一类是嵌入者实现的回调接口，被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） Plugin: 仅有一个接口告诉嵌入者plugin进程被创建了 5） Render 第一类包含获取RenderThread的消息循环，注册v8 extension，计算JavaScript表达式等等 第二类包括ContentRendererClient，主要是实现部分逻辑，被Browser端（或者进程）调用，还有就是一些事件的回调函数 6） Utility: 工具类接口，主要包括让嵌入者参与content API中的线程创建和消息的过滤。 ## CEF和CEF3 早在content API出现之前，CEF便已出现，其目的是提供嵌入式的框架，可以让渲染网页的功能方便地嵌入到应用程序之中。CEF依赖于chromium浏览器，所以chromium对HTML5的支持和性能上的优势，都得以继续在CEF中体现出来。但是，根据实际测试的结果来看，情况可能并非如此。首先，其对GPU硬件加速的支持不是很好，这时因为它会把GPU内存读回到CPU内存，速度非常慢；再次，因为基于chromium的内部结构，而它们经常变化，所以CEF经常需要发生变化，这对维护来说是件很头痛的事。 下面简单介绍一下CEF3的接口。 CefClient：回调管理类，包含5个接口用于创建其它的回调类的对象 CefLifeSpanHandler: 回调类，用于控制popup对话框的创建和关闭等操作 CefLoadHandler: 回调类，可以用来监听frame的加载开始，完成，错误等信息 CefRequestHandler: 回调类，用于监听资源加载，重定向等信息 CefDisplayHandler: 回调类，用于监听页面加载状态，地址变化，标题等得信息 CefGeolocationHandler: 回调类，用于CEF3向嵌入者申请geolocation的权限 CefApp: 与进程，命令行参数，代理，资源管理相关的回调类，用于让CEF3的调用者们定制自己的逻辑 CefBrowser: renderer进程中执行浏览相关的类，例如前进，后退等 CefBrowserHost: browser进程中的执行浏览相关的类，其会把请求发送给CefBrowser CefFrame: 表示的是页面中的一个Frame，可以加载特定url，在该运行环境下执行JavaScript代码等得。 V8：CEF3提供支持V8extension的接口，但是这有两个限制，第一，v8 extension仅在Renderer进程使用；第二，仅在沙箱模型关闭时使用。 ## Content API和WebKit2 Content API和WebKit2的接口都是基于跨进程的结构的，按我个人的理解，它们是互相影响而又互相吸收对方的优点，它们具有相同点，又有不同点： 1） Content API提供的是一套基于跨进程的架构模型（当然它也可以不是多进程的），这有利于browser（UI）进程的稳定，这同样对WebKit2适用； 2） Content API不仅如此，它里面包含chromium对于HTML5，GPU硬件加速，和沙箱模型等功能的支持，而WebKit2可能并非如此； 3） Content API是chromium提出的接口，而WebKit2是一个更加开放和公开的接口，被众多的WebKit移植所使用。 ## 源文件目录 Content/public/app ,Content/public/browser, Content/public/render, Content/public/common, Content/public/plugin, Content/public/utility ContentAPI所包含的相关的目录，里面包含所有的接口 ## 参考文献 1. http://www./developers/content-module/content-api 2. http://code.google.com/p/chromiumembedded/ By yongsheng@ |
|
|
