早在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的呼叫者們定製自己的邏輯
早在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的呼叫者們定製自己的邏輯