我们有一个 32 位应用程序，并且我们已经从中调用了一个 32 位铬嵌入式框架。
我们现在要调用 CEF3 64 位进程，因为我们无法将应用程序升级到 64 位。
是否有任何示例如何实现它（我读到有一个 IPC 架构），我必须说我能够创建子进程但是，我没有看到任何渲染（我猜主 UI 线程没有响应）。
【问题讨论】：
cef3 目前不支持您尝试完成的应用程序模型。即使您以某种方式获得了一个链接到 64 位 libcef.dll 的 64 位 cef 帮助程序可执行文件，您仍然需要在您的主可执行文件上包含相当多的 cef 应用程序代码。
因此，原则上您的 32 位主代码仍需要 32 位 libcef.dll，我怀疑他们无法与 cef 的辅助进程通信，因为他们的内部 IPC 可能与平台无关，换句话说，它可能使用带有本机整数等的共享内存，它们将不兼容，并且 AFAIK 没有用于利用它的全功能 IPC 代码。
根据您的跟进，问题是内存消耗，如果我是您，以下是我会采取的路径：
a) 尝试通过将 /LARGEADDRESSAWARE 传递给链接器来链接 32 位可执行文件（假设您使用的是 msvc）。这允许 32 位进程最多映射 3GB 的 RAM，如果您在 cef 论坛中搜索，您会发现相当多的用户在使用 32 位和没有它的情况下进行链接时遇到问题，例如http://magpcss.org/ceforum/search.php?keywords=large+address)。我自己有一个部署了 32 位可执行文件的产品，到目前为止还没有遇到内存问题，我正在使用这个选项。
b) 如果这还不够，最好的办法是将浏览器应用程序逻辑移动到一个单独的 64 位可执行文件，并在它和您的应用程序之间创建您自己的 IPC 形式。根据您的应用程序的需求，它可以像将 cef 主窗口附加到应用程序上的小部件并执行 https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md 中所述的操作一样简单，但我怀疑它可能会变得更复杂。
只有在使用上述任一解决方案的工作场景后，我才会考虑使用单独的 cef 帮助程序可执行文件（因为让它工作可能会妨碍您）。它的主要用途是提供更快的加载速度，因为您的应用程序通常链接到多个（有时是巨大的）DLL，而帮助程序可以简化为仅链接到 libcef.dll（和 c/c++ 运行时）。
如果您决定在 32 位场景中使用帮助程序，请不要忘记将它与 /LARGEADDRESSAWARE 链接。
【讨论】：