ios-perceived-performance

iOS 感知性能

目的

使用此技能，检查 iOS 屏幕或流程是否让用户感觉响应迅速，即使实际执行时间没有变化。

此技能侧重于用户可见的反馈、加载行为、分阶段呈现的内容、连续性、乐观 UI、高风险操作，以及对感知响应能力的验证。

何时使用此技能

当任务涉及以下情况时，使用此技能：

• 屏幕感觉缓慢、卡住、空白、跳动或无响应；
• 点击或手势后没有可见反馈；
• 首批有意义内容延迟出现；
• 加载状态、占位内容、骨架屏、空状态、重试状态或刷新状态；
• 渐进式渲染、部分内容、分区加载或刷新期间显示旧内容的 UI；
• 乐观更新、等待状态、回滚、重试或本地与服务器状态协调；
• 高风险、不可逆、破坏性、金融、法律、医疗、身份或安全敏感操作；
• 异步工作期间重复提交或反复点击；
• 感知延迟方面的权衡，其中产品行为与实际耗时同样重要；
• 使用录屏、UI 测试、Instruments、MetricKit、生产日志或用户可见信号进行验证。

何时不使用此技能

以下情况不要使用此技能：

• 低层 CPU、分配、ARC、内存、运行时或编译器性能调查；
• SwiftUI 失效、标识、布局或滚动问题，除非问题与感知响应能力有关；
• Swift 并发内部机制，除非任务行为会影响可见 UI 反馈或分阶段加载；
• App 启动性能，除非问题涉及从用户角度看到首个可用屏幕或进行首次交互的时间；
• 与响应能力、加载或反馈无关的视觉重新设计请求；
• 在没有运行时证据时，提出必须运行 App 才能验证的说法。

当这些领域才是主要问题时，请使用 ios-performance-profiling、swiftui-performance、swift-concurrency-performance、swift-runtime-performance 或 ios-launch-performance。

核心模型

用户不会直接感受到 CPU 采样、网络跟踪、数据库计时或异步任务图。

他们感受到的是：

• App 是否立即响应；
• 首批有用内容何时出现；
• 进度是否清晰；
• 工作继续进行时屏幕是否保持稳定；
• 失败和重试是否容易理解；
• 等待中的操作是否值得信赖；
• 操作是否可能被意外重复；
• UI 是否如实反映以服务器为准的结果。

在提出低层优化方案之前，先从用户可见的延迟或不确定性入手。

Agent 能力边界

Agent 通常可以检查并改进：

• 加载、已加载、空、错误、刷新中、待处理、同步中和失败等状态的状态模型；
• UI 是否只在异步工作完成后才发生变化；
• 用户操作是否会立即得到视觉反馈；
• 刷新时是否不必要地清除已有的有用内容；
• 屏幕是否可以先呈现关键内容，再呈现次要内容；
• 乐观更新是否具备等待、回滚、重试和冲突处理机制；
• 高风险操作是否会在显示最终成功状态前等待确认；
• 是否阻止了重复提交。

Agent 可以提出建议，但没有运行时证据时无法证明以下事项：

• 屏幕感觉是否足够快；
• 骨架屏是否能改善感知；
• 刻意延迟是否合适；
• 低电量模式是否暴露了性能余量不足的问题；
• 旧设备上的性能是否可以接受；
• 产品流程是否让用户感到可信。

除非用户提供了录屏、跟踪记录、测试结果、性能分析输出或生产环境信号等证据，否则不要声称已进行手动验证或基于设备的验证。

审查工作流

1. 确定用户可见的症状：没有反馈、空白屏幕、要么全部加载要么什么都不加载、更新跳动、进度不明确、不安全的乐观反馈、重复提交或不信任。
2. 找出导致该症状的状态转换。
3. 判断最先有效的改进应是产品／UI 反馈，还是底层性能优化。
4. 检查 UI 是否会立即响应用户操作。
5. 检查关键内容能否先于次要内容显示。
6. 检查刷新时能否保留已有的有效内容。
7. 检查加载、空状态、错误、重试、刷新中、待处理、已同步和失败状态是否足够明确、彼此有别。
8. 判断乐观 UI 是否安全、可撤销且诚实。
9. 对高风险操作，优先提供明确的进度反馈，并以服务端确认成功为准，而不是显示乐观的最终状态。
10. 提出能够改善用户可感知响应速度的最小改动。
11. 说明哪些内容可以从代码中确定，哪些需要运行时验证。
12. 建议使用能够反映用户体验的证据进行验证。

决策规则

