结论：本周先固定一组可重复的用户操作，再用 Swift Executors instrument 观察任务与执行器轨迹；把它当作缩小排查范围的工具，不要把轨迹截图当成根因证明。如果你正在追查 Swift Task、Main Actor 或执行器行为异常，这套流程适用于需要比较修改前后行为的 iOS 与 macOS 项目。
你会按时间线完成准备、录制、读轨迹、定位线索与复测。关键是先区分“任务在哪里执行”和“用户为什么看到卡顿”：两者相关时值得深入检查，但不能直接画等号。
最后更新于 2026 年 10 月 27 日；版本与功能信息核对自 Apple 的 Xcode 27 发布说明、系统要求及 Instruments 官方资料。
SECTION 01 先把“卡顿”变成可复现的观察目标
“页面卡”“任务跑得慢”还不足以开始分析。先选一个具体操作作为复现入口，例如打开某个页面、滚动列表或触发一项后台处理，然后记下应用实际表现、出现问题的阶段，以及你希望轨迹回答的问题。
接着选定一个主要观察目标：
- 任务生命周期：关注相关 Swift Task 在什么时候出现、何时结束，或复现操作附近是否存在任务活动。
- 执行器活动：关注任务是否在 Main Actor、协作线程池或自定义执行器上运行。
- 主执行路径：关注用户可见的卡顿是否与 Main Actor 上的工作时间重合；必要时再用其他 Instruments 工具检查 CPU 或系统层活动。
这一步能避免把不同层次混为一谈。任务是并发工作的活动单位；执行器关系到任务在哪里执行；应用症状则是你从界面或产品行为中观察到的现象。三者可以互相印证，却不能互相替代。Apple 的 Xcode 27 发布说明介绍了 Swift Executors instrument 的轨迹范围，并指出旧系统上的执行器名称可能显示为 “Unknown executor”。
SECTION 02 第一步：确认 Xcode、工具和目标环境
录制前，先检查分析工具与目标应用是否处在兼容环境中。Apple 的系统要求页面列出了 Xcode 版本对应的 macOS、SDK 与设备支持范围。当前页面列出的 Xcode 27 RC 要求为 macOS Tahoe 26.6 或更新版本，并注明 Xcode 27 仅能安装和运行在 Apple silicon Mac 上；后续版本或适用范围可能变化，执行前应以页面最新内容为准。
| 检查项 | 你需要核对什么 | 不匹配时的影响 |
|---|---|---|
| Xcode 与 macOS | 当前 Xcode 的系统要求、安装版本和选中的开发者目录 | 工具可能无法启动，或无法使用目标版本提供的分析能力 |
| Instruments 与目标系统 | 目标设备或模拟器运行的系统版本，以及轨迹支持范围 | 执行器名称或可见信息可能不完整 |
| 应用与符号 | 能启动的目标应用、对应构建产物及可用的调试符号 | 可能能看到活动，却难以把线索对应回代码 |
不要把“项目构建成功”当作“分析环境已就绪”。确认你启动的是计划分析的应用版本，并记下 scheme、构建配置、目标设备或模拟器、Xcode 版本与系统版本。
Apple 的 Xcode 命令行工具参考介绍了 xctrace，可用于录制、导入、导出和符号化 Instruments .trace 文件。还要注意，命令行工具安装说明指出 xcodebuild 和 xctrace 随完整 Xcode 提供，而不是随独立的 Command Line Tools 包提供；如果你的流程依赖这些命令，先确认完整 Xcode 已安装并设为当前开发者目录。
SECTION 03 第二步：每次录制只对应一组清晰的复现步骤
准备好环境后，从 Xcode 对目标应用执行 Profile，在 Instruments 中选择 Swift Executors instrument，再开始录制。具体操作路径和模板显示可能随版本调整；Apple 的 WWDC 26 Instruments 分析演示展示了相关轨迹及诊断流程，可用来核对目标版本的界面与能力。
正式操作前先确定复现步骤：打开哪个页面、执行哪个动作、何时停止。录制期间只按这组步骤操作，并在问题再次出现或步骤完成后停止。若一次录制中既切换页面又触发多个后台动作，轨迹事件会更难与具体行为对应；这种情况下，优先拆成多次录制，而不是依靠猜测解释复杂轨迹。
每次保存轨迹时，把运行上下文一并记下，例如：
- 项目版本或提交标识，以及应用构建配置；
- Xcode、macOS 和目标系统版本；
- 复现操作和观察到的产品表现；
- 轨迹文件名，以及此次录制相对基线的差异。
这些记录能让你之后重新打开同一份 .trace，并比较相同操作下的活动。若团队通过命令行管理轨迹，应先查阅 xctrace 当前帮助与 Apple 的工具参考，不要照搬其他版本的命令参数。
SECTION 04 第三步：怎样读出 Main Actor 与执行器线索？
先在时间轴上找到复现操作对应的区间，再查看 Swift Executors instrument 中的执行器轨迹。Xcode 27 发布说明列出 Cooperative Thread Pool、Main Actor，以及符合 TaskExecutor 或 SerialExecutor 的自定义执行器；WWDC 26 的 Instruments 演示也展示了如何观察 Main Actor 和全局并发执行器上的任务。
| 轨迹或证据 | 可以帮助你观察 | 不能单独证明 |
|---|---|---|
| Swift Task 活动 | 任务是否在复现时间附近活动，帮助锁定检查时段 | 某个任务必然导致卡顿 |
| Main Actor 轨迹 | 复现期间是否有相关任务在 Main Actor 上执行 | 任务执行时间就是用户感知延迟的全部来源 |
| Cooperative Thread Pool 或自定义执行器 | 任务活动与不同执行器轨迹的对应关系 | 线程池或执行器配置就是唯一根因 |
| 应用表现与其他诊断证据 | 轨迹线索是否与卡顿、CPU 活动或其他现象吻合 | 单凭时间上的重合就能确定因果 |
若你的问题是“哪些任务出现在 Main Actor 上”，就把时间范围缩到复现区间，查看该轨道中的任务活动，再与操作记录对照。Apple 的后台线程分析教程介绍了如何结合 Instruments 检查任务执行上下文与 Main Actor 的关系。
还要留意时间轴的边界：录制开始之前已经排队的任务，可能不会以完整状态出现在轨迹中；旧版目标系统上，执行器名称也可能显示为 “Unknown executor”。因此，轨迹中没显示某个名称，不一定代表对应工作没有发生。遇到不确定的状态，应先确认版本与录制区间，再决定是否补录。
SECTION 05 第四步：让轨迹线索回到代码与产品行为
发现可疑任务后，先提出一个可验证的问题，而不是直接下结论。例如，复现操作发生时，Main Actor 上是否出现了与该功能相关的工作？如果答案是肯定的，再检查对应调用路径、隔离上下文和具体工作内容；如果轨迹显示任务活动与症状不吻合，就转向其他证据。
实际排查时，你可以先检查相关函数是否受 @MainActor 隔离、任务是否继承了创建上下文，以及耗时工作是否需要与界面更新分开处理。这里的检查只是候选方向，不意味着看到 Main Actor 轨迹就应把代码一律移出主执行路径。
当 Swift Executors instrument 无法解释症状时，补充其他诊断证据。Apple 的 WWDC 26 演示将 Swift 并发轨迹与 Time Profiler、System Trace 等工具结合，用于进一步检查执行活动和系统行为；这说明不同工具回答的问题不同，而不是某一张时间轴就能包揽全部诊断。
实际操作可按这个顺序推进：
- 将可疑轨迹区间对应到复现操作，而非只看整段录制。
- 从任务名称、所属执行器及项目代码中寻找可能关联的调用路径。
- 对照应用实际症状，确认时间上的吻合是否稳定出现。
- 若证据不够，缩短或调整复现步骤，或补录其他诊断轨迹。
- 只修改能被当前证据支持的候选代码路径，并记录改动。
例如，Main Actor 上出现任务只是“值得检查”的线索。它可能与界面响应问题有关，也可能并非造成用户症状的关键因素。只有当代码路径、复现表现和轨迹证据能相互对应时，你才有足够依据进入针对性修复。
SECTION 06 第五步：用相同条件复测，而不是凭印象验收
修改后按原来的复现步骤重新录制，并尽可能保持项目版本、构建配置、目标环境与操作一致。比较重点应是可观察行为：原先的可疑轨迹是否仍在同一操作期间出现？应用表现是否发生了与改动预期一致的变化？若不能复现同一条件，前后两份轨迹就不适合直接比较。
验收记录至少保留运行环境、工具版本、复现动作、轨迹文件和修改内容。不要只用“感觉更流畅”作为结论，也不要在缺乏可重复测量方式时写入未定义的性能提升比例。复测的目标是确认修改是否支持你的诊断判断，而不是为了追求一个没有定义的数字。
如果你需要在没有本地 Mac 的情况下重复运行 Instruments 分析，可以比较本地已有环境、临时远程环境与长期自购设备：本地机器不用额外维护远程连接，但可能受硬件与可用时间限制；远程环境能把 Xcode 分析与日常开发机分开，却需要确认系统版本、应用访问方式及项目条件；自购 Mac 更适合长期稳定使用且确实需要本地设备的人。你可以先查看 VPSNIX 的远程 Mac 服务说明，再按预计使用周期核对租赁方案与计费方式。这些选择不代表任何环境必然支持你的具体分析任务，仍应在开始前核对兼容要求。
SECTION 07 常见问题
Swift Executors instrument 里有哪些执行器和任务线索？
它可展示进程中的执行器轨迹，例如 Cooperative Thread Pool、Main Actor 与符合特定协议的自定义执行器，也能帮助你观察相关任务活动。具体轨迹名称、呈现方式与支持范围取决于 Xcode 和目标系统版本；工具给你的是排查线索，并非所有代码执行细节的完整记录。
如何从时间轴定位 Main Actor 上的工作？
选择目标应用并完成录制后，在 Swift Executors 时间轴中定位 Main Actor 轨迹，再把轨迹时间与复现步骤对应起来。如果任务活动和症状同时出现，接着回到源码检查相关调用路径；若无法对应，先核实目标版本、录制区间与符号信息，再决定是否补充其他诊断证据。
轨迹能否单独确定并发问题的代码原因？
不能。轨迹可以把注意力引向值得检查的任务、执行器和时间区间，但不会替你判断代码因果关系，也无法独自解释资源等待或系统阻塞。你需要结合复现操作、代码路径和应用表现验证假设；修改之后，再以相同条件重录，确认结果是否支持你的判断。
使用远程 Mac 做并发分析前要检查什么？
先核对目标系统、工具版本、应用启动条件以及项目所需设备，再确认远程环境能否保存轨迹并让你访问所需文件。能够远程登录不等于已经具备完整分析条件；若问题依赖本地设备或特定硬件，还应先确认测试环境是否满足这些要求。
Swift Executors instrument 适合用来缩小并发问题的观察范围，不适合充当自动根因诊断。若你现有方案受限于开发机无法长期运行、Xcode 分析环境难以复现或本地磁盘空间紧张，可以先评估远程 Mac 是否符合项目的工具与目标环境要求；如果你需要长期稳定的本地设备，或必须使用特定物理接口，自购设备可能更合适。
SECTION 08 常见问题 FAQ
Swift Executors instrument 能看到哪些并发活动？
它可以展示目标进程中可识别的执行器轨迹，例如 Cooperative Thread Pool、Main Actor，以及符合 TaskExecutor 或 SerialExecutor 的自定义执行器；配合 Swift Concurrency 轨迹，可观察相关任务活动。可见名称和数据取决于 Xcode 与目标系统版本，轨迹用于定位可疑时间段，不等于完整记录每条代码路径。
怎么在 Instruments 里找出 Main Actor 上的任务？
录制时选中正确的应用进程，在 Swift Executors 轨迹中找到 Main Actor 对应的轨道，再对照复现操作发生的时间范围检查任务活动。若想确认任务是否与卡顿同时出现，还要结合应用症状和其他诊断轨迹；不要仅凭 Main Actor 上出现任务，就断定该任务是唯一原因。
Swift Executors 的轨迹可以直接证明代码根因吗？
不可以。它记录的执行器与任务活动能给你排查线索，帮助把观察范围缩小到特定时间段或代码路径，但不会自动判定某段代码有错，也不能单独区分计算耗时、资源等待或其他阻塞因素。你需要回到源码、复现步骤和应用行为交叉核对，并在修改后重复录制。
没有本地 Mac，能不能复现 Xcode 并发分析？
可以考虑通过可访问的远程 Mac 环境运行 Xcode 和 Instruments，但先确认该环境的 macOS、Xcode、目标系统与项目要求相符，并验证应用能启动及轨迹可保存。远程桌面连接成功不代表分析环境已经就绪；如果问题依赖本地设备或特定硬件，还需另行确认目标设备与连接条件。