1. 计时器跳动问题的真实场景

1.1 一个让人深夜挠头的 SwiftUI 小问题

如果你是长期在做 iOS 开发的人，大概率碰到过这种状况：倒计时功能写完了，数字也按秒在走，但屏幕上的时间文本就像个不安分的孩子——一会儿偏左、一会儿偏右，有时候还会上下抖一下。尤其是当数字从 9 变到 10、从 59 变到 60 这种位宽发生变化的瞬间，跳动的感觉会特别明显。我第一次在 SwiftUI 里做番茄钟的时候就踩过这个坑，当时的第一反应是怀疑自己写的 Timer 回调有问题，结果排查了半宿，最后发现根本不是 Timer 的问题，而是 SwiftUI 的布局和渲染机制在"捣乱"。

这个问题之所以常见，是因为很多从 UIKit 转过来的开发者会把"用 Timer 刷新 UI"的习惯照搬进 SwiftUI。在 UIKit 里，你确实可以直接用 Timer 去驱动UILabel.text的更新，因为 UIKit 不会因为文本内容变化就去重新计算整个视图树。但在 SwiftUI 里，视图是由状态驱动的，一旦@State变化，SwiftUI 会重新求值body，而重新求值过程中只要有任何布局参数发生改变，视图就会产生肉眼可见的位移、闪烁或跳动。这就是"计时器跳动"问题的根源。

1.2 跳动的三种典型表现

我在不同项目里见过三种"跳动"形式，它们成因不同，解决方案也不完全一样。第一种是水平跳动，最常见，表现是数字文本的宽度变化导致整个文本块位置偏移，比如数字 1 比数字 8 窄很多，从9:59跳到10:00时，一下子多了一位，周围的视图会被推着移动。第二种是竖直方向的微小抖动，一般发生在文本被放在VStack或HStack里、周围有其他弹性空间的时候，字体基线轻微变化就会让整体产生感觉上的"抖"。第三种是整体闪烁或重绘闪白，这种往往是因为视图结构被整体替换、或者隐式动画被错误地附加到了计时器更新的视图上。

这三种情况有时候还会叠加出现，尤其是当你把.animation(.default)挂在包含计时器文本的容器上时，每秒的更新都会触发动画过渡，视觉上就像整个页面在"呼吸"一样。很多人以为是自己代码写错了，其实只是没搞清楚 SwiftUI 的布局原理和动画触发条件。接下来我会把根因拆开讲，然后给出实际可用的解决方案，最后附上一份可以直接抄的完整倒计时实现。

2. 根因拆解：SwiftUI 为什么会让计时器"抖"起来

2.1 数字宽度不一致引发的布局抖动

SwiftUI 里Text("9")和Text("10")的宽度在默认.system比例字体下是不一样的。这是所有字体设计的常见特性——数字中，"1" 的宽度通常只有 "0" 的一半左右，尤其是在苹方、Helvetica 这类字体的默认数字字形上。比例字体追求可读性和美感，但放在计时器场景里就成了问题——因为你每秒都在改变字符串的宽度，SwiftUI 的布局引擎就需要不断重新计算Text的 frame，它周围的元素无论如何都会跟着微调。

打个比方，你在一排摆好的积木中间抽掉一块或者塞进去一块，旁边的积木肯定要重新排列。SwiftUI 的HStack也一样，文本宽度一变，它的"邻居"全部受影响。在倒计时显示分钟和秒数的时候，9:59变成10:00的瞬间，多出来的那个数字会把文本整体撑宽，如果Text被居中放置，那么左右两侧的空间分布就会变化，视觉上就是"跳"。

解决思路非常直接：让所有数字的宽度保持一致。SwiftUI 提供了两个层面的方案，一个是针对整个字体设计的.monospaced，另一个是专门针对数字字形的.monospacedDigit()。这两个的区别我会在第三章详细展开，但你先记住结论：计时器文本至少要用.monospacedDigit()，这能从根源上解决大部分水平跳动问题。

2.2 视图整体重建带来的闪烁

@State是 SwiftUI 中最常用的状态存储方式，但也最容易引发"无差别刷新"。请看下面的典型写法：

