1. 项目缘起当嵌入式遇上 Swift如果你和我一样常年混迹在嵌入式开发的圈子里听到“Swift”这个词第一反应大概率是苹果生态里的那个高级编程语言用来写 iOS 或者 macOS 应用。把 Swift 和一块小小的、资源有限的嵌入式开发板联系起来听起来就像是让一个习惯了开跑车的人去开拖拉机——不是不行但总觉得有点“大材小用”或者“水土不服”。但这就是 Seeed Studio XIAO-C6 带来的一个非常有意思的尝试。我最初接触到这个项目纯粹是出于好奇。XIAO-C6 本身是一块基于乐鑫 ESP32-C6 芯片的微型开发板主打 Wi-Fi 6、蓝牙 5 和低功耗在物联网领域是个很不错的选手。而 Swift作为一门现代、安全、高性能的编译型语言其简洁的语法和强大的类型系统对于追求代码质量和开发效率的开发者来说吸引力巨大。那么在一个没有操作系统裸机或者仅有轻量级 RTOS 的嵌入式环境里Swift 能跑起来吗如果能它能做什么性能开销如何开发体验又怎样这不仅仅是技术上的猎奇。对于嵌入式开发者而言我们长期被 C 和 C “统治”虽然它们高效、底层但在内存安全、并发模型和现代开发工具链方面确实存在一些痛点。Swift 带来的内存安全保证如自动引用计数 ARC、优雅的错误处理机制、以及丰富的标准库或许能为嵌入式开发打开一扇新的大门特别是在需要快速原型验证、对代码健壮性要求较高的物联网应用场景中。对于 Swift 开发者来说这则意味着他们的技能树可以延伸到更广阔的硬件世界用熟悉的语言去控制 LED、读取传感器、连接网络实现真正的“软硬结合”。所以这篇指南的目的就是带你一起亲手在 XIAO-C6 这块板子上把 Swift 环境搭建起来并跑通第一个程序。我们会深入整个过程背后的原理剖析那些容易踩坑的细节并探讨这种组合的实用边界。无论你是想拓宽视野的嵌入式老手还是渴望接触硬件的 Swift 新手相信都能从中获得一些启发。2. 核心准备理解 Swift 嵌入式的基石在撸起袖子开始敲命令之前我们必须先搞清楚一个根本问题Swift 是如何在 XIAO-C6 这样的嵌入式目标上运行的这直接决定了我们后续工具链的选择和配置方向。2.1 Swift 编译器的交叉编译能力Swift 编译器swiftc本身支持交叉编译。所谓交叉编译就是在你的开发主机例如 x86_64 架构的 macOS 或 Linux上编译生成能在另一种架构例如 XIAO-C6 的 RISC-V上运行的二进制文件。这依赖于编译器后端对不同指令集架构ISA的支持。对于嵌入式常见的 ARM Cortex-M、RISC-V 等架构Swift 社区通过swift-embedded等项目或上游 LLVM/Clang 的支持提供了相应的编译目标target。例如针对 ESP32-C6其核心是 RISC-V 架构我们需要指定类似-target riscv32-unknown-none-elf这样的编译目标。这意味着编译器将生成符合 RISC-V 32位 ISA、不使用任何操作系统特定库none、采用 ELF 格式的二进制文件。2.2 运行时与标准库的裁剪在 macOS 或 Linux 上运行 Swift 程序我们依赖一个庞大的 Swift 运行时库包含 ARC、类型元数据、并发调度等和完整的 Swift 标准库。这在资源紧张的嵌入式设备上是不可接受的。因此嵌入式 Swift 开发的关键一步是“裁剪”。我们需要一个为嵌入式环境定制的、极度精简的运行时和标准库子集。这个子集通常只包含最核心的功能如基本类型Int, String、内存管理基础、以及必要的底层运行时支持。像Foundation框架这种大家伙在裸机环境下基本是无法直接使用的你需要寻找或实现其替代品例如用 C 标准库函数实现部分功能。目前这项工作通常由swift-embedded或芯片厂商/社区提供的 SDK 来完成。它们会提供一个预编译好的、针对特定芯片架构的精简版 Swift 运行时库.a文件和相应的头文件。2.3 与现有嵌入式生态的桥接C 互操作性嵌入式世界的基础设施几乎都是用 C 语言写的芯片厂商提供的 HAL硬件抽象层库、各种 RTOS如 FreeRTOS、Zephyr的 API、以及设备驱动程序。Swift 想要控制硬件必须能与这些 C 代码对话。幸运的是Swift 拥有优秀的 C 互操作性。通过import一个模块映射module map文件Swift 编译器可以理解 C 头文件中的函数声明和数据结构并允许你在 Swift 代码中直接调用这些 C 函数、使用这些 C 结构体。这是嵌入式 Swift 的“生命线”。例如你可以写一个module.modulemap文件将乐鑫的esp_idfHAL 库中的gpio_set_level函数暴露给 Swift然后在 Swift 中调用它来控制 GPIO 引脚。// 假设通过 modulemap 引入了 gpio.h func setLED(on: Bool) { let level: UInt32 on ? 1 : 0 gpio_set_level(LED_GPIO_NUM, level) // 直接调用 C 函数 }理解了这三点我们就知道整个流程的核心是在主机上使用支持 RISC-V 目标的 Swift 交叉编译器链接针对 XIAO-C6 裁剪过的 Swift 运行时和标准库并通过 C 互操作调用乐鑫 ESP-IDF 提供的硬件接口最终生成一个可以烧录到闪存中的 ELF 文件。3. 环境搭建构建专属的 Swift 嵌入式工具链理论清晰了现在开始动手。由于官方并没有为 ESP32-C6 提供开箱即用的 Swift 工具链我们需要自己动手或者利用社区项目进行搭建。这里我推荐一个相对活跃的社区项目作为起点swift-embedded请注意具体项目名称和状态可能随时间变化本文以核心概念和流程为主你需要查找最新的、支持 ESP32-C6 的衍生项目。注意以下步骤基于 Linux 开发环境Ubuntu 22.04进行演示。macOS 环境原理类似但部分依赖和路径需要调整。整个过程涉及从源码编译大型工具链对网络和机器性能有一定要求。3.1 基础依赖安装首先确保你的系统安装了必要的编译工具和依赖。sudo apt-get update sudo apt-get install -y \ git cmake ninja-build \ clang libxml2-dev libicu-dev \ python3 python3-pip \ libssl-dev libncurses-dev \ flex bison gperf \ ccache这些包包括了编译 Swift 和 ESP-IDF 所需的编译器clang、构建系统cmake, ninja、库文件以及 Python 环境。3.2 获取并配置 ESP-IDF乐鑫的 ESP-IDF 是开发 ESP32 系列芯片的官方框架提供了芯片支持包HAL、Wi-Fi/BLE 栈等和构建工具。即使我们用 Swift 写主逻辑也需要它来提供最底层的硬件驱动和启动代码。# 1. 创建项目目录并进入 mkdir -p ~/embedded-swift-xiao cd ~/embedded-swift-xiao # 2. 克隆 ESP-IDF推荐使用特定 release 版本如 v5.1 git clone -b v5.1 --recursive https://github.com/espressif/esp-idf.git cd esp-idf # 3. 安装 ESP-IDF 所需的所有工具编译器、调试器、烧录工具等 ./install.sh all # 4. 激活 ESP-IDF 环境变量 # 每次打开新终端都需要执行或者将其添加到 shell 配置文件中 . ./export.sh执行export.sh后你的终端环境里就加入了idf.py这个核心构建命令以及针对 RISC-V 的riscv32-esp-elf-交叉编译工具链。3.3 构建 Swift 嵌入式工具链这是最具挑战性的一步。我们需要一个能生成 RISC-V 代码的 Swift 编译器以及对应的精简运行时库。方案一使用社区预编译工具链如果存在最省事的方法是查找是否有社区爱好者为riscv32-unknown-none-elf目标编译好的 Swift 工具链。如果有下载并解压到指定目录如~/swift-embedded-toolchain然后设置PATH环境变量即可。方案二从源码编译通用方法假设没有现成的我们需要从 Swift 源码和swift-embedded项目源码开始编译。# 回到工作目录 cd ~/embedded-swift-xiao # 1. 克隆 swift-embedded 项目这是一个组织包含多个仓库 git clone --recursive https://github.com/swift-embedded/swift-embedded.git cd swift-embedded # 2. 该项目通常包含构建脚本。查看 README按照指示操作。 # 通常步骤是 # a. 确保所有子模块更新 git submodule update --init --recursive # b. 运行构建脚本指定目标为 riscv32-unknown-none-elf # 例如./build.py --target riscv32-unknown-none-elf --install /path/to/install # 这个过程非常漫长可能需要数小时因为它会编译整个 LLVM、Clang、Swift 编译器以及运行时库。编译成功后你会在安装目录下得到bin包含swiftc,swift等、lib包含精简的运行时库和share目录。将这个bin目录加入你的PATH。3.4 验证工具链工具链就位后进行快速验证。# 验证 Swift 编译器能否识别目标架构 swiftc -print-target-info -target riscv32-unknown-none-elf # 验证链接器能否找到标准库 # 创建一个极简的 Swift 文件 test.swift echo print(Hello from Swift!) test.swift # 尝试编译可能会因为缺少 swiftSwiftOnoneSupport 等库而失败这是正常的目前只是测试编译器 swiftc -target riscv32-unknown-none-elf -nostdlib -no-link-rtlib test.swift -o test.elf 21 | head -20如果第一步能正确输出 RISC-V 的目标信息说明编译器配置基本正确。第二步的链接错误是预期的因为我们还没有正确配置库的搜索路径和链接参数。4. 第一个项目从 Blink LED 开始环境准备就绪我们来创建第一个项目让 XIAO-C6 板载的 LED 闪烁。这是嵌入式世界的“Hello World”。4.1 项目结构创建我们创建一个标准的混合项目结构包含 Swift 代码、C 桥接头文件、以及 ESP-IDF 的组件配置。cd ~/embedded-swift-xiao mkdir -p swift-blink/main components/swift_runtime目录结构规划如下swift-blink/ ├── CMakeLists.txt # 项目顶层 CMake 配置 ├── main/ │ ├── CMakeLists.txt # 主程序 CMake 配置 │ ├── app_main.swift # Swift 主程序入口 │ ├── bridge.h # C 头文件声明需要暴露给 Swift 的 ESP-IDF 函数 │ └── module.modulemap # Swift 模块映射文件 ├── components/ │ └── swift_runtime/ # 放置 Swift 精简运行时库和链接脚本 │ ├── CMakeLists.txt │ ├── libswiftCore.a │ ├── libswiftSwiftOnoneSupport.a │ └── swift.ld # 内存布局链接脚本 └── sdkconfig # ESP-IDF 项目配置可后续生成4.2 编写 C 桥接层由于 Swift 不能直接包含 ESP-IDF 的 C 头文件我们需要一个中间层。main/bridge.h:#ifndef BRIDGE_H #define BRIDGE_H #include driver/gpio.h // 引入 ESP-IDF 的 GPIO 驱动头文件 #include freertos/FreeRTOS.h #include freertos/task.h // 声明我们想要在 Swift 中使用的 C 函数 // 这里只是简单包装也可以直接暴露原函数 void bridge_gpio_set_level(gpio_num_t gpio_num, uint32_t level); void bridge_vTaskDelay(uint32_t ticks); #endif // BRIDGE_Hmain/bridge.c:#include bridge.h void bridge_gpio_set_level(gpio_num_t gpio_num, uint32_t level) { gpio_set_level(gpio_num, level); } void bridge_vTaskDelay(uint32_t ticks) { vTaskDelay(ticks / portTICK_PERIOD_MS); // 注意转换vTaskDelay 参数是 Tick 数 }main/module.modulemap:module Bridge { header bridge.h link Bridge export * }这个文件告诉 Swift 编译器有一个叫Bridge的模块它的接口定义在bridge.h里链接时需要找名为Bridge的库对应我们编译的bridge.c。4.3 编写 Swift 主程序main/app_main.swift:// 导入我们定义的 Bridge 模块从而可以调用 C 函数 import Bridge // 导入 Swift 标准库中的基础部分如果精简版支持 // 注意嵌入式环境下可能没有完整的 Foundation 或 Dispatch。 // 定义 GPIO 引脚号XIAO-C6 的板载 LED 通常连接在某个 GPIO 上例如 GPIO 2 let ledPin: UInt32 2 // 任务入口函数相当于 C 中的 app_main _cdecl(app_main) // 这个属性告诉编译器此函数应以 C 链接方式导出供 ESP-IDF 启动代码调用 public func app_main() - Void { // 1. 初始化 GPIO这里直接调用 C 函数实际可能需要更复杂的配置 // 假设 bridge.h 里暴露了 gpio_reset_pin 和 gpio_set_direction // 为了简化我们假设 LED GPIO 已经在 ESP-IDF 的启动阶段被配置为输出模式 print(Swift Blink Started!) // 注意print 可能需要重定向到串口才能看到 while true { // 2. 点亮 LED bridge_gpio_set_level(gpio_num_t(ledPin), 1) // 3. 延迟 500 毫秒 bridge_vTaskDelay(500) // 注意我们的包装函数可能已经处理了 tick 转换 // 4. 熄灭 LED bridge_gpio_set_level(gpio_num_t(ledPin), 0) // 5. 延迟 500 毫秒 bridge_vTaskDelay(500) } }几点关键说明_cdecl(app_main)这是关键中的关键。ESP-IDF 的启动流程最终会寻找一个名为app_main的 C 函数作为用户程序的入口。这个属性将我们的 Swift 函数app_main()以 C 语言调用约定进行编译和链接使其能被系统正确找到和调用。类型转换Swift 的UInt32需要显式转换为 C 的gpio_num_t类型确保调用无误。print函数在裸机或 RTOS 环境下标准的print默认可能无处输出。你需要实现一个将输出重定向到 UART 串口的底层函数通常是一个 C 函数接收字符串指针然后通过类似的桥接方式让 Swift 调用。这里为了示例清晰暂时保留实际可能看不到输出。4.4 配置构建系统 (CMake)这是最复杂的一环需要将 Swift 编译过程嵌入到 ESP-IDF 的 CMake 构建体系中。顶层CMakeLists.txt:cmake_minimum_required(VERSION 3.16) include($ENV{IDF_PATH}/tools/cmake/project.cmake) project(swift-blink) # 告诉 ESP-IDF 构建系统主程序在 main 目录下 set(COMPONENT_DIRS main components) set(EXTRA_COMPONENT_DIRS components) # 注册项目组件 register_component()main/CMakeLists.txt:idf_component_register(SRCS bridge.c INCLUDE_DIRS . REQUIRES driver) # 设置 Swift 编译器路径和目标 set(SWIFTC_FLAGS -target riscv32-unknown-none-elf -Xcc -I${CMAKE_CURRENT_SOURCE_DIR} -Xcc -I${IDF_PATH}/components/driver/include -Xcc -I${IDF_PATH}/components/freertos/include/freertos) set(SWIFT_RUNTIME_DIR ${CMAKE_SOURCE_DIR}/components/swift_runtime) # 添加 Swift 源文件并定义编译规则 add_custom_command( OUTPUT app_main.swift.o COMMAND swiftc ${SWIFTC_FLAGS} -c ${CMAKE_CURRENT_SOURCE_DIR}/app_main.swift -o app_main.swift.o -module-name Main -emit-object DEPENDS app_main.swift bridge.h module.modulemap COMMENT Compiling Swift module Main ) # 创建一个静态库包含 Swift 对象文件和桥接对象文件 add_library(main STATIC bridge.c) target_link_libraries(main PUBLIC app_main.swift.o) # 关键在链接最终固件时将 Swift 运行时库和这个静态库链接进去 # 这通常在 project.cmake 中通过 LINKER_SCRIPT 和 EXTRA_LINKER_DEPS 变量全局设置 # 此处简化演示实际需要更精细地操作 idf_build_process 的变量components/swift_runtime/CMakeLists.txt:idf_component_register() # 将预编译好的 Swift 精简运行时库添加为组件依赖 # 假设 libswiftCore.a 等库已放置在此目录 set(LIBRARIES swiftCore SwiftOnoneSupport) foreach(lib ${LIBRARIES}) add_library(${lib} STATIC IMPORTED GLOBAL) set_target_properties(${lib} PROPERTIES IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/lib${lib}.a ) # 将这些库添加到全局的链接依赖中 set(EXTRA_LINK_LIBRARIES ${EXTRA_LINK_LIBRARIES} ${lib} CACHE INTERNAL ) endforeach()4.5 编译、烧录与监控配置好之后就可以使用 ESP-IDF 的标准流程进行构建。cd ~/embedded-swift-xiao/swift-blink # 设置目标芯片 idf.py set-target esp32c6 # 配置项目可以 menuconfig 进行详细配置这里用默认 idf.py menuconfig # 可选确保串口、分区表等配置正确 # 编译 idf.py build如果一切顺利build目录下会生成swift-blink.bin等固件文件。接下来连接你的 XIAO-C6 开发板到电脑确认串口端口如/dev/ttyUSB0。# 烧录固件 idf.py -p /dev/ttyUSB0 flash # 监控串口输出 idf.py -p /dev/ttyUSB0 monitor按下板子的复位键你应该能看到 LED 开始闪烁。串口监视器中如果实现了print的重定向则能看到 “Swift Blink Started!” 的输出。5. 深入实践解决现实世界的问题让 LED 闪烁只是第一步。在实际项目中你会遇到更多挑战。本章节我们探讨几个关键问题的解决方案。5.1 内存管理ARC 在无操作系统的环境Swift 使用自动引用计数ARC来管理内存。在 macOS/iOS 上这由 Objective-C 运行时和 Swift 运行时共同协作。在嵌入式无 OS 环境下我们需要一个精简的 ARC 运行时实现。好消息是为-none目标编译的 Swift 运行时库已经包含了必要的 ARC 逻辑如swift_retain,swift_release。但你需要确保堆分配器Swift 对象的分配需要底层提供堆内存。你需要实现或提供一个malloc和free的实现。通常可以使用编译器自带的libc精简实现如newlib或picolibc或者使用 RTOS 提供的内存管理函数。在 ESP-IDF 中可以使用heap_caps_malloc等函数并需要通过桥接提供。避免循环引用在没有像 iOS 那样的弱引用自动置零机制的简化运行时中循环引用可能导致内存泄漏。在嵌入式 Swift 中需要格外小心地使用unowned或手动打破循环。初始堆大小需要在链接脚本swift.ld或 ESP-IDF 的sdkconfig中正确设置堆内存的起始地址和大小确保足够 Swift 运行时使用。5.2 并发与任务Swift Concurrency 的困境Swift 5.5 引入的结构化并发async/await是其现代并发模型的核心。然而在典型的嵌入式 RTOS如 FreeRTOS环境中直接使用原生的 Swift Concurrency 运行时是非常困难的因为它依赖一个全局的协作式线程池和复杂的调度器。当前实践建议避免使用async/await在嵌入式目标上最稳妥的方式是暂时不使用标准的 Swift Concurrency。编译器可能无法为-none目标生成正确的并发运行时代码。使用 RTOS 的任务原语通过桥接调用 FreeRTOS 的xTaskCreate等函数来创建任务。在 Swift 中你可以将任务函数包装在一个普通的 Swift 函数中然后将其函数指针通过convention(c)属性获得传递给 C 函数来创建任务。未来展望社区有项目在探索为嵌入式环境实现一个轻量级的libDispatch或自定义执行器Executor但这尚处于早期阶段。5.3 与外设和协议栈交互控制 GPIO、I2C、SPI 等外设以及使用 Wi-Fi、蓝牙都需要通过 C 桥接层调用 ESP-IDF 提供的 API。最佳实践模式创建 Swift 友好包装层不要在每个 Swift 文件里都直接调用丑陋的 C 函数。建议为每个主要功能模块如 GPIO、I2C、Wi-Fi创建一个 Swift 包装类或结构体。// GPIO.swift import Bridge struct GPIO { let number: UInt32 init(_ number: UInt32) { self.number number // 调用 C 函数进行初始化配置例如设置为输出模式 gpio_reset_pin(gpio_num_t(number)) gpio_set_direction(gpio_num_t(number), GPIO_MODE_OUTPUT) } func set(high: Bool) { bridge_gpio_set_level(gpio_num_t(number), high ? 1 : 0) } func toggle() { // 需要先读取当前状态这里省略读取逻辑 // ... } } // 使用 let led GPIO(2) led.set(high: true)错误处理ESP-IDF 的 API 通常返回esp_err_t错误码。可以在 Swift 包装层中将其转换为 Swift 的Result类型或抛出Error使 Swift 侧的调用更符合语言习惯。资源管理对于需要“打开-关闭”的资源如 SPI 总线句柄可以利用 Swift 的deinit来自动释放确保资源安全。5.4 调试与日志输出调试是嵌入式开发的一大难点。对于 Swift 嵌入式项目日志重定向实现一个 C 函数void swift_printf(const char* fmt, ...)它使用esp_rom_printf或vprintf输出到串口。然后在 Swift 中你可以尝试覆盖默认的_swift_stdlib_printf函数指针如果运行时允许或者更简单地创建一个自定义的print函数来调用这个 C 函数。GDB 调试理论上你可以使用riscv32-esp-elf-gdb配合 OpenOCD 或 ESP-Prog 进行源码级调试。但需要确保编译时包含了调试符号-g。挑战在于GDB 对 Swift 符号和语言特性的支持在嵌入式目标上可能不完整。更实际的做法可能是混合调试在 C 桥接函数中设置断点或者通过大量打印日志来定位问题。Panic 处理Swift 运行时发生不可恢复错误如强制解包nil时会触发trap。你需要实现一个自定义的swift::fatalError处理函数让它将错误信息输出到串口并可能重启系统而不是陷入死循环。6. 项目优化与进阶思考当你的 Swift 嵌入式项目跑起来后接下来自然会考虑优化和扩展。6.1 代码大小与性能优化Swift 生成的代码体积通常比 C 大这是其安全性和抽象性带来的代价。优化策略包括编译器优化等级使用-Osize优化大小或-O优化速度进行编译。-Ounchecked可以禁用一些安全检查以获得性能但会牺牲安全性。链接时优化 (LTO)如果工具链支持启用 LTO 可以跨模块优化有效减少二进制体积。避免使用泛型特化爆炸过度使用泛型特别是为大量不同类型生成特化代码会显著增加体积。在嵌入式环境中要谨慎使用。审查导入的库确保只链接了真正需要的 Swift 运行时库。通过swiftc的-print-target-info和链接映射文件来分析体积构成。6.2 与现有 C/CPP 组件共存一个现实的项目很少完全用 Swift 重写。更常见的场景是核心算法或业务逻辑用 Swift 编写而复杂的设备驱动、协议栈或性能关键路径仍用 C/C。CMake 可以很好地管理这种混合项目。将 Swift 代码编译成一个静态库.a文件然后在主项目的 CMake 中将其与其他的 C/C 组件一起链接。确保在链接顺序上Swift 运行时库放在所有 Swift 模块之后、标准 C 库之前。6.3 探索更成熟的框架手动搭建整个工具链和构建系统是学习的好方法但不利于团队协作和项目维护。可以关注以下方向Yocto/OpenEmbedded 层有人为 Swift 创建了 Yocto 的 meta-layer可以将其集成到嵌入式 Linux 系统的构建中。这对于运行 Linux 的嵌入式平台如 Raspberry Pi是更标准的方式。Zephyr RTOS 支持Zephyr 项目对现代语言工具链的支持较好有社区在探索将 Swift 作为 Zephyr 的应用语言之一这可能提供更统一的开发体验。VSCode 开发环境配置 VSCode 的C/C和Swift插件实现代码补全、跳转和构建任务集成能极大提升开发效率。6.4 评估适用场景经过一番实践我们需要冷静评估 Swift 在嵌入式开发中的定位优势代码表达力强、安全性高内存安全、强制错误处理、开发效率高特别是对于复杂业务逻辑、易于维护。适合作为应用层逻辑的实现语言。劣势二进制体积大、运行时开销相对较高、对现有生态驱动、RTOS依赖桥接、调试工具链不成熟、社区资源匮乏。适用场景资源相对充裕的物联网设备ESP32-S3、C6 等、快速原型开发、对代码安全性和可维护性要求极高的产品、以及作为 Swift 开发者向硬件领域探索的桥梁。在我个人看来将 Swift 用于 XIAO-C6 这类项目目前更像是一种“技术探险”和“概念验证”。它证明了可行性并展示了现代语言在嵌入式领域的潜力。但对于量产级、对成本和资源有严苛要求的项目C 和 Rust 仍然是更稳妥的选择。不过随着工具链的完善和社区的成长Swift 在未来或许能在特定的嵌入式细分市场找到一席之地。至少这个过程本身对于理解编译、链接、运行时和语言设计是一次绝佳的学习机会。