swift-performance

Swift 性能

一次开销等于每次运行的工作量乘以运行频率。编写代码时，构建模式会将高开销工作移出热路径。诊断模式会找出进入热路径的工作，而修复则回到构建模式中完成。

请为每个应用编写自己的测试数据、场景和计数器，因为每个应用需要的内容都不同。

构建模式

开发新功能时运行所有步骤。审查代码时，对差异运行步骤 4 到 6。

1. 工作负载模型。 列出每个视图当前、×10 和 ×100 时的项目数。最大的视图通常会合并其他视图。
2. 热路径分析。 按运行频率标记每项计算：每帧、每个输入事件、每个操作、每次数据变更，或仅一次。
3. 性能预算。 在 120 Hz 下，一帧有 8 ms 的主线程时间；在 60 Hz 下有 16 ms。一个操作应在 100 ms 内完成。未交互的窗口 CPU 使用率约为 0%。
   • 完成标准：每条热路径在 ×10 规模下的开销都符合预算，或已标记出来。
4. 限制工作量。
   • 使用 LazyVStack、List 或 Table 延迟绘制不断增长的集合。VStack 会构建每个项目。
   • 仅在可见且内容变化时运行动画、符号效果、TimelineView、计时器和轮询。重复效果会让窗口每帧都重新渲染。
   • 保持大型子树的 .id 稳定，因为新的 .id 会重建子树。
5. 复用与失效。
   • 在源数据变化时计算派生集合，并在 body 中读取存储的结果。
   • 将快速变化的状态（例如悬停和选择状态）放在需要它的最小视图中。列表根视图的状态会导致每一行都重绘。
   • 仅在显示时构建每个项目的附加内容，例如工具提示文本。
   • 按需读取项目几何信息，或在不会滚动的坐标空间中读取。
6. 并发与 I/O。 保留主线程用于绘制和输入。在 Swift 6.2 的易用并发模式下，将 CPU 密集型异步函数标记为 @concurrent，因为普通的 nonisolated async 函数会在调用方的 actor 上运行。
7. 测量。 在变更前后，按各个数据规模测量每条已标记的路径。

诊断模式

1. 症状。 记录哪里变慢、慢了多少，以及在什么数据规模下发生。
2. 复现。 在应用副本中，用用户的数据规模重复问题，并使用独立数据，以免更改用户的应用和数据。
3. 测量。 沿用户实际采用的路径，测量空闲状态、慢速交互和快速对照场景。
   • 完成标准：慢速和快速场景之间能通过某个数值体现差异。
4. 隔离。 一次关闭一个部分，直到开销消失。每当性能分析结果只显示框架代码时，都要这样做，因为性能分析器能显示时间花在哪里，却不能说明原因。
5. 根因。 指明其机制、发生频率、文件和行号，以及它违反的构建规则。
   • 完成标准：移除该问题后，开销也随之消失。
6. 验证。 将修复前后的测量结果与未更改的基线并列比较。

报告一张表，列出每个场景的主线程占比、最严重的卡顿和最慢的操作，然后列出根因。

可信的测量方法

• 测量主线程 CPU 占比和卡顿时长。总 CPU 使用率和帧率无法说明时间花在哪里。
• 统计 body 和处理程序运行的次数，因为频率能解释大多数开销。
• 测量时确认状态：窗口已打开、数据已加载，并且没有其他内容在该主线程上绘制。
• 检查测量工具是否引入开销。自动化和截屏可能会改变应用绘制的内容。
• 用发布版构建对比发布版构建，并在每次运行中只改变一项内容，至少重复每个场景两次。

脚本

• scripts/MainThreadMeter.swift：在可构建的应用内部测量主线程 CPU 占比和卡顿。其 8 ms 的 ping 会唤醒主线程，因此请使用 sample 测量空闲状态。
• scripts/sample-busy.py：根据 sample <pid> <seconds> -mayDie -file <path> 的输出，测量任意运行中应用的主线程繁忙占比。--frames <binary> 会列出该二进制中开销最大的帧。