struct TimerView: View { @State private var remaining = 60 let timer = Timer.publish(every: 1, on: .main, in: .common).autoconnect() var body: some View { VStack { Text("\(remaining)") .font(.system(size: 48, weight: .bold)) Text("剩余秒数") .font(.subheadline) } .onReceive(timer) { _ in remaining -= 1 } } }

这段代码运行起来，每秒remaining变化一次，SwiftUI 会重新调用body，整个VStack里的所有子视图——包括那个永远不变的"剩余秒数"标签——都会被重新求值。如果这些子视图本身没有太多副作用，SwiftUI 的 diffing 机制通常能保证原生视图不被真正重建，所以闪烁不明显。但一旦你的视图层级变复杂，比如里面有List、有自定义绘制视图、有复杂的ZStack遮罩，重建频率过高就会导致渲染管线出现肉眼可见的闪烁或卡顿感。

这就像你每次只想刷新收件箱的一个小角标，结果把整个邮箱客户端都重启了一遍。视觉效果虽然不是完全不可用，但和"流畅"二字基本无缘。更麻烦的是，如果视图里有.animation、.transition这类修饰符，SwiftUI 会把每次@State变化都当成一次值得"动起来"的更新，闪烁和跳动就会被进一步放大。

2.3 Timer 与主线程更新的连锁反应

再聊一个隐藏很深的坑：Timer.publish的回调时机。默认情况下，SwiftUI 的onReceive会在主线程接收到事件并更新状态，这本身没问题。但如果你像很多人一样，在代码里又补了一层DispatchQueue.main.async包住remaining -= 1，且括号后的Timer发布事件和@State更新在同一个 RunLoop 周期内出现多次，就会造成冗余的 UI 刷新。虽然 SwiftUI 对同一 RunLoop 周期内的多个状态变化做了合成处理，但过于频繁的派发还是会让 CPU 做无谓的布局计算。

更重要的是，如果 Timer 附加的 RunLoop 模式选错了——比如用了.default——那么当用户正在滚动列表或者拖动滑块时，Timer 事件会被挂起，等滚动结束后又"追回"之前没触发的所有更新。表现在 UI 上，就是倒计时在滚动时突然停住，滚动结束又一秒连跳好几下。这种看起来像"跳动"的视觉效果，本质上是 Timer 事件被 RunLoop 模式阻塞后积压导致的。

要避免这一系列问题，光靠"把代码改对"还不够，还需要理解 SwiftUI 的视图求值策略、布局机制以及 RunLoop 的调度方式。理解了这些，你才能真正做到"计时器不跳动"，而不是换一种写法又踩进另一个坑。

3. 让计时器平滑的三大核心方案

3.1 第一步：等宽数字字体解决宽度抖动

先把最简单也最有效的方案拿出来。Text在 SwiftUI 里提供了monospacedDigit()修饰符，它会让文本中所有数字的字形宽度统一。注意这只影响数字，不影响字母和其他符号，所以很适合需要兼顾9:59这种格式的计时器——冒号仍然是原来的比例字形，但数字部分不会再忽宽忽窄。

Text("\(minutes):\(seconds)") .font(.system(size: 28, weight: .medium, design: .default)) .monospacedDigit()

你也可以直接用.font(.system(size: 28, weight: .medium, design: .monospaced))，让整个字体变成等宽字体，但这通常只用于代码展示场景，因为会让所有字符看起来过于"机械"，在界面设计上不太协调。我的建议是：只对计时器数字区域使用.monospacedDigit()，标题、单位文本保持原有字体风格。

如果你的倒计时格式里后面还有单位，比如"秒"或者是"分"，最好把数字和单位拆成两个独立的Text，数字部分用monospacedDigit()，单位部分正常显示，并放在HStack里对齐。这样既能保证数字宽度稳定，又不会让单位文本也被迫使用等宽数字。实测下来，加了这一步之后，绝大多数水平跳动会直接消失。

