2026 年 iOS PR 流水线在 Mac 云上跑并行 Simulator 测试：并发、destination 矩阵与磁盘队列怎么定

PR 门禁一打开并行 xcodebuild test，办公室里的 Mac mini 池往往先撞上「Simulator 争用 + DerivedData 暴涨 + 队列不可见」三件事。本文写给要把 UI/单测当成可度量 SLA 的读者：先用三条编号拆解误区，再给「本机池 vs 可弹性规格 Mac 云」对照表，随后给出不少于五步的落地顺序、可写进 Runbook 的并发与磁盘阈值，并以 FAQ 说明何时应先读本篇、何时直接打开站内 90 秒 API 开通与 CI 对接或 构建队列与 DerivedData长文。

Mac 云节点上并行运行 iOS Simulator 与 xcodebuild 测试流水线的示意图

本文要点

1. 三类痛点：把 Simulator 当「轻量容器」

多数团队已在 Linux 上跑完静态分析与单测骨架，真正拖慢合并频率的，往往是 macOS 上的 Simulator 级测试。习惯「像管 VPS 一样」用 SSH 管机器的人，最容易在 PR 场景里低估下面三类成本。

  1. 把并行 worker 当成线性扩容：同一台机器上盲目提高 -parallel-testing-enabled 或 fork 多个 destination，会让 CPU 抢占与 I/O 抖动叠加，反而拉长尾延迟；没有「每核可承载的 Simulator 数」这类内部基线，SLA 只能写成口号。
  2. destination 矩阵复制生产「全机型」到每个 PR：全矩阵在发布周有意义，在 PR 门禁里常常浪费；未区分「阻断类」与「信息类」目的地，会让队列深度在高峰线性爆炸。
  3. DerivedData 与测试附件当软预算：录屏、失败快照、性能轨迹默认开启时，单 PR 可在数小时内吃掉数十 GB；若清理策略只在周末跑一次，周三下午磁盘就会先于业务挂掉。站内 构建队列与 DerivedData一文从构建侧讲过水位，本篇把同一逻辑收紧到「PR 高频短 Job」。

先把「并发上限、destination 子集、磁盘回收」三件事参数化，再谈工具链版本。

2. 对照表：本机 Mac 池与 Mac 云 PR 节点

下表用于评审第一版：左侧是常见诉求，右侧给出推荐形态与主要风险。

诉求办公室 Mac mini 池规格可预期的 Mac 云 PR 节点备注
峰值并发可预测受桌面占用、系统更新与人工登录影响大机型与内存钉死，适合把并发写成代码与 GitHub 托管 Runner 对比见 自建池对照文
磁盘水位共享盘易「谁都没删」按 Job 挂载临时卷或强制定时 prune建议 PR Job 结束即删 DerivedData 子树
队列可见性常靠口头协调与 CI 标签、API 扩容一致参见 可观测性清单
网络 RTT内网低但拓扑复杂可选区域，贴近代码与制品库与跨端混合流水线可组合阅读
实践提示：PR 节点与 release 节点分离标签；PR 侧重「快失败 + 窄 destination」，release 再跑宽矩阵，避免互相抢 Simulator。

3. 七步落地：并发、destination 与清理

  1. 建立「每机型 Simulator 数 × 并行测试 worker」基线表：在目标机型上用典型工程跑 20 次 PR 长度任务，记录 P95 时长与峰值 RSS，得到「每物理核最多并发几个 Simulator」初值。
  2. 把 destination 分成阻断集与扩展集：阻断集只保留最新两代 iOS 与主屏幕尺寸；扩展集 nightly 再跑，PR 失败不阻断合并。
  3. 为 xcodebuild test 设置硬超时与分层重试：基础设施超时与断言失败分流；对 flaky UI 用「同 commit 最多重试 1 次」策略并打标签，避免无限重跑掩盖队列问题。
  4. 在 Job 尾部挂清理钩子：无论成功失败执行 xcrun simctl shutdown all 与 DerivedData 子目录删除；对附件大于阈值的结果包做截断上传。
  5. 把队列深度暴露成指标：在 CI 平台记录「等待 macOS 执行器」的排队时间分布，超过阈值自动扩容或降级 destination。
  6. 与 Linux 前置 Job 约定 artifact 边界：只传编译产物与索引，不传整仓 Pods 缓存除非命中签名。
  7. 写一页 Runbook：包含「磁盘>某阈值→只跑阻断集」「队列>某深度→禁止扩展集」的开关语句，值班可照抄执行。
# PR 阻断集示例（按团队基线替换设备名） xcodebuild test \ -scheme YourApp \ -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.4' \ -destination 'platform=iOS Simulator,name=iPhone 15,OS=17.5' \ -parallel-testing-enabled YES \ -maximum-parallel-testing-workers 3

4. 可引用阈值：CPU、磁盘与队列深度

下列数字用于评审对齐，最终以你们工程实测为准：① 在 M4 级约 10～12 核可见算力、32GB 内存的节点上，常见消费级 App 的 PR 阻断集可先从「并行 worker 3～4 + 同时活跃 Simulator ≤4」起评，再按 UI 用例密度上调或下调。② 单 PR Job 建议预留约 1.8～2.4 倍最近一次成功构建的 DerivedData 体积作为磁盘峰值，低于全局剩余空间 12% 时触发只跑阻断集策略（与站内构建队列文阈值语言对齐）。③ 队列深度若连续 30 分钟高于「可用 macOS 执行器」数量的 4 倍，应优先降级扩展集而非盲目加机器，否则会把 flaky 放大成全队噪声。④ 录屏与性能轨迹建议默认关闭于 PR，仅在手动触发或 nightly 打开，可把附件体积从数 GB 压到数百 MB 量级。⑤ 合并到主分支后保留一次完整矩阵结果 JSON 24～72 小时，便于对比「PR 窄集通过但宽集失败」的回归类型。

5. 常见问题

PR 要不要跑 iPad 与多系统_minor 全排列？

不建议默认全排列；用阻断集覆盖最新用户占比高的机型，其余放 nightly 或发布分支。

并行一打开就随机卡死怎么办？

先减半 worker 并关闭录屏；检查是否多个 Job 共享同一用户会话导致 Simulator 锁争用。

与「90 秒开通 Mac 云」文档如何分工？

该文讲资源入口与 Runner 注册；本文讲跑起来之后如何把 Simulator 与磁盘治理到可发布状态。

6. 从 PR 测试回到可预期的 Mac 执行面

只在办公室堆几台 Mac mini 能撑过早期迭代，但一旦 PR 频率与并行度上来，人力擦盘与口头协调会迅速成为隐藏单点：尾延迟不可解释，队列深度不可见，夜间合并仍靠赌磁盘余量。纯笔记本环境又缺持续电源与稳定上行，和「像管 VPS 一样」的运维习惯也不一致。若要把 PR 门禁做成可度量、可降级、可扩容的流水线，租赁 VPSMAC 的 M4 Mac 云主机作为专用 PR 执行池，通常比在混杂桌面或超售共享环境里硬扛更稳：SSH 与标签体系与 Linux 调度器一致，机型与内存可钉死，清理与并发策略可写进同一套 Runbook，并与站内 API 开通、DerivedData 队列及 Runner 对照文形成闭环。