• 如果用户操作后看不到任何响应，应先添加即时反馈，再优化操作本身。
• 如果操作进行期间屏幕一片空白，可考虑缓存内容、占位内容、骨架屏或渐进式渲染。
• 如果屏幕必须等待无关数据后才能显示任何内容，可考虑按区块加载或分阶段渲染。
• 如果刷新会移除有用内容，且保留旧内容是安全的，应保留旧内容并标明正在刷新。
• 如果加载、空状态、错误和重试状态混为一谈，应先将它们区分开，再调整性能。
• 如果操作风险低且可撤销，乐观 UI 可能会改善感知延迟。
• 如果操作涉及财务、破坏性操作、法律、医疗、身份、安全敏感事项、不可逆操作或服务端权威状态，在确认之前不要显示最终成功状态。
• 如果可能发生重复提交，应添加待处理状态、禁用控件、幂等性处理或请求跟踪。
• 如果建议取决于产品信任或用户感知，除非有证据，否则应将其描述为产品假设。
• 如果无法通过代码证明性能结论，应提供验证计划，而不是声称已取得成效。

注意事项

• 不要将骨架屏或占位内容当作实际执行时间的改善。
• 不要让错误被无限期的加载状态掩盖。
• 不要为高风险或不可逆操作建议显示乐观成功状态。
• 不要默认建议人为延迟作为性能修复方案。
• 除非旧内容不安全或会产生误导，否则不要在刷新时清除内容。
• 如果部分内容会让用户困惑，不要建议将每个屏幕都拆分为独立加载的区块。
• 不要声称“低电量模式可以模拟旧设备”。只能将其用作粗略的手动压力测试信号。
• 没有录屏、追踪记录、指标、测试或用户可见行为作为证据时，不要声称“感觉更快了”。
• 如果眼前的问题是缺少反馈或状态不明确，不要提出宽泛的底层优化建议。

证据与验证

优先采用能反映用户体验的证据：

• 从用户操作到首次反馈和首个有意义内容的屏幕录制；
• 点按到首次反馈的耗时；
• 首个有意义内容的出现时间；
• 主要交互可用前的等待时间；
• 多次刷新尝试；
• 慢速网络测试；
• 捕捉状态转换的 UI 测试；
• 用于分析卡顿、顿挫、布局、渲染和主线程工作的 Instruments 跟踪记录；
• MetricKit 或 Xcode Organizer 的响应性数据；
• 加载各阶段的生产日志；
• 用户描述界面卡住、空白、跳动或产生误导的反馈。

证据不完整时，请谨慎措辞：

• “这应该能缩短空白屏幕的时间。”
• “这能让用户更早获得反馈。”
• “这需要在发布版本中验证。”
• “请通过屏幕录制、Instruments 跟踪记录、UI 测试或生产信号进行验证。”

避免缺乏依据的说法：

• “这解决了性能问题。”
• “现在运行很流畅。”
• “用户会觉得速度更快。”
• “这在较旧设备上也能良好运行。”

参考资料路由

仅在相关时阅读以下资料：

• references/progressive-rendering.md — 当屏幕必须等待所有数据加载完成才能显示有用的界面、可以优先显示关键内容、需要按区块加载，或刷新时会清除现有内容时阅读。
• references/loading-states.md — 当任务涉及加载、空状态、错误、重试、刷新、骨架屏、占位内容或进度状态时阅读。
• references/optimistic-updates.md — 当任务涉及乐观 UI、待处理状态、回滚、重试、冲突处理、本地协调或服务器同步时阅读。
• references/high-stakes-actions.md — 当操作涉及财务、法律、破坏性操作、不可逆操作、医疗、身份、安全敏感或由服务器权威判定的内容时阅读。
• references/validation-and-testing.md — 当任务询问如何验证感知响应性、较旧设备上的表现、低电量模式信号、发布版本表现、屏幕录制、Instruments 跟踪记录、MetricKit 或生产环境证据时阅读。

输出要求

审查屏幕或流程时，请作出以下回应：

## Finding

Describe the perceived performance issue.

## User impact

Explain what the user sees or feels: no feedback, blank screen, jumpy updates, delayed interaction, unclear progress, unsafe optimism, duplicate submission risk, or premature success.

## Evidence

Point to code, state model, flow behavior, trace, recording, metric, user report, or missing UI state.

## Recommended change

Suggest the smallest useful product/UI change first: immediate feedback, distinct loading state, progressive rendering, stale-while-refreshing content, optimistic update with rollback, explicit confirmation, duplicate-submission prevention, or validation.

## Implementation notes

Explain what can be changed in code and what depends on product, design, backend, or runtime evidence.

## Validation

State how to verify the improvement. Do not claim manual, device, or production validation was performed unless evidence is provided.

当瓶颈在于缺少反馈、一次性渲染全部内容、加载状态不明确、不安全的乐观行为或衔接不佳时，应优先改进用户可见的体验，而不是进行底层优化。