CEF1和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进程使用；第二，仅在沙箱模型关闭时使用。