12-11.【SwiftUI】SwiftUI/TCA 中，为什么“State 变化频率”比“State 大小”更危险？

在 SwiftUI 或其高级架构（如 TCA - The Composable Architecture）中，“State 大小”几乎从不是性能瓶颈，而**“State 变化频率”**则是引发掉帧（Jank）、电池发热甚至逻辑 Bug 的核心元凶。

这背后的逻辑深植于 SwiftUI 的渲染管线和值的比较成本。

1. State 大小：值类型的“假象”成本

开发者往往担心一个庞大的 struct 会占用内存或拷贝缓慢。但在 Swift 中，这种担心通常是多余的：

内存开销极低：一个包含几百个字段的 struct 占用的内存也不过几 KB。在现代 iPhone 几 GB 的内存面前，这微不足道。
写时拷贝（COW）优化：Swift 的集合（Array, Dictionary）使用 COW 机制。即使 State 很大，只要你没修改它，拷贝的只是一个指针开销；即使修改了，也只是一次线性的内存移动。
Diff 复杂度：SwiftUI 对视图树的 Diff 复杂度是 $O(N)$ ，其中 $N$ 是视图的数量，而不是 State 字段的数量。

2. State 变化频率：渲染管线的“疲劳驾驶”

相比之下，高频的状态更新会强迫系统在极短时间内完成以下循环：

Body 重新求值：每当状态变一次，对应视图的 body 闭包就要跑一遍。
依赖追踪（Dependency Tracking） ：系统需要对比新旧视图树的属性。
主线程占用：所有的 UI 评估都在主线程。如果状态每秒更新 120 次（比如来自传感器或高频计时器），主线程将没有剩余时间处理用户触摸事件。

3. TCA 中的特殊危险：Reducer 的开销

在 TCA 中，高频状态变化更加危险，因为它比纯 SwiftUI 多了两层开销：

Reducer 遍历：每一个 Action 都会经过 Reducer。如果你高频发送 Action（例如滑动手势的每一像素偏移），Reducer 内部的逻辑（即使是简单的 switch）都会被密集执行。
Effect 调度：高频更新往往伴随着大量的异步 Effect。如果管理不当，这些 Effect 会抢占线程池资源，导致真正的 UI 任务排队。

4. 案例对比：哪个更卡？

场景 A：粗大但低频

状态：一个包含 5000 条图书信息的数组。
动作：用户点击“收藏”，修改其中一个布尔值。
结果：极其流畅。SwiftUI 发现只有这个布尔值变了，只重绘一颗子树。

场景 B：精简但高频

状态：只有一个 Double 类型的 progress。
动作：一个计时器每 5 毫秒（200Hz）更新一次这个值。
结果：UI 掉帧。由于更新频率远超屏幕刷新率（60/120Hz），系统在处理前一个 Diff 时，后两个更新已经到了，导致大量的无效计算。

5. 防御式优化策略

A. 节流与防抖 (Throttling & Debouncing)

对于搜索框输入或滚动偏移，必须进行处理。

在 TCA 中，使用 .debounce(id:for:scheduler:)。
在 Combine 中，使用 .throttle(for:scheduler:latest:)。

B. 状态切片 (ViewStore Selection / View State)

在 TCA 中，不要让 View 观察整个 Store。使用 scope 或 observe 仅订阅你需要的字段。

原则：如果一个 View 只关心 id，那么 name 的变化不应触发该 View 的重绘。

C. 使用 Observation 框架 (Swift 5.9+)

升级到新的 @Observable 宏。它实现了字段级追踪。这意味着即使你把整个对象传给 View，如果 View 的 body 没读过那个高频变化的字段，它就永远不会重绘。

总结

“State 大小”是静态的，可以通过增加内存轻松解决；“State 变化频率”是动态的，它直接消耗最宝贵的计算资源——主线程时间。

12-11. [SwiftUI/TCA] Why is "State Change Frequency" more dangerous than "State Size"?

In SwiftUI or advanced architectures like TCA (The Composable Architecture) , "State Size" is almost never the performance bottleneck. Instead, "State Change Frequency" is the primary culprit behind dropped frames (jank), battery drain, and even logical bugs.

The reasoning behind this is deeply rooted in the SwiftUI rendering pipeline and the cost of value comparison.

1. State Size: The "Illusion" of Cost

Developers often worry that a massive struct will consume too much memory or be slow to copy. In Swift, this fear is usually misplaced:

Negligible Memory Overhead: A struct containing hundreds of fields still only occupies a few KB of memory. Compared to the several GBs of RAM in a modern iPhone, this is insignificant.
Copy-on-Write (COW) Optimization: Swift collections (Array, Dictionary) use COW. Even if the state is huge, if you haven't modified it, the "copy" is just a pointer overhead. Even when modified, it's a linear memory move that is extremely fast.
Diff Complexity: The complexity of SwiftUI’s view tree diffing is $O(N)$ , where $N$ is the number of views, not the number of fields in your state.

2. State Change Frequency: "Fatigue" in the Pipeline

In contrast, high-frequency state updates force the system to complete the following cycle in an incredibly short window:

Body Re-evaluation: Every time the state changes, the body closure of the corresponding view must run.
Dependency Tracking: The system must compare properties of the new and old view trees.
Main Thread Saturation: All UI evaluations happen on the Main Thread. If the state updates 120 times per second (e.g., from high-frequency sensors or timers), the main thread will have no time left to process user touch events.

3. Special Dangers in TCA: Reducer Overhead

In TCA, high-frequency state changes are even more dangerous because they add two layers of overhead compared to vanilla SwiftUI:

Reducer Traversal: Every Action passes through the Reducer. If you send Actions at a high frequency (e.g., for every pixel of a drag gesture), the internal logic of the Reducer (even a simple switch) is executed intensely.
Effect Scheduling: High-frequency updates are often accompanied by a large number of asynchronous Effects. If managed poorly, these Effects can saturate the thread pool, causing actual UI tasks to queue up.

4. Case Comparison: Which is Laggier?

Scenario A: Bulky but Low Frequency

State: An array containing 5,000 book records.
Action: User taps "Favorite," toggling one Boolean value.
Result: Extremely smooth. SwiftUI detects that only one Boolean changed and redraws only a tiny subtree.

Scenario B: Slim but High Frequency

State: A single Double representing progress.
Action: A timer updates this value every 5 milliseconds (200Hz).
Result: UI Stutter. Since the update frequency exceeds the screen refresh rate (60/120Hz), the system receives new updates while still processing the previous Diff, leading to massive wasted computation and frame drops.

5. Defensive Optimization Strategies

A. Throttling & Debouncing

For search box inputs or scroll offsets, processing must be handled.

In TCA, use .debounce(id:for:scheduler:).
In Combine, use .throttle(for:scheduler:latest:).

B. State Slicing (ViewStore Selection)

In TCA, do not let a View observe the entire Store. Use scope or observe to subscribe only to the specific fields you need.

Principle: If a View only cares about id, then a change to name should never trigger that View’s redraw.

C. Use the Observation Framework (Swift 5.9+)

Upgrade to the new @Observable macro. It implements field-level tracking. This means even if you pass the entire object to a View, if the View’s body never reads a high-frequency field, it will never redraw when that field changes.

Summary

"State Size" is static and easily solved with memory; "State Change Frequency" is dynamic and directly consumes the most precious resource—Main Thread time.