处理高频事件流（如 TextField 字符变动或 ScrollView 偏移量监听）时，性能优化的核心目标是：减少不必要的计算开销、防止 UI 线程阻塞以及规避网络请求的“竞态条件”。
设计一个高性能的 Combine 链条，通常需要遵循以下五步法则：
1. 流量节流：选择合适的过滤器
这是防止“下游过载”的第一道防线。
- 输入框搜索（TextField） ：使用
.debounce(for:scheduler:)。它能保证在用户连续打字时保持静默，只有在停顿（如 300ms）后才发送最后的结果。 - 滚动监听（Scroll） ：使用
.throttle(for:scheduler:latest:)。滚动事件每秒可触发 60 次以上，节流可以强制每隔固定时间（如 100ms）只采样一次，大幅降低布局计算频率。
2. 避免冗余：去重处理
在高频流中，即使频率降低了，仍可能产生大量重复值（例如用户删除了一个字符又快速补回，或者滚动回到了同一位置）。
- 使用
.removeDuplicates()。 - 进阶用法：如果处理的是复杂模型，可以自定义闭包：
.removeDuplicates { $0.id == $1.id }。这能确保只有在数据内容真正发生变化时，才触发后续的昂贵操作（如 JSON 解析或视图刷新）。
3. 线程隔离：精准的调度器控制
这是保证 UI 流畅的关键。高频流通常在主线程产生，但复杂的处理逻辑不应占用它。
.subscribe(on:)：控制上游数据产生（如文件扫描、数据库读取）所在的线程。.receive(on:)：将最终结果切回DispatchQueue.main进行 UI 赋值。- 避坑指南：不要在链条中间反复切换线程，这会带来上下文切换开销。
4. 任务竞争管理：使用 switchToLatest
当高频事件触发异步副作用（如网络搜索）时，最怕的是“旧请求比新请求晚到”导致的数据错乱。
- 错误做法：使用
flatMap。它会并行执行所有请求，可能导致 UI 显示旧的搜索结果。 - 正确做法：使用
map返回请求 Publisher，紧跟.switchToLatest()。它会自动取消（Cancel）之前的未完成请求，只保留最后一次。
5. 内存管理：复用与销毁
- 避免在闭包内强引用 self：使用
[weak self]。在高频流中，强引用可能导致对象在应该销毁时仍被链条持有，甚至造成临时性的内存堆积。 - 共享订阅：如果有多个 UI 组件订阅同一个高频流，务必在链条末尾、订阅之前使用
.share()。否则，每多一个订阅者，上游的过滤逻辑和副作用就会多执行一次。
综合实战代码示例：搜索框性能优化
Swift
$searchText
.dropFirst() // 忽略初始状态
.debounce(for: .milliseconds(300), scheduler: DispatchQueue.main) // 1. 防抖
.removeDuplicates() // 2. 去重
.filter { $0.count >= 2 } // 过滤无效短字符
.map { [weak self] text in
// 3. 将搜索逻辑封装为子流，switchToLatest 会自动处理取消逻辑
self?.apiService.search(query: text) ?? Empty().eraseToAnyPublisher()
}
.switchToLatest() // 4. 解决竞态条件
.receive(on: DispatchQueue.main) // 5. 切回主线程更新 UI
.assign(to: &$searchResults)
总结策略
| 操作符 | 核心作用 | 适用场景 |
|---|---|---|
debounce | 停顿后触发 | 搜索框、窗口大小调整 |
throttle | 定时采样 | 滚动条进度、传感器数据 |
removeDuplicates | 相同不触发 | 状态驱动的 UI 刷新 |
switchToLatest | 取消旧任务 | 异步搜索、连续点击跳转 |
buffer | 批处理 | 日志收集、大批量数据落库 |
