Chromium 嵌入式框架

http://www.magpcss.net/cef_downloads/

在此由衷地感谢 Chromium 嵌入式框架的创始人 Marshall Greenblatt，他撰写并帮助编辑了本篇博文的部分内容。

Chromium 嵌入式框架 (CEF) 是一个开源项目，可使开发人员轻松地在其桌面应用程序中显示 HTML 内容。通过可用的 API，可以精细地控制甚至可以扩展 HTML 视图。在底层，HTML 呈现是通过 Chromium 浏览器项目完成的，该项目基于 Blink 引擎（以前称作 WebKit）和 V8 JavaScript 虚拟机。

就像框架通常的做法一样，CEF 主要提供一组标头和一个库。它可以在 Windows、Mac OSX 和 Linux 上使用，不过仍需要完成一些工作才能在平台间实现功能对等。C++ 和 C API 作为此项目的一部分提供，但已经存在为 .NET、Java 和 Python 等其他环境维护包装程序的项目。

与 Chromium 的关系

CEF 推出了两种版本，分别是 CEF1 和 CEF3，这两种版本都得到了积极维护。这两个项目向嵌入客户端公开的 API 几乎相同，同时使用 Chromium 风格的 WebKit（现为 Blink）来呈现 HTML。二者的不同之处体现在它们与底层 HTML 引擎结合的方式上，不过，为了更好地了解这一点，对 Chromium 体系结构进行总体概述会十分有用。

Chromium 体系结构主要有三个层：Blink（以前称作 WebKit）API、Content API 和 Chrome。借助 Blink API，可以访问呈现引擎和 V8 JavaScript 引擎，这两个引擎在单个进程中一起运行。Content API 增加了多进程体系结构，并为更为复杂的 HTML5 和浏览器功能（例如加速合成、地理位置和 WebRTC）提供了具体实现。Chrome 层包括 Chrome 浏览器用户界面以及与 Chrome 浏览器紧密耦合的各种功能实现，例如历史记录管理、扩展程序和书签。Chromium 团队目前正在致力于引入称作“组件”的第四种概念，此概念将为跨多个层的浏览器功能提供模块化实现。

Blink API 和 Content API 不稳定，而且很多功能都有其他的实现要求。CEF 便提供了这些实现，以及一个隐藏了大部分底层 Chromium 和 Blink 复杂性的稳定 API。CEF1 直接使用 Blink API，并因此而共享单进程体系结构。CEF3 使用 Content API 并受益于多进程体系结构以及 Content API 中实现的很多高级功能。得益于“组件”方面的变化，将更容易有选择性地启用和共享目前因与 Chrome 层紧密耦合而无法共享的功能实现，这对 CEF3 而言是一项额外的益处。

CEF3 实现了 Content API 提供的一部分接口和委派，实现方式与 Chrome 颇为相似。虽然开发人员可以直接从 Content API 开始嵌入 Chromium，但这会涉及到相当大的工作量，而这些工作在 CEF3 中已经完成。这些工作包括实现应用程序希望操纵的 Content API 接口和委派，并且在实现的过程中，还要为应用程序所需的运行平台 (Windows/Mac/Linux) 编写平台代码。另一方面，使用 CEF 时则十分简单：只需先编写几行代码，然后直接在应用程序内触发一个现代、最新的 HTML5 视图即可。

CEF1 和 CEF3 都将 Chromium 的某些部分纳入到了所产生的库中，并因此形成了对 Chromium 代码的依赖性。该项目保持了与底层特定版本 Chromium 代码的兼容性，这些代码的更新颇为频繁。从这个角度而言，嵌入者不必担心更新 Chromium 会破坏他们的应用程序。

从此处开始，除非另有说明，否则 CEF 这个术语将称作 CEF3。

快速入门

要着手使用 CEF，最简单的方式或许就是下载其中一个二进制版本。CEF 维护的一些分支与用于各版本的 Chromium 稳定分支兼容。定期发布的二进制版本通常都是基于一个此类稳定分支生成的。

