使用CEF（七）详解macOS下基于CEF的多进程应用程序CMake项目搭建
由于macOS下的应用程序结构导致了CEF这样的多进程架构程序在项目结构、运行架构上有很多细节需要关注，这一块的内容比起Windows要复杂的多，所以本文将会聚焦macOS下基于CEF的多进程应用架构的环境配置，并逐一说明了CMake的相关用法和CEF应用配置细节。
前言
在进行搭建之前，我们首先必须要弄清楚一个问题，我们最终到底要生成几个可执行应用。为什么要搞清楚这个问题呢？了解CEF的读者都知道，CEF属于多进程架构体系，包含有一个主进程管理整个浏览器应用（包括原生GUI窗体等），以及多种类型的子进程各自独立负责各自的职责（比如渲染进程以及GPU加速进程等）。
笔者在以前的文章中曾介绍过CEF中提供的样例cefsimple在Windows操作系统上的构建流程，我们发现这个cefsimple项目在编译后会最终只生成了一个exe可执行程序，而在运行时为了达到多进程的目的，该exe首先作为主进程入口启动，内部在准备启动子进程的时候，其做法是调用该exe本身，并通过命令行参数的形式来区分主进程和其他子进程。也就是说，该exe应用内部不仅包含了主进程代码，也包含了子进程代码，源代码中会根据命令行参数（--type=xxx）通过分支让主进程和子进程走到不同的逻辑：
而在macOS下，由于macOS本身对于应用程序的权限管理与Windows存在差异，它具备有一套特殊的沙盒机制来保证应用程序彼此独立和安全。所以，我们不建议像Windows那样最终通过编译生成一个App Bundle，来多次启动自己。一个很直观的例子可以解释这一点：假设我们现在基于CEF的应用程序编译并构建了一个App Bundle，这个app内将主进程代码和子进程代码写在了一起，通过运行时逻辑来区分。此时，假设主进程需要macOS的“钥匙串”权限，读取用户的一些配置。由于macOS权限是给到Bundle应用层面的，所以尽管我们只想让主进程得到“钥匙串”访问权限，但因为主进程和子进程都是同一个Bundle，无形中导致了子进程也同样拥有了这个权限，而像渲染进程这样的子进程，里面会运行js代码、wasm等第三方代码逻辑，一旦出现了BUG，就会存在权限泄漏风险。如果我们把主进程和子进程分离到两个Bundle，主进程所在Bundle获取某些系统权限，而渲染进程获取某些必要权限，就能做到主进程和子进程权限分离的目的，为安全性提供了一定保证。
所以，在了解了macOS下的CEF应用构建思路以后，我们开始搭建对应项目，并在搭建过程中对涉及的配置逐一解释，希望能够帮助读者理清项目脉络。
搭建
基础准备
搭建的步骤分为以下几步：
1）下载cef的二进制分发文件（cef_binary_xxx），将它解压存放到某个文件夹（可以不用放在项目目录下）；
2）配置一个环境变量CEF_ROOT，需要该环境变量值配置为cef_binary_xxx所在目录：
1 | ❯ echo $CEF_ROOT |
3）创建项目目录cef_app_macos_project，该目录将会存放本次macOS下工程的所有配置、源代码。
4）在项目根目录下创建cmake目录，并将步骤1中cef_binary_xxx/cmake/FindCef.cmake文件复制到cmake目录中：
项目根目录CMake配置
前期工作准备好以后，我们在项目根目录下创建CMakeLists.txt文件，并编写如下内容：
1 | CMAKE_MINIMUM_REQUIRED(VERSION 3.21) |
关于CMake本身的基础配置定义我们不再赘述，这里主要解释一下关于CEF引入的部分。首先，我们并没有把cef_bin_xxx目录复制到项目根目录下，而是放在了“外部”，并通过环境变量CEF_ROOT指向了它。在上述CMake关于CEF配置部分，我们对CMAKE_MODULE_PATH路径值追加了cef_app_macos_project/cmake目录。
${CMAKE_CURRENT_SOURCE_DIR}就指代了项目根目录cef_app_macos_project。
接下来，在find_package(CEF REQUIRED)的时候，CMake会搜索CMAKE_MODULE_PATH路径下的名为FindCEF.cmake的CMake配置，于是就能找到我们曾复制的cef_app_macos_project/cmake/FindCEF.cmake文件并进行加载。
如果CMake初始化的时候出现了：
CMake Error at CMakeLists.txt:20 (message):
环境变量CEF_ROOT未定义！请确保CEF_ROOT环境变量确定配置了。
对于FindCEF.cmake本身的内容，其核心逻辑就是读取环境变量CEF_ROOT值，然后定位到cef_binary_xxx目录，并加载cef_binary_xxx/cmake/cef_variables.cmake和cef_binary_xxx/cmake/cef_macros.cmake两个CMake配置文件。
这两个文件的作用分别是定义一些CEF提供的变量和宏方法，以便在后续的CMake加载逻辑中使用。
在find_package以后，我们调用了add_subdirectory指令，该指令第一个参数${CEF_LIBCEF_DLL_WRAPPER_PATH}就使用了来自cef_variables.cmake中定义值，指代了libcef_dll_wrapper代码工程的目录：
因此，这里的逻辑就是将cef_binary_xxx/libcef_dll目录作为了我们的CMake子模块工程，于是CMake会进一步加载cef_binary_xxx/libcef_dll/CMakeLists.txt文件并进行CMake相关文件的生成。细心的读者会注意到，这里还存在第二个参数libcef_dll_wrapper：
这里需要这个参数值的原因在于，libcef_dll_wrapper所在目录是一个外部路径，所以需要提供一个目录名作为的CMake文件二进制生成的路径。如果不提供，则会收到错误：
那么第二个参数具体影响了什么呢？如果读者使用CLion+CMake，会看到CLion会在项目根目录下生成cmake-build-debug目录，这个就是CMake生成文件目录，编译后的结果、CMake的过程文件都会在这个目录下找到（该目录其实就是cmake命令行的-B参数指定的路径，CLion默认指定的项目根目录下/cmake-build-debug目录）。在这里，当我们add_subdirectory添加了libcef_dll_wrapper子模块，经过CMake的初始化以后，会看到cmake-build-debug/libcef_wrapper_dll路径的产生：
至此，我们添加了对CEF的libcef_dll_wrapper子模块的引入，为了验证模块引入的正确性，我们尝试在当前cef_app_macos_project这个项目中对引入的子模块进行编译。有两种操作方式，方式1就是进入cmake-build-debug这个目录下使用命令：cmake --build .；当然，我们还可以使用IDE提供的更加便利的方式2：CLion直接使用GUI即可。
如果一切没有问题的情况下，我们可以在output目录中找到libcef_dll_wrapper的生成出来的库文件：
在继续后面的讲解前，我们先放慢脚步，对项目环境做一个总结。我们首先准备了两个目录，一个是我们自己的cef_app_macos_project目录，我们会在这个项目中“引入”CEF相关库，后续还会在里面编写我们自己的应用程序；另一个则是在外部的cef_binary_xxx目录，我们不会改动其中的内容。
对于我们自己的cef_app_macos_project，在根目录下，我们编写了一个CMakeLists.txt，它是我们项目顶层的CMake配置，该文件核心配置逻辑分以下几步：
- 一些基本的项目、编译配置；
- 加载CEF的CMake配置；
- 引入外部的
cef_binary_xxx中的libcef_dll_wrapper模块作为CMake子模块。
但请注意，目前我们仅仅是通过CMake提供的add_subdirectory命令，将libcef_dll_wrapper作为子模块引入，但目前还没有任何的应用在依赖它，接下来我们将进一步，开始配置主进程应用，并依赖该libcef_dll_wrapper。
主进程应用项目配置
在项目根目录下，我们创建cef_app目录，该目录目前先存放CEF的macOS应用的主进程应用项目代码。我们在cef_app目录下创建process_main.mm，且暂时先编写一段简单的代码：
1 |
|
PS：
.mm为后缀文件是指Objective-C与C/C混写的源代码文件后缀，所以这里我们是可以完全写C代码的。
然后，在cef_app目录中创建CMakeLists.txt文件，并编写如下的配置：
1 | # ===== 主进程target配置 ===== |
我们接下来对上述的配置逐一解释：
1 | # 主进程target名称 |
上述配置了我们接下来将会定义的target的名称，以及后续生成的macOS特有的App Bundle的应用文件的路径，后续会使用到该值。
1 | add_executable( |
add_executable部分定义最终生成的target，除了包含编写的源码路径（process_main.mm），这里还有一个很重要的参数MACOS_BUNDLE，配置该参数后，在macOS下，我们最终生成的可执行程序就不再是一个简单的命令行程序，而是macOS下的App Bundle。下图是没有配置该值前后的对比：
可以看到，没有配置MACOSX_BUNDLE时，最终项目会在输出目录（${CMAKE_CURRENT_BINARY_DIR}）下生成名为cef_app的可执行命令行程序；而配置以后，项目会在输出目录下生成target名.app，这里就是cef_app.app。
1 | # 使用CEF提供的预定义好的工具宏，该宏会帮助配置target一些编译上的配置 |
SET_EXECUTABLE_TARGET_PROPERTIES不是CMake提供的指令，而是由CEF提供的，存放于cef_macros.cmake中的宏。该宏主要的功能是对目标target配置一些可执行程序所需要的编译参数等。如果读者在实践过程中，遇到了链接问题，可以优先检查这个宏中的实现。由于篇幅原因，这块后续单独出一篇文章水一水，>_<。
1 | # 添加对 libcef_dll_wrapper 库的依赖 |
add_dependencies的作用则是为当前target指定依赖。因为我们的项目本身会通过静态链接库的形式链接libcef_dll_wrapper，通过这add_dependencies能够保证最终构建过程中，确保优先将libcef_dll_wrapper编译出来，供后续链接过程使用。当然，你也可以不闲麻烦的手动先编译libcef_dll_wrapper，再编译这个cef_app。
1 | # 链接库配置 |
target_link_libraries处理则是配置当前target的链接库，包括不限于libcef_dll_wrapper的静态链接、各种平台特定的链接库等。最后一个参数变量CEF_STANDARD_LIBS，由CEF在cef_variables.cmake中定义，包含平台特定的链接库。
例如，在Windows下我们可能需要
gdi32.lib，在Linux构建窗体可能需要X11库，以及在macOS下需要Cocoa、AppKit等框架库。读者可以翻阅cef_variables.cmake中关于这个变量的配置了解具体的内容。
1 | # 主进程编译后，会在输出目录下生成一个名为 cef_app.app 的macOS App Bundle。 |
倒数第二个指令add_custom_command，在介绍它的作用前，先简单说明在macOS下基于CEF的App Bundle的一应用结构。基于前面的配置，主进程编译后，会在输出目录下生成一个名为cef_app.app的macOS App Bundle，该Bundle内部/Contents/MacOS/cef_app可执行程序，就是链接了源码二进制、libcef_dll_wrapper静态库后的可执行二进制程序。然而，CEF核心库Chromium Embedded Framework.framework我们并没有静态链接到执行程序内，而是在实际运行过程中，动态加载这个framework。为了达到该目的，我们思路是通过脚本将cef_binary_xxx中提供的CEF的核心库framework拷贝到App Bundle中指定路径下。
所以，在了解了App Bundle运行逻辑以后，关于add_custom_command作用就显而易见了，其逻辑就是配置在构建完成以后，通过CMake的工具指令（-E copy_directories）将Chromium Embedded Framework.framework整个内容复制到生成的Bundle的/Contents/Frameworks目录下：
在上面的讲解中我们大致理解了macOS的App Bundle的应用程序组织结构，细心的读者会发现，在构建后的Bundle中的根目录下有一个文件Info.plist：
该文件的核心作用是定义macOS下App Bundle的基础应用程序配置，包括不限于该应用的名称、应用ID、图标资源等。因为我们将主进程target定义为了MACOS_BUNDLE，CMake会在构建的时候，默认为我们的Bundle生成了一份plist并写入到Bundle中。同时我们会发现，Info.plist配置中关于CFBundleName、CFBundleIdentifier等值就是我们现在的target的名称：
原因在于配置文件中紧接着add_custom_command后面的set_target_properties：
1 | # 简单配置Info.plist的一些值 |
使用set_target_properties指令指定了MACOSX_BUNDLE_BUNDLE_NAME和MACOSX_BUNDLE_GUI_IDENTIFIER的值。关于这段配置的说明，官方文档提到：https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.html，我们可以直接通过相关属性值来替换CMake内置的plist模板文件内容。
注意，CMake支持的变量只有上述官方文档提供的Key，如果有其他的Key需要处理，只能通过自己提供模板方法进行处理，这点会在后面构建子进程Bundle再次说明。
至此，我们基本完成了在macOS对主进程的CMake配置。此时，请务必注意，记得在项目根目录的CMakeLists.txt追加如下将cef_app目录作为子模块引入的配置：
1 | # 1. CEF前置准备完成后，此处便可以使用变量 CEF_LIBCEF_DLL_WRAPPER_PATH ，该值会返回libcef_dll_wrapper的目录地址 |
当然，我们主进程应用的源代码还是只是简单的在控制台输出一段话，我们不着急编写主进程代码，接下来还需要配置对应的子进程项目。
子进程应用项目配置
我们在一开始已经提到过，在macOS建议将主进程和子进程分别构建为两个不同的App Bundle，这里我们有两种做法：
-
方式1：通过CMake的定义target，在前面主进程CMakeLists.txt中直接定义子进程的target，让构建系统同时生成另外的子进程应用。
-
方式2：直接重新创建一个目录来定义子进程CMake模块并存放子进程模块代码。
这里笔者使用第一种方式来进行配置，或许配置上略显复杂，但只要读者一旦理解，笔者相信今后对于其他CMake项目配置应该也能很快上手。
我们先在cef_app目录中创建一个名为process_helper.mm的文件，暂时作为子进程的入口源码：
1 |
|
同时，在该子模块目录下创建一个templates目录，并在其中创建helper-Info.plist文件，具体的意义和其内容我们后面介绍，这里读者可以将它理解为一份模板文件。
此时，我们的项目结构如下：
为了阅读的方便，我们都将子进程叫做helper
接下来，我们在cef_app/CMakeLists.txt内容的基础上，添加如下的针对helper子进程应用的配置：
1 | # ===== 主进程target配置 ===== |
让我们从头到尾一一道来。
1 | # 定义helper子进程target名 |
首先，我们会定义helper子进程的target名称和输出应用名称。但需要注意的是，这里的名称不完全是最终输出的应用程序的名称。因为在后续的配置中，我们会使用CMake支持的循环命令来支持生成多个target。
1 | # 创建多个不同类型helper的target |
接着，我们使用CMake的foreach指令，来遍历变量CEF_HELPER_APP_SUFFIXES这个变量值。这个变量来自于cef提供的变量（cef_variables.cmake）：
1 | # CEF Helper app suffixes. |
在这里通过CMake的遍历能力，我们每一次迭代都能读取到对应一条字符串并存放到_suffix_list变量中。
接下来介绍在foreach包裹的内部配置：
1 | # 将字符串转为";"分割，这样可以使用CMake支持的list(GET)指令来读取每一节字符串 |
我们将_suffix_list变量中所有的:字符替换为;，然后就可以使用CMake支持的list(GET)指令来读取每一节字符串。
以 " (Renderer):_renderer:.renderer"为例，在替换后，通过list(GET)可以分别得到：
- _name_suffix =
" (Renderer)" - _target_suffix =
"_renderer" - _plist_suffix =
".renderer"
这三个suffix将在后续的流程拼接出相关名称变量。但需要注意的是，在CEF_HELPER_APP_SUFFIXES中存在一个特殊的字符串："::"。这个字符串会导致最后提取出来的前面三个suffix都是""（空字符串），这并不是BUG，后续会用到。
1 | # 定义一个Helper target以及BUNDLE名称 |
接下来，我们开始消费suffix。首先，我们通过拼接操作得到_helper_target和_helper_output_name。这两个变量分别代表了当前正在构建的helper的真正target名和对应后续构建的应用名称。还是以 " (Renderer):_renderer:.renderer"为例。我们能够得到：
_helper_target="cef_app_helper" + "_renderer"得到"cef_app_helper_renderer"_helper_output_name="cef_app Helper" + " (Renderer)"得到"cef_app Helper (Renderer)"
1 | # 读取templates/helper-Info.plist模板文件内容到_plist_contents |
接下来，我们使用CMake提供的能力，读取了前面提到的存放在cef_app/templates目录下的helper-Info.plist文件。这是一个模板文件，打开后读者能从中看到一些${XXX}的占位字符串，我们会在这一步进行对应文本的替换。这里我们用到了CMake的几个知识点：
- file(READ)读取某个文件并存放到文本变量中；
- string(REPLAECE)替换文本变量中某些字符串并写回到变量中；
- file(WRITE)将文本数据写入到某个文件中。
这一步我们还得到了_helper_info_plist_file变量，它指向了我们写入的plist文件，以便在后续配置中进行使用。
1 | # 创建当前helper的executable target，当然，也是一个App Bundle |
和前面主进程应用target类似。我们将helper的构建结果同样定义为App Bundle；使用SET_EXECUTABLE_TARGET_PROPERTIES来进行编译参数等设置；使用add_dependencies告诉CMake编译构建子进程target的时候，保证libcef_dll_wrapper优先于helper构建完成；使用target_link_libraries链接子进程Helper。但，最后一个set_target_properties和之前主进程target设置有所不同。在之前的主进程应用配置时，我们直接使用了诸如MACOSX_BUNDLE_BUNDLE_NAME、MACOSX_BUNDLE_GUI_IDENTIFIER等参数来让CMake使用内置的plist模板文件生成主进程应用App Bundle中的plist文件。但因为CMake内置的模板plist只能设置部分字段值，而在Helper配置的时候，我们需要更改更多的占位字段，所以我们自己提供了helper Bundle的模板plist，并通过内容读取、字符串替换的方式生成了对应Helper的Bundle的plist文件内容。要让CMake不再使用内置的模板plist，而是使用我们生成的plist文件，我们使用参数MACOSX_BUNDLE_INFO_PLIST指定前面生成好的plist文件路径。最后，我们还定义了OUTPUT_NAME这个参数，这个参数主要的作用是可以自定义生成的应用程序的名称，如果没有这个参数，我们最终在构建结果目录中生成应用名称就是target。
1 | # 构建主进程应用前，会先构建当前Helper target |
告诉CMake，构建主进程target应用的时候，会先构建当前Helper target。
1 | # 将构建的Helper App Bundle拷贝到主进程cef_app的Bundle中 |
在循环的最后，我们再次使用add_custom_command通过CMake提供的文件复制能力，让主进程应用构建完成以后，将当前子进程helper应用app复制到主进程应用.app/Contents/Frameworks目录下。至于为什么要这么做，我们将会在下一篇文章中介绍应用程序运行时架构来说明。
基于现在完成的配置，我们可以通过对cef_app进行构建，检查最终构建的产物来验证项目的正确性。笔者使用CLion的GUI生成cef_app，最终会在输出目录中找到cef_app.app，同时会看到会生成多个helper的App Bundle，并已经成功复制到了对应目录中：
写在最后
在本文，我们基本上完成了在macOS下基于CEF的多进程应用架构的项目CMake配置，并结合实际的配置，逐一说明了CMake的相关用法和配置细节。在下一篇文章中，我们会基于此文搭建的项目，逐步介绍并编写macOS下基于CEF应用程序的代码，其中会涉及到macOS下Cocoa框架知识简介。