find-animation-opportunities

查找动画机会

大多数应用不需要更多动画。它们只需要在少数有意义的地方使用动画，其他地方则不需要。你的任务是在用户的代码中找到这些地方，明确指出哪些内容应保持静止或减弱动效，并用 60fps 库中的实际交互为每条建议提供依据。

这里的动效包括视觉动效和触觉反馈：两者共同决定应用带给人的感受。

本轮不要更改任何代码。交付内容是一份简短的报告。

1. 盘点现有动效

在查找缺失之处前，先搜索代码中应用已有的动效：withAnimation、.animation(、.transition、matchedGeometryEffect、matchedTransitionSource、contentTransition、symbolEffect、phaseAnimator、keyframeAnimator、sensoryFeedback、UIImpactFeedbackGenerator、UIView.animate，以及任何减弱动效检查。在大型应用中，这会是一份很长的清单：按文件归类，并优先查看触觉反馈和转场，因为大多数问题都藏在这里。

然后说明这是什么类型的应用：

• 动效较少。 大多数价值来自新的动效机会。
• 动效已很丰富。 在报告开头说明这一点。此时重点应是少数缺失之处、存在问题的动效和过度使用的动效。不要推荐应用已经具备的动效。

根据应用现有的动效和设计，判断其整体风格：平静克制，还是大胆活泼。每条建议都必须与其风格相符。

2. 确定范围

如果用户指定了某个屏幕或功能，就只查看该处。否则，覆盖用户最常接触的屏幕：根视图及其呈现的内容（标签页、覆盖层、工作表以及它们打开的流程），还要包括容易被忽略的小组件、实时活动和其他扩展。小组件无法运行自己的动画：其中唯一的动效是在时间线变化时使用内容转场（滚动数字、交叉淡入淡出），因此绝不要建议更多动效。也要查看驱动视图的状态（@Observable 模型、视图模型、分配新数据的代码），而不只是视图：问题往往出在状态变化的位置。

跳过没有任何代码构造的视图，以及当前无法运行的代码路径（例如始终处于开启状态的标志背后的代码）。如果某项内容以后会变得重要，只需提及一次，并标注为目前尚不可访问。

发现项最多报告 10 条，表格和修复建议合计计算（“保持静止”列表不计入）。如果真正有价值的内容在修复建议中，简短的表格即可。如果候选项更多，按时机的意义与发生频率排序：罕见且有意义的排在前面，频繁且影响较小的排在后面。

3. 找出需要动效的时刻

值得加入动效的时刻：

• 等待。 网络调用或耗时操作只有一个旋转指示器，甚至什么反馈也没有。
• 成功与失败。 保存、发送、购买或完成后悄无声息，或者出错后直接重置，没有任何反馈。
• 内容出现和消失。 插入、删除或重新排序的行，被关闭的卡片，以及添加的项目。
• 它去哪儿了。 点开缩略图查看详情，或任何能通过保持连续性帮助用户记住当前位置的场景。
• 选择与状态。 开关、选项、标签页、分段控件切换时毫无反馈，直接跳变。
• 发生变化的数字。 余额、计数、计时器、进度。
• 空状态与首次运行状态。 新用户看到的第一个界面。
• 直接操控。 拖动、轻扫和长按等应跟随手指的操作。

还要检查已有的动效：

• 失效。 .transition 对应的状态变化不在 withAnimation 中，因此动效无法播放。动画关联到了错误的值。只读取一次减弱动态效果设置，而不是从 @Environment(\.accessibilityReduceMotion) 读取，因此无法检测到 App 打开期间设置的变化。
• 过度。 在日常操作上使用成功触感反馈或庆祝效果（每次刷新、每次轮询）。搜索所有 .success 触感反馈：如果 App 只在一个重大时刻使用它，那么其他任何用法都值得指出。用户每天多次经过的路径上使用较长动画。
• 让意义消失的降级处理。 减弱动态效果分支让有意义的变化毫无过渡地跳变，而交叉淡入淡出本可以保留其含义。已有动效却完全没有降级处理，也需要修正。

对每项发现，注明需要修改的文件和行号（通常是设置状态的位置），以及展示该效果的视图（如果它位于另一个文件）。

4. 决定哪些地方保持静止

在报告中明确说明这一点。它的价值占了一半。

以下情况应保持静止：

• 操作会重复。 每天要进行多次的操作（输入、滚动信息流、点击几十次的标签栏、每隔几秒刷新的数据）会让任何动画都令人厌烦。保持即时响应或不加修饰。
• 用户正在阅读。 长篇文本、设置、数据表格、表单。动效会分散注意力。
• 动效会碍事。 绝不要让用户等动画结束后才能操作。用户频繁经过的路径上，超过约 300 ms 的动画都太长。
• 系统已有处理。 导航推入、工作表、警告框、键盘、系统登录。通常重新设计这些效果只会让 App 显得不那么原生，而不是更原生。
• 动效只是装饰。 无法表达状态的循环效果或炫技效果。
• 界面已经有一个亮点。 每个界面只保留一个令人难忘的动效。两个动效会互相争抢注意力。

每项建议都必须提供减弱动态效果时的降级方案：交叉淡入淡出，或不使用动效。

5. 为每个机会寻找真实参考

对于表格中的每个机会，都调用 60fps_search_shots。用通俗的话描述动效、发生的时刻，以及 App 的氛围：“用柔和的圆环填充一次，标记一个里程碑”就合适；“成就”则不合适。不要先说界面元素的名称（小组件、设置、单元格）：这会让搜索结果偏向该元素，而不是动效本身。

搜索总会返回结果，而且评分几乎无法区分优质匹配和较差匹配，因此要根据每条结果的标题和摘要自行判断。优先选择 intensity 和 mood 与 App 氛围相符的结果。如果第一次搜索未找到合适结果，用不同措辞再试一次（加入 calm、subtle、playful 等氛围词）。如果再试后仍没有合适结果，就写上“No close match”，不要勉强凑合，改用文字描述动效即可。修复问题不需要搜索，纯触感反馈的改动也不需要搜索。只要说明要借鉴哪一部分，部分匹配也可以：“只用行滑动效果，不要彩纸”。

只有在用户选定后才获取更多信息。然后，60fps_get_motion_breakdown 会提供时长信息，60fps_get_motion_code 会提供可调整的 SwiftUI 代码（参见 motion-reference 技能）。

6. 报告

开头用两到三句话给出结论，包括应用现有的动效是否流畅。如果问题严重（内容不可见、流程中断），要在开头指出，不要只写在修复建议里。如果某个非动效事实会改变建议（例如点按后应打开的屏幕尚不存在），在表格下方补充一行。然后 提供一个表格，按价值从高到低排列：

位置	时机	建议	减少动态效果	截图
CheckoutView.swift:84	支付完成后没有反馈	将按钮变成勾号，然后关闭	淡入淡出显示勾号	截图标题，只截取勾号

然后，只有在存在相关问题时，才添加 修复或弱化：列出有问题或过度的动效，每项注明文件、行号和一句修复建议。然后添加 保持静止的内容，每项用一句话说明原因。

最后询问对方想实现哪一项，并指出哪些问题可以用一行代码修复。表达要直白：使用简短句子和常见词语，不要夸大其词。绝不要使用破折号。

不适用范围

对于 Android、Flutter、React Native 或 Web 应用：说明此库仅适用于 iOS，并给出不含截图的一般性建议。性能或帧率问题属于另一个问题。