轉載自: http://blog.csdn.net/haojun186/article/details/50450429
- Content API爲何物
- CEF和CEF3有和區別
- CEF3與Content API的關係
1、Content API的由來
首先我們先了解Chromium是怎麼顯示網頁的，請看下圖：
這是一幅介紹頁面如果被渲染和顯示的概括性的層次結構圖。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不僅提供了公開和穩定的接口，而且它從誕生以來一個重要的目標就是要支持所有的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中的線程創建和消息的過濾。
2、CEF和CEF3有和區別
早在content API出現之前，CEF便已出現，其目的是提供嵌入式的框架，可以讓渲染網頁的功能方便地嵌入到應用程序之中。CEF依賴於chromium瀏覽器，所以chromium對HTML5的支持和性能上的優勢，都得以繼續在CEF中體現出來。但是，根據實際測試的結果來看，情況可能並非如此。首先，其對GPU硬件加速的支持不是很好，這時因爲它會把GPU內存讀回到CPU內存，速度非常慢；再次，因爲基於chromium的內部結構，而它們經常變化，所以CEF經常需要發生變化，這對維護來說是件很頭痛的事。
得益於content API的出現，CEF的作者也基於它開發了CEF3。CEF3在保持其提供的接口基本不變的情況下，藉助content API的能力，其對HTML5和GPU硬件加速提供了較好的支持。它的核心變爲調用content API的接口和實現content API的回調接口，來組織和包裝成CEF3自己的接口以被其他開發者所使用。其好處是，CEF3的接口相對比較簡單，使用起來方便，同時不需要實現很多content API的回調接口，但是缺點就是，如果需要使用content API的很多功能，CEF3的接口可能做不到，或者說只能通過直接調用content
API接口來完成。
下面簡單介紹一下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進程使用；第二，僅在沙箱模型關閉時使用。