这里还有一个容易被忽略的细节：如果计时器文本使用了Text("\(remaining)")这种直接把整数塞进去的方式，当数字位数变化时（比如从 9 到 10），等宽数字也救不了你，因为多了一位，整体宽度必然增加。要彻底解决位数变化带来的跳动，要么固定最少占位位数（比如String(format: "%02d", remaining)强制两位显示），要么在后续的布局手段中固定宽高。

3.2 第二步：用 TimelineView 替代 Timer + @State

如果你还在用Timer.publish(...).autoconnect()配合onReceive，那么我强烈建议你试试 SwiftUI 自带的TimelineView。它是 Apple 在 iOS 15 里专门为时间驱动型 UI 推出的解决方案。它做的事情非常纯粹：根据你指定的时间调度规则，在特定时间点重新求值视图内容，而不是通过"状态变化"来触发刷新。

理论上，TimelineView和Timer + State都能实现每秒刷新，但设计意图完全不同。TimelineView把"时间"作为输入数据源直接暴露给你的视图闭包，你不需要存储任何和当前时间相关的@State，这就避免了状态变化带来的视图树整体重建。另外一个关键点是，TimelineView的重新求值是发生在局部视图作用域内的，因此它不会牵连周围的视图。

下面是一个基础用法：

TimelineView(.periodic(from: .now, by: 1.0)) { context in let currentDate = context.date Text(currentDate, style: .time) .font(.system(size: 48, weight: .bold)) .monospacedDigit() }

context.date就是当前"调度时间点"，by: 1.0表示每秒触发一次。Text的单参数初始化方式配合.date、.time这些样式可以直接显示时间日期，底层会自己处理数字更新，性能很好。但如果你需要显示的是倒计时剩余时长，那就要自己根据context.date计算差值，我在第四章会给出完整代码。

用TimelineView还有一个额外的好处：你不需要手动管理 Timer 的生命周期。很多初学者在写Timer.publish().autoconnect()之后会忘记取消 Timer，导致视图已经销毁了、Timer 还在跑，这在 SwiftUI 里还会引发一个更隐蔽的问题——即使视图消失，onReceive依然持有闭包，后台更新时间状态，等视图再次出现时状态已经"乱跳"了。而TimelineView的生命周期由 SwiftUI 管理，视图消失后调度就会自动停止，省心太多。

3.3 第三步：用 contentTransition 实现数字过渡动画

解决了布局抖动，下面该解决"变化过程"的视觉效果了。很多计时器 App 在数字跳动时会有一种非常顺滑的滚动翻转效果，这在传统 UIKit 里需要做不少动画工作，但在 iOS 16+ 的 SwiftUI 里，苹果直接提供了.contentTransition(.numericText())这个修饰符。

Text("\(minutes):\(seconds)") .font(.system(size: 48, weight: .bold, design: .rounded)) .monospacedDigit() .contentTransition(.numericText(countsDown: true))

numericText(countsDown:)表示数字发生改变时，以"数字竖向滚动"的形式平滑过渡到新值。countsDown: true表示数值正在减小，动画方向是从下往上滚动；如果是倒计时场景，这个参数选true视觉更自然。如果数值在增加（比如秒表），就传false。

注意，contentTransition只是一个"过渡样式声明"，它本身不会触发动画。你需要在外部容器上附加.animation修饰符，才算真正激活。不过这里有个大坑：一旦.animation被附加到包含多个子视图的容器上，所有子视图的任何变化都会被动画化，包括那些你不希望动的东西。所以我的建议是：把.animation和.contentTransition只挂在计时器文本上，或者把TimelineView的内容单独封装成一个子视图，缩小动画作用域。

这个方案的最大价值不只是视觉好看，还在于性能和体验的统一。系统级的数字滚动过渡是经过优化的 Core Animation 实现，比你自己写withAnimation包裹文本更新要平滑得多，CPU 占用也更低。如果你的项目最低支持版本是 iOS 16+，可以直接放心使用。

4. 完整实操：从零搭建一个不生锈的倒计时器

4.1 数据模型与时间源设计

下面咱们不搞过分复杂的案例，就用一个"番茄钟倒计时 + 秒表计时"的经典组合来演示。关键设计原则只有一条：把时间源作为唯一真值，不要用"剩余秒数"这种可变状态去驱动 UI。

