如果你做嵌入式开发这几年还没被 CCS 折腾过要么是你用的工程还不够大要么就是你刚好跳过了那些最让人抓狂的卡顿场景。CCS 这几个字母在不同领域代表的东西不少但对我们这行来说绝大多数时候指的是 TI 的 Code Composer Studio就是那个跑 CC2642、MSP430、C2000 都绕不开的 Eclipse 系 IDE。我今天要聊的就是围绕 CCS 做一整轮性能优化的思路和实操。早些年我用 CCS 编译一个稍大一点的无线 SoC 工程动不动要等好几分钟启动软件还要再卡半分钟索引一跑 CPU 直接满载那段时间真是被磨得没脾气。后来花了不少时间研究它的构建链路、JVM 配置、调试器连接参数才慢慢把整套流程理顺。这篇文章适合那些已经在用 CCS、但明显感觉到启动慢、编译慢、调试时不时卡一下的工程师。我不会只丢几个参数就完事会把每一步的为什么讲清楚这样你拿到自己的工程上也能举一反三。1. 先理清思路CCS性能优化到底在优化什么很多人一说 CCS 优化第一反应就是把编译器优化等级调高一点其实这是个误区。编译器优化等级解决的是最终固件的执行效率和 IDE 本身卡不卡、编译快不快完全是两码事。真正让日常开发体验变差的往往集中在下面几个环节IDE 启动时的工作区加载与索引重建、工程编译链接的构建链路、调试器连接和镜像下载的速度以及编辑器在写代码时的响应能力。这四个维度相互独立优化手段也完全不同要分头解决。1.1 把痛点拆成四个维度来看第一个痛点是启动。CCS 底层是 EclipseJVM 起来、工作区扫描、插件加载、索引初始化这一套流程在机械硬盘上能慢到你怀疑人生。即使到了 SSD 时代如果工作区里塞了几十个工程启动时仍然要花很长时间因为 IDE 会把很多工程一起做静态分析。第二个痛点是构建。这一块最直观点一下 Build然后就开始盯着进度条。构建慢的原因很多头文件搜索路径太宽、并行编译没开、增量编译失效、链接器脚本配置不合理等等。第三个痛点是调试和烧写。很多项目天天要改固件、下载调试验证如果每次烧写都需要几十秒甚至一分钟一天下来浪费的时间相当可观。第四个痛点是编辑器响应。跳转慢、代码提示卡、打开大文件卡死这些和索引器的索引策略、内容辅助的触发配置都有关系。这四个维度就像是汽车的四个轮子哪个轮子瘪了整车开起来都别扭。所以做 CCS 性能优化我一定会建议先列表梳理看自己最常被卡在哪一步。如果你每天只 Build 一次那编译慢一点也许还能忍但如果你一天要 Build 十几次那并行构建和增量编译就是第一优先级。1.2 为什么我优先动构建配置而不是换电脑经常有人问我能不能靠换一台更好配置的电脑来解决 CCS 卡顿。我的观点是换电脑有用但不是最优解。CCS 是 Eclipse 系JVM 堆内存、索引策略、构建并行度这些软件层面的限制往往比硬件更能决定体验。你给 Eclipse 分配 512MB 堆内存哪怕电脑有 64GB 内存它一样会频繁 GC、一样卡。先把软件配置调到合理值再考虑硬件这才是正确顺序。另外还要强调的是性能优化的核心原则之一是“保持工程可复现、可增量”。我见过一些人为了追求编译速度把整个 SDK 的头文件路径全塞进 include或者用外部脚本在每次 Build 之前强制清理全部产物结果确实全量编译很快但改一个文件就要全量重编体验反而更糟。优化要做的是减少重复劳动不是推翻 IDE 的增量机制。2. 开工前的底座安装、工作区与启动优化这部分很多教程不会详细讲但它其实是整个优化链条里性价比最高的一环。你每天打开 CCS 的第一眼体验就取决于安装方式和工作区摆放是否合理。我见过不少项目组几十个人共用同一个拷贝过来的工作区里面什么杂七杂八的工程都有每个人打开都要加载一堆别人留下的插件和配置不卡才怪。2.1 版本选择与安装路径的一些细节先看版本。TI 每两三年会更新一个大版本新版通常意味着更新的编译器、更好的 Cortex-M 支持以及更快的启动逻辑。但也不要一味追新。如果你当前工程的 SDK 托管的编译器版本和 IDE 自带的不兼容那升级的成本会很高。比较稳妥的做法是下载对应 SDK 版本推荐的 CCS 版本同时保留旧版本以兼容老工程。比如用 CC2642 SDK 的人可能同时装了 CCS 12.x 和 CCS 20.x就是怕老工程迁移有坑。安装路径这部分务必记住两个原则路径不要带中文和空格CCS 的安装目录、SDK 目录、工作区目录三者尽量分开。原因很简单Eclipse 系工具对带空格路径的处理偶尔会出幺蛾子虽然新版本基本都支持但没必要在这种地方赌。分开目录还有一个好处是杀毒软件可以针对性地排除扫描避免每次读写工程文件时都被实时监控拖慢。我实测过给 CCS 安装目录和工作区目录加白名单之后构建速度至少提升了 20%尤其工程文件多的时候更明显。不同杀毒软件的排除设置入口不一样但基本都是找到“排除文件夹”或“排除进程”把ccs和workspace两个目录加进去就行。2.2 调大 JVM 堆内存减少启动卡死和构建崩溃Eclipse 系 IDE 跑在 JVM 之上CCS 也不例外。JVM 默认堆内存往往偏小当工作区较大、索引较多时堆内存不够用就会频繁触发垃圾回收表现为界面时不时的“假死”严重的还会直接抛出Java heap space或OutOfMemory错误Build 到一半崩溃。这个问题的解决方法很直接找到 CCS 安装目录下的ccs.ini文件修改 JVM 参数。ccs.ini通常位于CCS安装目录/ccs/eclipse/ccs.ini。打开后找到-Xms和-Xmx这两行一般老版本默认只有-Xms256m-Xmx可能根本没写。我常用的配置是这样-Xms512m -Xmx2048m -XX:UseG1GC -XX:MaxPermSize512m注意不同版本对MaxPermSize的支持不同较新版本已经不需要这行加了也不影响。-Xms表示 JVM 启动时分配的初始堆大小-Xmx是最大堆上限。如果机器内存足够建议把-Xmx设置到 2048MB 以上但不要超过物理内存的一半否则操作系统本身也会卡。修改完重启 CCS然后用菜单 Help About Code Composer Studio Installation Details Configuration 查看当前 -vmargs 是否生效也可以直接看启动日志里的 JVM 参数。如果是 64 位系统但跑在 32 位 JVM 上那堆内存上限会被操作系统限制这种情况建议直接换 64 位安装包。2.3 工作区收纳法则别什么都往一个工作区塞工作区设计看似是个习惯问题实际上对性能影响很大。Eclipse 的索引器默认会扫描工作区里的所有工程哪怕你用的只是其中一个其他暂时不用的工程也会被纳入索引范围。工程越多后台 CPU 越高代码跳转和补全就越慢。我的做法是不同产品线、不同 SDK 版本用独立工作区工作区里只保留当前阶段真正在改的工程同一个 SDK 相关的公共库工程可以用 Import 的方式链接进来但要用Linked Folder或路径变量方式不要全部拷贝复制。如果实在有很多工程要留作参考可以在工程上右键选择 Close Project关闭后索引器会跳过这些工程资源占用大幅下降。等以后要用了再打开损失一点点重新索引的时间换来平时开发过程的流畅这笔账很划算。3. 重头戏编译与链接的提速方案编译速度直接影响你一天的工作节奏。这一课时我花了最多精力去研究因为拿到一个新工程之后能不能高效迭代很大程度上取决于构建配置是否合理。老规矩先说思路再说具体操作方法。3.1 编译器优化等级怎么选才划算CCS 支持两种主流编译器TI 自研的 TI CGT 编译器以及较新版本中越来越常用的 TI Arm Clang 编译器。不同编译器对应的优化选项略有差别但核心思想是一致的Debug 配置用-O0保调试体验Release 配置用-O2或-Oz平衡性能和代码大小。我在无线 SoC 项目里的经验是日常调试一律用 Debug 配置编译器优化等级保持-O0这样设置断点、单步执行时变量值才能准确看到。到了需要评估真实性能或准备出固件的时候再切到 Release 配置把优化等级调高。如果 Flash 空间告急用-Oz这类偏向代码大小的选项通常比手动删代码更省事。你可以在工程属性的 “C/C Build Settings Tool Settings” 下找到 Optimization Level 选项也可以直接在命令行编译参数里覆盖默认值。这里还有一个容易踩的坑全局一把梭把优化等级调高未必是好事。某些场景下-O3会导致代码体积暴涨间接增加 I-Cache 压力反而拖慢执行速度。更合理的做法是针对热点模块单独设置优化等级比如无线协议栈处理、射频驱动这类对时间敏感的部分用-O2其他稳定代码保持-O0或-Os。CCS 支持按源文件目录设置不同的编译参数实际上不少 SDK 里已经这么做了。3.2 并行构建、增量编译和预编译头文件并行构建是提升编译速度最直接的手段。现代 CPU 核心数都不少但 CCS 默认的并行度未必调得很激进。你可以在工程属性里的 “C/C Build Behaviour” 或构建配置中找到并行任务数的设置把它从默认值改成和你 CPU 逻辑线程数基本持平比如 8 核 CPU 就填 8。命令行构建时也可以用gmake -j8这类方式指定。增量编译的逻辑是只有发生变更的文件才需要重新编译其他文件直接复用目标文件。但增量编译经常会因为时间戳问题失效。常见的原因包括工程从 Git 仓库拉下来时所有文件的时间戳都被更新或者外部脚本、软件工具修改了源文件但没动内容IDE 会误判为“文件已变更”而重新编译。解决思路有两个一是尽量用 checkout 时保留原始时间戳的方式二是在构建前关闭不必要的自动刷新减少误判。CCS 的 “C/C Build Refresh Policy” 里可以设置外部修改的刷新策略这里建议选择仅在构建前手动刷新避免后台频繁扫描目录。预编译头文件PCH是另一个容易被忽略的提速工具。如果你的工程里有大量公共头文件比如 CMSIS、TI HAL 库、蓝牙协议栈接口层等每次编译都要解析一遍耗时非常可观。使用 PCH 可以将这些公共头文件提前编译成缓存后续编译单元直接复用理论上可以提升 20%~30% 的编译速度。CCS 里的配置路径大致是工程属性 - C/C Build - Settings - Precompiled Headers指定一个稳定的公共头文件入口即可。不过 PCH 也不是没有代价它更吃内存而且一旦公共头文件发生变化需要重新生成缓存所以一般只对稳定的大型 SDK 工程开启频繁迭代的早期项目反而收益不大。3.3 Linker 与内存布局里藏着的隐形收益看到标题你可能会奇怪Linker 和编译速度有什么关系其实链接过程在整个构建中占比不小尤其当你的工程依赖大量静态库时链接器需要处理大量的符号解析、重定位和镜像生成。优化链接阶段重点在于减少链接器的工作量。第一合理设置链接器脚本.cmd文件。TI 的平台通常用链接器命令文件来定义内存区域和段分配你可以把代码段、只读数据段、可写数据段放到正确的 Flash/RAM 区域并尽量减少跨区域的 padding。如果段分配不合理生成的固件镜像里会夹带很多空洞bin 文件变大烧写时间也随之变长。第二开启 “去掉未使用段” 的链接器选项。TI CGT 里有--remove_unusedonClang 系对应-Wl,--gc-sections这类开关可以把没有被引用的函数和数据从最终镜像里剔除。对 Flash 空间紧张、烧写速度慢的芯片来说收益非常明显。第三定期看 map 文件。工程构建后生成的.map文件里记录了每个段的大小、地址和所属对象文件分析 map 能准确找到哪些模块占用了大头然后决定是优化算法还是简化库依赖。这一步虽然不能直接加速编译但能减少固件体积、缩短烧写时间是性能优化链条里不可缺的一环。4. 别忽视的日常链路索引、编辑与代码导航很多人的 CCS 卡顿集中在写代码阶段输入一半代码提示迟迟不弹点一下函数跳转转圈转半天打开一个 SDK 源码文件编辑器直接无响应。这些问题通常不来自编译器而是来自索引器。索引是 Eclipse 系 IDE 的看家功能也是一把双刃剑索引全的时候跳转精准但 CPU 和内存开销也大索引懒的时候界面倒是流畅但代码导航基本废了。这里的关键在于找到一个平衡点。4.1 索引器设置全量索引还是按需索引CCS 的索引器控制面板在 Window Preferences C/C Indexer。默认情况下会索引整个工作区包括所有打开和关闭的工程。这种模式下跳转最准确但代价也最高。我更推荐配置为“Index only selected projects”或“Index only active build configuration”让索引器只覆盖当前工程和当前使用的构建配置。特别是那种一个工作区挂多个工程的情况索引范围缩小后编辑器响应速度快得不是一点半点。还有一个选项是取消“Automatically update the index”或者把它改成手动触发更新。很多人不知道当你在外部用别的编辑器或脚本改文件时Eclipse 会在后台重新索引这个过程相当吃 CPU。改成手动索引后需要跳转时按 CtrlShiftR 这类快捷键前随手刷新一下即可体验反而更可控。当然这一切的前提是你用的是 IDE 内置的代码导航如果后续用到 VSCode 做主力编辑器索引策略又是另一套玩法这个我放到后面单独讲。4.2 大文件与 SDK 源码打开卡顿的处理SDK 里有些头文件和源码文件非常大比如无线协议栈的配置头文件可能有近万行。CCS 默认的编辑器在这种文件上会明显变卡因为它在做语法高亮、代码折叠、自动匹配等多重解析。我的处理技巧是能不看的不看能拆分的不硬撑。对于确实需要频繁打开的大文件可以尝试在 Preferences General Editors Text Editors 里关闭 “Show whitespace characters”、降低 “Number of displayed lines” 限制或者直接把光标闪烁关了这些都有轻微改善。更有效的方式是减少全局搜索的频率。C/C 工程的 Search 默认会全目录扫描如果你在 SDK 根目录下搜索某个符号可能等上四五秒甚至更久。建议把 Search 的 Scope 从 Workspace 改成 Selected Resources 或 Project并且在搜索时用文件类型过滤去掉.dat、.bin等二进制文件。另外不要在每次需要查 API 时都去全局搜直接 F3 跳转到定义通常更快。4.3 文件时间戳变化导致的重复编译问题这个坑很有代表性。你在 Windows 下用资源管理器、Beyond Compare 之类的外部工具把源码文件复制回工程或者从 Git 切分支然后回到 CCS 点 Build结果发现所有文件都被重新编译了一遍。原因就是文件时间戳变了增量构建认为文件已修改。这并不是 CCS 的 bug而是增量构建的基本判断逻辑只是外部工具的常见行为恰好会触发它。解决的办法有几个按优先级排列第一优先在 CCS 内部执行刷新操作外部工具改完后在 Project Explorer 里选中工程按 F5让 IDE 感知到更新再检查时间戳第二如果不是必须保留原始时间戳建议在刷新之后一键 Build让它先吃一次全量重编的亏之后就不再重复了第三在 Refresh Policy 中关闭持续自动刷新改成构建前自动刷新。如果你的团队经常多人协作改代码建议约定一个统一流程拉取代码后先在 CCS 里 Refresh再 Build不要直接点构建按钮。5. 调试、下载与烧写的性能优化调试和烧写虽然不是每次写代码都要做的操作但一旦慢起来那种“改一行代码—编译—烧写—复现—再改”的循环会变得非常痛苦。实际项目中很多时间就是这么一点一点被吃掉的。这个模块的核心目标是把从代码修改到目标板运行新固件的时间压缩到最短。5.1 调试器连接与镜像下载提速如果你用 XDS110 这类 TI 调试器连接速度受几个因素影响驱动的安装与固件版本、USB 接口的稳定性、Target Configuration 里的 JTAG/SWD 时钟速率、以及每次下载时是否做了不必要的 Flash 擦除。先检查驱动。XDS110 的固件可以通过 TI 的调试器固件升级工具或 CCS 自带的更新机制进行升级固件太旧时连接速度会明显跟不上。再检查 .ccxml 文件CCS 会自动为每个目标板生成一个 Target Configuration里面有一个连接速率参数。我常用的 CC2642 目标板可以把速率设在 2MHz 到 5MHz不要盲目调太高速率太高反而会导致连接不稳定、烧写出错来回折腾更浪费时间。下载方式上面也有讲究。日常调试时尽可能用 Debug 而不是每次 Load Program。Debug 模式会通过调试器加载符号信息和应用程序到目标板更适合频繁改代码验证而 Load Program 更多用于烧写 Flash 后断电重启的场景。频繁 Load Program 不仅慢还会增加 Flash 的擦写次数。很多老工程师会直接给 CCS 配一个快捷键一键 Debug 而不是反复 Build 后再 Load。5.2 调试会话加速的实用技巧进入调试会话后卡顿通常来自调试器和 IDE 之间的高频交互。最常见的坑是 Watch 窗口和表达式求值。你添加一个变量到 Watch 窗口后调试器每次暂停时都要去目标板上读取变量值如果变量在多级指针或复杂结构体上读取耗时更久。这时候界面会觉得“卡住了”。建议把不常用的表达式从 Watch 窗口移除只留当前关注的那几个如果只是临时想看某个变量的值用鼠标悬停即可不用挂到 Watch 里。断点数量也要控制。Cortex-M 处理器的硬件断点数量通常有限比如只有 4~8 个硬件比较器。当你打了很多断点时调试器可能用软件断点代替软件断点的实现靠改写指令效率低且容易污染 Flash 内容。我的习惯是一个调试周期内只保留 2~3 个关键断点先把主流程走通再逐步缩小范围。打印日志也是加速调试的利器。很多时候你在代码里塞了一堆printf或串口输出逻辑但串口初始化、等待发送完成的延时都会影响实时行为。如果芯片支持 SWO/ITM可以直接用 SWO 输出调试日志不影响 GPIO 和串口资源调试体验非常好。CCS 对 SWO 的支持比较成熟只需要在 Target Configuration 里开启对应的 trace 功能再用 ITM 端口输出字符串即可。最后提一下 HardFault 的定位。程序跑飞或者进入异常时如果在调试器里能看到 PC 指针和 LR 寄存器可以直接用 CCS 的 Fault Analyzer 或手动查看CFSR、HFSR这些异常状态寄存器能很快定位是访问越界、除零还是栈溢出。很多新手遇到 HardFault 就急着重新烧写反复试错其实先花一分钟看寄存器往往比盲试高效得多。5.3 批量烧写的效率优化思路到了小批量生产或者联调阶段可能一天要烧写几十块板子。这时再用 CCS 的 GUI 一个个操作就太慢了而且每开一次 CCS 都要等启动和加载工程。推荐两条路第一条是在 CCS 里通过 Target Configuration 生成一个可复用的调试配置然后用命令行工具如dslite执行脚本化烧写把目标板型号、固件路径、烧写选项都写到一个脚本里第二条是对 CC26xx 这类无线 SoC直接用 TI 的 SmartRF Flash Programmer 2 或 UniFlash它们比完整 CCS 轻量很多界面启动快、烧写流程也更专注。实际项目中我更常用 UniFlash 命令行来批量烧写因为脚本可以嵌入到产测流程里GUI 只在手动处理单板时用。6. 进阶玩法把CCS嵌入到现代工作流里现在很多嵌入式工程师已经不再每天只面对 IDE 了。代码用 Git 管理文档在浏览器里看CI 服务器上还要自动构建固件。这个时候你会发现CCS 作为一个重型 GUI 工具在一些场景下并不适合直接跑在服务或无界面环境里。因此一套“CCS 现代工具链”的组合打法就显得特别有用了。6.1 VSCode CCS 的协作模式关于 VSCode CCS 的搭配网上问的人非常多。我自己的使用体验是VSCode 负责看代码、写代码、做代码评审CCS 负责真正干编译和调试烧写的活。为什么这么分工因为 VSCode 基于轻量级的语言服务协议做代码补全、跳转、全局搜索时响应极快尤其处理大型 SDK 时的体感比 Eclipse 系 IDE 好得多而 CCS 对 TI 芯片、调试器、SDK 工程的支持是最完整的编译和调试环节交给它最稳。在实际操作中我会在 VSCode 里直接打开工程源码目录配好.vscode/c_cpp_properties.json里的 includePath让它能正确识别头文件然后代码编辑全在 VSCode 完成。需要编译时切到命令行调用 CCS 的构建引擎。CCS 自带gmake工具可以在命令行里直接编译工程命令类似这样cd workspace/project CCS安装路径/ccs/utils/bin/gmake -j8 all如果需要烧写或调试再打开 CCS 加载工程按 F11 一次启动调试会话。这种模式下你在 VSCode 里写代码期间不会感受到任何 IDE 卡顿只有到需要验证时才打开 CCS体验会清爽很多。对于团队协作还可以约定把所有编译参数固化到构建脚本里大家统一走命令行构建避免不同人 IDE 配置不一致导致的“在我机器上能编过”问题。6.2 构建后自动化与CI集成构建完成后的处理步骤很多人还在手动操作导出 hex/bin、记录版本号、拷贝到服务器、打包上传。这些步骤完全可以做成 post-build 脚本。在工程属性里找到 “C/C Build Settings Build Steps”在 Post-build steps 里可以直接写命令。比如用 TI 的hex430、tiarmhex工具生成 hex 文件或者用批处理把生成的.out文件重命名成带版本号的文件。再配合 Git 提交号自动写入固件版本这样每次拿到一个固件就能准确对应源码版本调问题效率大幅提升。在无人值守的编译服务器上CCS 也支持无头构建模式。TI 官方文档里提到可以给 CCS 传递-noSplash、-application org.eclipse.cdt.managedbuilder.core.headlessbuild之类的参数在命令行里完成工程的导入、编译和导出整个过程不启动图形界面。虽然配置起来比 IDE 内点几下要繁琐但对需要每日构建、自动回归的团队来说这套机制非常值得投入因为它能保证每次构建环境都是干净、一致的。7. 常见问题速查与避坑心得这部分列几个我在实际项目里高频踩到的坑以及对应的排查思路。表格可以直接当速查手册用。需要说明的是下面这些方法我都按通用场景验证过但你的 CCS 版本、SDK 版本、芯片型号不同细节可能会有差异遇到问题以自带的 log 文件为准。7.1 高频问题排查表问题现象可能原因解决思路CCS 启动非常慢甚至卡在启动画面工作区过大、索引太多、JVM 堆内存过小精简工作区关闭不用的工程修改 ccs.ini 提高 -Xmx构建时提示文件正被占用或无法删除杀毒软件实时扫描、上次构建进程未退出给 CCS 目录和工作区加白名单杀掉残留的 gmake/编译器进程编译到一半报 Java heap spaceJVM 堆内存不足修改 ccs.ini 中 -Xmx并确认 64 位 JVM 生效烧写失败或连接不稳定JTAG 速率过高、XDS110 固件太旧、USB 供电不足降低连接速率、更新调试器固件、换 USB 口或加 HUB 供电代码跳转找不到符号索引范围受限或索引未更新调整索引器配置按需刷新索引检查 include 路径点了 Build 但所有文件都重新编译文件时间戳变化、外部工具刷新导致增量失效在 CCS 内刷新工程调整 Refresh Policy尽量保持时间戳稳定Debug 时 Watch 窗口刷新卡顿调试器频繁读取复杂表达式减少 Watch 表达式数量改用悬停查看HardFault 难以定位代码访问越界、栈溢出、外设配置错误查看 CFSR/HFSR 寄存器、分析调用栈结合 Fault Analyzer 逐步定位7.2 我拿到新工程后必做的 5 件事第一件事清理工作区。把不相关的工程全部 Close只保留当前要用的顺手把 SDK 路径变量检查一遍确保不是每个人机器上都有一份硬编码路径。第二件事调构建参数。并行任务数开满优化等级按当前阶段选择Debug 用-O0Release 再谈性能。第三件事检查 include 路径。把头文件搜索路径精简到最少同时避免把 SDK 根目录整个塞进去。第四件事验证烧写和调试链路。先跑一次完整的 Debug 烧写流程确认 Target Configuration 正确、连接速率合理不要等到快下班了才发现调试器固件不对连不上板子。第五件事配置好 post-build 脚本。哪怕只写一行生成 hex 的命令也比每次手动导出强。最后再分享一个小经验CCS 的性能优化核心思路其实是尽量少让它干“不需要干的事”。编译并行、索引精简、工作区收纳、命令行化操作这些都是减少 IDE 额外负担的办法。真正到了硬件层面SSD、大内存、高主频 CPU 对 Eclipse 系的提升依然是最直接的但只有先把软件配置调顺那些硬件投入才能真正花在刀刃上。踩过几次坑之后你会发现把工具链打磨顺了挤出来的时间远比加一天班多得多。