可分发程序包包含标头、库、一些必需的资源以及一款称作 cefclient 的测试应用程序。这正是您应该着眼的地方。它完美地展示了如何使用 CEF，从启动该框架到实现通过 API 公开的 HTML 内容回调，都一一说明。您可以通过修改应用程序代码、快速重新生成等方式进行测试。

请注意，您还可以将 Chromium 命令行开关传递给 cefclient，以这种方式使用时它们所产生的效果将与在浏览器中产生的效果（如果适用）相同。

如果您要作出贡献，或者要使用其中一个二进制版本目前未提供的功能，您必须基于源代码生成 CEF 库。虽然 CEF 本身是非常轻便的，但这还涉及到生成 Chromium，从而使工作复杂性略有增加。在本篇博文中我不作细致阐述，但如果您想知道要从何处着手，可以浏览一下 CEF 的 automate 文件夹。其中的 python 脚本会签出 CEF 和 Chromium 源代码，并继续生成最终 CEF 程序包。同一文件夹中的 README 文件更加详细地描述了这一过程，并且还包含了在运行该脚本前要执行的一些必需步骤。

Adobe 贡献

下面列出的是除了各种缺陷修复之外，我们为 CEF 作出的更重要的贡献。

Mac 上的 IME [CEF1]

我们为 CEF 作出的第一项重要贡献就是为 Mac OS X 的输入法编辑器 (IME) 实现了缺失的平台代码。在 CEF1 中，此代码完全缺失。在 CEF3 中，Content API 类别下已经提供了此代码。

跟踪 API [CEF3]

跟踪机制是一种 Chromium 开发工具，可用于跨线程和进程分析 Chromium 代码。如果您想一探究竟并开始跟踪，只需在 Chrome URL 栏中键入 chrome://tracing 即可。我们作出的贡献是将内部跟踪 API 作为 CEF API 的一部分进行了公开。嵌入者可以使用这些方法在他们自己的客户端应用程序内通过与整个“CEF – Chromium – Blink”堆栈相同的视图来分析调用。

Windows 和 Mac 上的屏幕外呈现 [CEF3]

借助此功能，嵌入者可以收到 CEF 发来的绘图通知，而不是让 CEF 直接呈现到本机窗口。随后，嵌入者便可以使用诸如 OpenGL 或 Direct3D 等技术来自行处理呈现。UI 事件也可以转发到 HTML 页面，这也是此功能的一部分。当嵌入者希望在 HTML 视图上绘制其他内容或者希望与自行执行呈现的现有应用程序框架集成时，这尤为有用。使用屏幕外呈现的做法为在两个重叠视图甚至是两个 HTML 视图间进行同步绘制提供了一种简单的解决方案。处理两个重叠、透明的本机视图时，进行同步绘制将非常麻烦。

另一种使用情形是打破 64 位进程与 32 位进程之间的界限。由于 Chromium 目前尚不支持 64 位内部版本，因此 CEF 二进制文件也将受到 32 位限制。故而，64 位应用程序将无法直接与 CEF 关联。不过，得益于屏幕外呈现，HTML 呈现可以隔离在 32 位进程内，而不在任何 UI 上呈现。所呈现的 HTML 结果随后可以通过一个网桥传回 64 位应用程序，并绘制在属于它的内部 UI 对象中。

后续步骤

我们计划贡献 IME 功能以便在 Mac 上实现屏幕外呈现。由于实现屏幕外呈现会覆盖其中一些内部 Content API 实现，因此需要使 IME 适应在没有它所绑定到的本机窗口的情况下工作。

我们也正在致力于为 CEF 搭建一种自动化的生成基础架构。该基础架构将定期生成 CEF、运行单元测试，并在公共位置发布内部版本。我们仍在斟酌此项目的相关细节（是每夜生成一次还是每进行一项改动便生成一次、是分支还是主干，等等）。

总结

如果您需要通过一种简单的跨平台方式在桌面应用程序中显示 HTML 内容，CEF 可能正合您意。它是开放的，并且有一个运作良好的社区在支持它，此外所有使用它的应用程序也无不证明了它的功用。

本文在 Web 平台功能中发表。