什么叫"剩余秒数"作为可变状态？就是文章开头那段代码里的@State private var remaining = 60。这种写法的问题在于，一旦 Timer 触发漏了一次或者应用进入后台，remaining就会和真实时间产生偏差。正确做法是保存一个endDate，每次 UI 刷新的时候用当前时间计算剩余时长：

struct CountdownModel { let totalDuration: TimeInterval let endDate: Date var remaining: TimeInterval { max(0, endDate.timeIntervalSinceNow) } }

使用endDate还有个额外好处：应用退到后台再切回来，剩余时间会自动校准。因为系统时间是全局同步的，你不需要在scenePhase变化时做任何特殊处理。这个思路和TimelineView的context.date天然契合——你在TimelineView闭包里拿到当前调度时间，用它和endDate做差值计算，得到的永远是最精确的剩余时长。

4.2 视图落地与布局细节

先看完整的视图代码，这是一个同时展示倒计时和秒表的界面：

struct TimerView: View { @State private var countdownEndDate = Date().addingTimeInterval(25 * 60) @State private var stopwatchStartDate = Date() @State private var isCountdownRunning = true var body: some View { VStack(spacing: 40) { countdownSection stopwatchSection controlButtons } .padding() } private var countdownSection: some View { TimelineView(.periodic(from: .now, by: 1.0)) { context in let remaining = max(0, countdownEndDate.timeIntervalSince(context.date)) let minutes = Int(remaining) / 60 let seconds = Int(remaining) % 60 HStack(spacing: 8) { Text(String(format: "%02d:%02d", minutes, seconds)) .font(.system(size: 56, weight: .heavy, design: .rounded)) .monospacedDigit() .contentTransition(.numericText(countsDown: true)) .animation(.snappy(duration: 0.3), value: remaining) Text("剩余时间") .font(.subheadline) .foregroundStyle(.secondary) } } } private var stopwatchSection: some View { TimelineView(.periodic(from: .now, by: 0.01)) { context in let elapsed = context.date.timeIntervalSince(stopwatchStartDate) let hundredths = Int(elapsed * 100) % 100 let seconds = Int(elapsed) % 60 let minutes = Int(elapsed) / 60 Text(String(format: "%02d:%02d.%02d", minutes, seconds, hundredths)) .font(.system(size: 44, weight: .bold, design: .monospaced)) .monospacedDigit() .contentTransition(.numericText()) .animation(.default, value: elapsed) } } }

这段代码里我混用了.snappy和.default，实际上你根据自己的交互风格调整即可。这里有几个细节值得反复琢磨：

第一，TimelineView(.periodic(from: .now, by: 1.0))里的from用的是.now，这意味着调度的起始时间是视图创建的时刻，之后每 1 秒重新求值一次。对于秒表，我把by:设成了0.01，也就是百分之一秒，这样才能显示出毫秒级跳动的效果。

第二，String(format: "%02d:%02d", minutes, seconds)强制分钟和秒钟都显示两位数，这样就杜绝了位数变化带来的宽度突变。就算倒计时从04:59走到04:00，文本宽度始终不变。

第三，.contentTransition(.numericText())配合.animation让每次数字变化都有平滑的滚动过渡。我特意把.animation放在Text之后、容器层级之下，确保动画作用域只覆盖文本本身，不会牵连按钮和标题。

4.3 生命周期与内存优化

别小看生命周期管理，很多"跳动"问题其实是因为旧视图没有销毁、新视图不断叠加导致的视觉混乱。使用TimelineView之后，你就不需要手动 cancel Timer 了，但还有一个场景要留意：TimelineView的闭包里不应该做任何重量级计算，因为它每秒甚至每秒 100 次被调用。比如反序列化、颜色转换、坐标计算这类操作，务必要提前缓存好。

如果界面里还有NavigationLink跳转或者 Tab 切换，最好给TimelineView外层附加.id()让它在视图结构变化时重新建立调度。不过更省事的做法是，把TimelineView独立成一个子视图，这样父视图重绘时不会连带重置调度。

