SnipTrip：贴纸画布编辑器与“光晕动效”的交互细节

文章目录

- 目标：无跳变、可瞬停、原地续播
- [SnipTrip 的光晕属于哪一类动画](#SnipTrip 的光晕属于哪一类动画)
- [原来的实现方式：基于 `startTime + pausedTime` 的"事后校准"](#原来的实现方式：基于 startTime + pausedTime 的“事后校准”)
- 原来方案的问题：恢复瞬间容易出现"跳一下"
- - [问题 1：恢复那一瞬间可能出现"一帧错相位"](#问题 1：恢复那一瞬间可能出现“一帧错相位”)
  - [问题 2：混用两套时钟源引入瞬时误差](#问题 2：混用两套时钟源引入瞬时误差)
  - [问题 3：`paused:` 只能停"帧更新"，不能保证"相位连续"](#问题 3：paused: 只能停“帧更新”，不能保证“相位连续”)
- [更隐蔽的坑：为什么 `TimelineView(paused:)` 容易踩到"回退一帧"](#更隐蔽的坑：为什么 TimelineView(paused:) 容易踩到“回退一帧”)
- - [最小复现 Demo（预测渲染 + 暂停）](#最小复现 Demo（预测渲染 + 暂停）)
  - 现象解释
- [SnipTrip 的可发布修复：累计时间轴 + 非预测渲染（相位只来自已提交状态）](#SnipTrip 的可发布修复：累计时间轴 + 非预测渲染（相位只来自已提交状态）)
- [配图说明：定位 SnipTrip 中的光晕与交互开关](#配图说明：定位 SnipTrip 中的光晕与交互开关)
- 小结

SnipTrip 是一款以"贴纸画布"为核心体验的 iOS 应用：从照片生成贴纸，将贴纸放置到 A4 画布上进行拖拽、缩放、旋转编辑，并通过现代化的玻璃拟态组件提供清晰、顺滑的交互反馈。界面中包含 Apple Intelligence 风格的动态光晕边框、液态玻璃背景与细腻的动态高光，用于强调可交互区域与层级关系。

在这类编辑器产品中，动效不仅要"好看"，还要"听话"：当贴纸进入操作状态时，氛围动效需要立刻停在当前帧，避免干扰；操作结束后动效需要从同一帧继续播放，避免相位跳变造成的闪动与突兀。

本文记录一个常见但微妙的问题：SwiftUI 中使用 TimelineView 驱动光晕"流动 + 呼吸"时，暂停/恢复很容易踩坑；并给出 SnipTrip 中可用于上线的修复思路与最小复现 Demo。

目标：无跳变、可瞬停、原地续播

需求用一句话描述：

触发交互（例如开始拖拽/缩放/旋转贴纸）时，光晕立即冻结在当前帧（流动与呼吸同步冻结）。
交互结束时，光晕从冻结位置继续推进（不重播、不跳变、不"回退一帧"）。

实现这一目标的核心原则只有一个：

动画必须由"可控时间轴"驱动；暂停/恢复只控制时间轴是否推进，而不是重新触发一段新动画。

SnipTrip 的光晕属于哪一类动画

SnipTrip 的光晕不是通过 .animation(..., value:) 对属性插值，而是典型的 time-driven rendering：每一帧根据时间 t 计算视觉状态。

常见的组成如下：

呼吸：opacity/blur 由 sin(t * ω) 产生周期变化。
流动：旋转渐变角度 Angle(degrees: t * speed) 持续推进。
色相漂移：hueRotation(Angle(degrees: t * drift)) 缓慢变化。

因此"暂停/恢复"的本质不是停止某个 SwiftUI 事务动画，而是让时间 t 在暂停期间保持不变，在恢复后从原值继续增长。

原来的实现方式：基于 `startTime + pausedTime` 的"事后校准"

在不少 SwiftUI 项目中，最直观的写法是：

每帧通过 timeline.date - startTime 得到动画时间 t。
暂停时记录 pausedTime = t。
恢复时用 startTime = now - pausedTime 重新对齐基准。

伪代码如下：

swift 复制代码

@State private var startTime = Date().timeIntervalSinceReferenceDate
@State private var pausedTime: TimeInterval = 0

TimelineView(.animation(minimumInterval: 1.0 / 60.0, paused: !isAnimating)) { timeline in
    let t = timeline.date.timeIntervalSinceReferenceDate - startTime
    render(at: t)
        .onChange(of: timeline.date) { _, _ in
            pausedTime = t
        }
}
.onChange(of: isAnimating) { old, new in
    guard !old, new else { return }
    startTime = Date().timeIntervalSinceReferenceDate - pausedTime
}

这套思路的目标是：恢复后 t 继续从暂停前的值推进。

原来方案的问题：恢复瞬间容易出现"跳一下"

问题 1：恢复那一瞬间可能出现"一帧错相位"

SwiftUI 的状态更新与回调执行顺序并不保证"先校准 startTime，再渲染第一帧"。一个很常见的序列是：

isAnimating 变为 true。
TimelineView 开始提供新 timeline.date，触发一次渲染。
第一帧仍使用旧 startTime 计算 t，导致相位瞬间跳动。
随后 .onChange(of: isAnimating) 才更新 startTime。
下一帧又回到"校准后的相位"。

视觉上表现为：松手恢复瞬间，渐变角度或色相漂移抖动一次，呼吸亮度闪一下。

问题 2：混用两套时钟源引入瞬时误差

渲染使用 timeline.date，校准使用 Date()。两者不是同一采样点，会引入微小误差；在"旋转渐变 + blur + plusLighter"的高对比边缘上，这个误差很容易被肉眼感知。

问题 3：`paused:` 只能停"帧更新"，不能保证"相位连续"

TimelineView(... paused:) 能让帧停止更新，但相位连续仍依赖"恢复时校准"。只要校准不是在恢复前原子生效，就会出现恢复首帧错相位的问题。

更隐蔽的坑：为什么 `TimelineView(paused:)` 容易踩到"回退一帧"

即使不使用 startTime/pausedTime，只要渲染使用了"预测值"，也会遇到"回退一帧"的问题。

最小复现 Demo（预测渲染 + 暂停）

下面的 Demo 使用累计时间轴，但渲染时使用 accumulatedTime + delta（预测"本帧结束后"的时间）。如果暂停发生在"渲染之后、累加之前"的边界窗口，accumulatedTime 将不会被更新，下一帧渲染将回到旧值，从而产生"回退一帧"。

swift 复制代码

import SwiftUI

struct TimelinePausedBackstepDemo: View {
    @State private var isAnimating = true
    @State private var accumulatedTime: TimeInterval = 0
    @State private var lastTick: TimeInterval?

    var body: some View {
        VStack(spacing: 16) {
            TimelineView(.animation(minimumInterval: 1.0 / 60.0, paused: !isAnimating)) { timeline in
                let tick = timeline.date.timeIntervalSinceReferenceDate
                let t = predictedTime(for: tick) // 预测值
                Text(String(format: "t = %.3f", t))
                    .monospacedDigit()
                    .padding()
                    .frame(maxWidth: .infinity)
                    .background(.ultraThinMaterial, in: RoundedRectangle(cornerRadius: 16, style: .continuous))
                    .onChange(of: tick) { _, newTick in
                        guard let previous = lastTick else {
                            lastTick = newTick
                            return
                        }
                        let delta = max(0, min(newTick - previous, 0.25))
                        if isAnimating {
                            accumulatedTime += delta
                        }
                        lastTick = newTick
                    }
            }

            Button(isAnimating ? "Pause" : "Resume") {
                isAnimating.toggle()
            }
            .buttonStyle(.borderedProminent)
        }
        .padding()
    }

    private func predictedTime(for tick: TimeInterval) -> TimeInterval {
        guard let lastTick else { return accumulatedTime }
        let delta = max(0, min(tick - lastTick, 0.25))
        return isAnimating ? (accumulatedTime + delta) : accumulatedTime
    }
}

现象解释

播放时：渲染使用 accumulatedTime + delta（预测值），因此看起来更"贴近当前帧时间"。
暂停边界：如果暂停恰好发生在"渲染结束、onChange 还没执行"之间，那么本帧的 accumulatedTime 无法被累加。
下一帧（暂停态）：渲染回落到旧 accumulatedTime，与上一帧用户看到的预测值相比，产生 delta 大小的回退。

对于旋转速度 80°/秒的光晕，16ms 的回退约为 80 * 0.016 ≈ 1.3°，足以形成"抖一下"的体感。

SnipTrip 的可发布修复：累计时间轴 + 非预测渲染（相位只来自已提交状态）

稳定的原则是：渲染只使用"已提交"的累计时间，不使用预测值。

修复要点：

TimelineView 只负责提供 tick。
onChange 内部负责累加 accumulatedTime。
渲染阶段直接使用 accumulatedTime，保证暂停发生在任何时刻都不会产生回退。

示例代码如下：

swift 复制代码

TimelineView(.animation(minimumInterval: 1.0 / 60.0)) { timeline in
    let tick = timeline.date.timeIntervalSinceReferenceDate

    render(at: accumulatedTime) // 只用已提交状态，不做预测
        .onAppear {
            lastTick = tick
        }
        .onChange(of: tick) { _, newTick in
            guard let previous = lastTick else {
                lastTick = newTick
                return
            }

            let delta = max(0, min(newTick - previous, 0.25))
            if isAnimating {
                accumulatedTime += delta
            }
            lastTick = newTick
        }
}

这种写法满足：

暂停：accumulatedTime 不再增长，渲染固定，流动与呼吸同步冻结。
恢复：继续累加 delta，相位从原值继续推进，无跳变、无回退。

配图说明：定位 SnipTrip 中的光晕与交互开关

SnipTrip 的光晕主要出现在以下区域：

画布边框：A4 画布 overlay 的光晕边框。
底部按钮：加号/导出按钮的圆形光晕。
素材托盘：胶囊形容器的光晕边框。

贴纸进入拖拽/缩放/旋转交互时，SnipTrip 通过环境值 glowAnimating 统一控制光晕是否推进时间轴，从而实现"操作时冻结、结束后续播"的体验。

小结

startTime + pausedTime 的"事后校准"在 SwiftUI 中很容易出现恢复首帧错相位，表现为跳变/闪动。
TimelineView(paused:) 与"预测渲染"结合时，边界窗口容易触发"回退一帧"。
可发布的稳妥做法是：用累计时间轴驱动，并确保渲染只基于已提交状态（非预测），暂停/恢复仅控制累计时间是否推进。

SnipTrip：贴纸画布编辑器与“光晕动效”的交互细节

文章目录

目标：无跳变、可瞬停、原地续播

SnipTrip 的光晕属于哪一类动画

原来的实现方式：基于 startTime + pausedTime 的"事后校准"

原来方案的问题：恢复瞬间容易出现"跳一下"

问题 1：恢复那一瞬间可能出现"一帧错相位"

问题 2：混用两套时钟源引入瞬时误差

问题 3：paused: 只能停"帧更新"，不能保证"相位连续"

更隐蔽的坑：为什么 TimelineView(paused:) 容易踩到"回退一帧"

最小复现 Demo（预测渲染 + 暂停）

现象解释

SnipTrip 的可发布修复：累计时间轴 + 非预测渲染（相位只来自已提交状态）

配图说明：定位 SnipTrip 中的光晕与交互开关

小结

原来的实现方式：基于 `startTime + pausedTime` 的"事后校准"

问题 3：`paused:` 只能停"帧更新"，不能保证"相位连续"

更隐蔽的坑：为什么 `TimelineView(paused:)` 容易踩到"回退一帧"