还有个内存上的细节：如果你在TimelineView闭包里捕获了@State属性，注意 SwiftUI 的闭包捕获规则。最常见的问题是，你更新了@State，导致body重新求值，产生了一个新的TimelineView，但旧的调度闭包没有释放，形成隐性循环引用。保证你闭包里不持有任何大型对象，或者用weak捕获非必需的引用即可。

5. 常见问题与排查手记

5.1 计时器在 List 中频繁跳动

SwiftUI 里最让人头疼的场景之一就是List中嵌套计时器。原因在于List本身有虚拟化和复用机制，每个单元格的出现在屏幕上和离开屏幕都会触发生命周期事件。如果你在List的ForEach里直接写一个TimelineView，那么滑动时新出现的单元格会立刻计算差值并渲染，文本从无到有地"长"出来，视觉上就特别跳。

解决办法是把计时器封装成一个独立的TimerView子视图，并且尽量保证单元格尺寸稳定。父列表只负责传递时间戳或 endDate，不关心内部视图的刷新频率。另外，在 List 里就不要再用秒表那种 0.01 秒刷新频率的TimelineView了，用 1 秒甚至是 10 秒的精度的就够了——高频刷新会让列表滚动帧率很难看。

5.2 滚动列表时计时器暂停更新

这个问题我在 2.3 里提过一嘴。如果你还在用Timer.publish(every:on:in:)，注意最后的in:参数。.default模式下，用户滚动List或ScrollView时，系统会将当前 RunLoop 切换到UITrackingRunLoopMode，默认模式的 Timer 事件不会触发，导致 UI 暂停。解决方法就是改成.common。

用TimelineView则完全不受 RunLoop 模式影响，因为它是 SwiftUI 渲染管线的一部分，会跟着视图的刷新节奏走。所以这个坑在TimelineView下不存在，这是另一个推荐它的理由。

5.3 后台切回前台时显示不更新

如果你用的是@State + Timer，应用进入后台后 Timer 事件依然会触发，但 SwiftUI 不会主动渲染，等回到前台时状态已经走了好几十秒，UI 一次性跳到最新值，看起来像"跳表"。如果用的是endDate方案，回到前台时通过时间差值计算出的剩余秒数本来就是正确的，不会出现跳变。唯一需要注意的是，TimelineView是否会在scenePhase回到 active 时立即刷新。实测下来不会立即刷新，需要等下一个调度周期。

解决办法是监听scenePhase，在回到 active 时手动触发一次刷新。你可以用一个.id()绑定到scenePhase状态上，强制重建TimelineView：

@Environment(\.scenePhase) private var scenePhase ... .timelineView(...) .id(scenePhase)

这样切后台再回来，TimelineView会重新创建并立刻以当前时间重新计算，界面即时恢复同步。

5.4 排查速查表

6. 最后的经验与避坑建议

在实际项目里打磨一段时间后，我个人的体会是：SwiftUI 计时器的"跳动"问题，十有八九不是 Timer 本身的锅，而是你让 UI 布局或视图结构为不该改变的事物改变了。抓住"保持文本宽度稳定"和"减少不必要视图重建"这两条原则，大部分问题都能迎刃而解。

最后再分享一个小技巧：如果你做的是一款健身或专注类 App，倒计时结束那一刻往往伴随振动和声音。务必把触发反馈的逻辑放到TimelineView之外，用onChange监听剩余时间从正数变为 0 的事件，否则同一帧里既要重绘文本又要触发反馈，两者叠加容易掉帧。我自己的习惯是单独用一个@State记录"是否已结束"标记，在TimelineView中只负责文本渲染，结束逻辑交给视图之外的事件处理。

还有一点要提醒你：SwiftUI 的版本差异很大，.contentTransition(.numericText())是 iOS 16 才有的，.monospacedDigit()则更早可用。如果你的 App 还要支持 iOS 15，建议用if #available(iOS 16, *)做一下分支处理，否则低版本会直接编译报错。兼容性处理虽然繁琐，但做过一次之后，你会发现这套方案在 iOS 15 和 iOS 16 上都能获得稳定、平滑的计时体验。