Combine 多线程与调度器：掌控数据流的执行线程

调度器（Scheduler）是 Combine 中控制代码执行上下文的核心机制。它决定了发布者在哪个线程或队列上产生值、操作符在哪个线程上执行转换，以及订阅者在哪个线程上接收最终结果。合理地运用调度器能避免 UI 冻结、减少不必要的线程切换，并确保线程安全。本章将系统讲解 Combine 的调度器体系、两个关键操作符 subscribe(on:) 与 receive(on:) 的区别，以及实战中常见问题的解决方案。

1. 调度器概述

在 Combine 中，所有与时间、线程相关的操作都依赖于 Scheduler 协议。一个调度器定义了任务在何时、何地执行。Combine 内置了多种调度器，覆盖了主线程、后台并发队列、串行队列以及测试场景。

1.1 Scheduler 协议

调度器遵循 Scheduler 协议，该协议提供了统一的任务提交接口：

protocol Scheduler {
    associatedtype SchedulerTimeType
    associatedtype SchedulerOptions

    var now: SchedulerTimeType { get }
    var minimumTolerance: SchedulerTimeType.Stride { get }

    func schedule(options: SchedulerOptions?, _ action: @escaping () -> Void)
    func schedule(after date: SchedulerTimeType,
                  tolerance: SchedulerTimeType.Stride,
                  options: SchedulerOptions?,
                  _ action: @escaping () -> Void)
    // ... 其他方法
}

你不必手动实现该协议；Combine 已经为 DispatchQueue、OperationQueue、RunLoop 以及 ImmediateScheduler 提供了现成的实现。

1.2 常用调度器

调度器	特点	典型场景
DispatchQueue.main	主线程串行队列	UI 更新、动画
DispatchQueue.global(qos:)	全局并发队列，可指定 QoS	网络请求、计算
OperationQueue	基于 Operation 的队列，可控制并发数	复杂任务依赖管理
RunLoop.main	主线程运行循环	兼容 Timer 等旧 API
ImmediateScheduler	立即在当前线程同步执行	单元测试

QoS 优先级速查：

• .userInteractive：最高优先级，用于动画、UI 事件
• .userInitiated：用户发起的任务，如点击后加载数据
• .utility：耗时较长但用户可等待的任务，如下载
• .background：后台维护任务，用户不直接感知

2. subscribe(on:) 与 receive(on:) 深度解析

这两个操作符最容易混淆，但它们的作用边界非常明确：

• subscribe(on:) 控制的是上游订阅和工作（包括数据产生）发生的调度器。
• receive(on:) 控制的是下游接收值和完成事件发生的调度器。

2.1 subscribe(on:)

subscribe(on:) 影响的是从订阅开始到数据产生的整条链路。它通常用于将昂贵的操作（如网络请求、数据库读取）移动到后台线程。

fetchData()
    .subscribe(on: DispatchQueue.global(qos: .userInitiated)) // 订阅及后续数据生成发生在后台
    .sink { value in
        print("接收线程：\(Thread.current)") // 仍在后台线程
    }
    .store(in: &cancellables)

要点：

• 链中只有第一个 subscribe(on:) 生效。重复指定不会改变已经设定的上游执行线程。
• 它决定了发布者的 receive(subscriber:) 调用栈所在线程。

2.2 receive(on:)

receive(on:) 设置它之后的所有操作 在哪个调度器上执行，包括值的转换（若在它之后）以及最终的 sink 闭包。它常用于将结果切回主线程刷新 UI。

fetchData()
    .subscribe(on: DispatchQueue.global(qos: .userInitiated)) // 工作线程
    .map { heavyProcessing($0) } // 仍在后台
    .receive(on: DispatchQueue.main) // 接下来的 map 和 sink 在主线程
    .map { formatForUI($0) }
    .sink { [weak self] value in
        self?.updateUI(with: value) // 安全更新 UI
    }
    .store(in: &cancellables)

要点：

• receive(on:) 可多次调用，每次都会改变后续操作的执行线程。
• 它只影响调用位置之后 的操作符和 sink，不会改变上游。

2.3 黄金法则

UI 更新永远在主线程 ，所以任何绑定到 SwiftUI 或 UIKit 的链都必须在 sink 之前放置 .receive(on: DispatchQueue.main)，或者确保在闭包中手动调度回主线程。

3. 实战场景

3.1 网络请求 + UI 更新

最经典的模式：后台执行网络请求，主线程刷新界面。

class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false
    @Published var errorMessage: String?

    private var bag = Set<AnyCancellable>()

    func loadUser() {
        isLoading = true
        errorMessage = nil

        URLSession.shared.dataTaskPublisher(for: userURL)
            .subscribe(on: DispatchQueue.global(qos: .userInitiated))    // 后台订阅和请求
            .map(\.data)
            .decode(type: User.self, decoder: JSONDecoder())
            .receive(on: DispatchQueue.main)                             // 主线程接收
            .sink(receiveCompletion: { [weak self] completion in
                self?.isLoading = false
                if case .failure(let error) = completion {
                    self?.errorMessage = error.localizedDescription
                }
            }, receiveValue: { [weak self] user in
                self?.user = user
            })
            .store(in: &bag)
    }
}

3.2 耗时计算

将 CPU 密集型工作放到后台，完成后再更新 UI。

func computeAndDisplay() {
    Just(())
        .subscribe(on: DispatchQueue.global(qos: .utility))   // 后台计算
        .map { _ -> Int in
            // 模拟耗时计算
            var result = 0
            for i in 0..<1_000_000 { result += i }
            return result
        }
        .receive(on: DispatchQueue.main)                      // 主线程展示
        .sink { [weak self] sum in
            self?.resultLabel = "\(sum)"
        }
        .store(in: &bag)
}

3.3 并行请求合并

Publishers.MergeMany 或 zip 组合多个请求时，可以为每个请求单独设置 .subscribe(on:)，或统一在外层指定。最后别忘了 receive(on:)。

func fetchMultiple(urls: [URL]) -> AnyPublisher<[Model], Error> {
    let publishers = urls.map { url in
        URLSession.shared.dataTaskPublisher(for: url)
            .subscribe(on: DispatchQueue.global(qos: .userInitiated))
            .map(\.data)
            .decode(type: Model.self, decoder: JSONDecoder())
    }
    return Publishers.MergeMany(publishers)
        .collect()
        .receive(on: DispatchQueue.main)
        .eraseToAnyPublisher()
}

4. 线程安全

4.1 CurrentValueSubject

CurrentValueSubject 是线程安全的，可以从任意线程调用 send()，也可以安全地读取 value。这使得它非常适合作为跨线程的状态桥。

let subject = CurrentValueSubject<String, Never>("初始值")

DispatchQueue.global().async {
    subject.send("后台发送的值") // 安全
}

DispatchQueue.main.async {
    print(subject.value) // 读取也是安全的
}

4.2 @Published 与线程

@Published 属性包装器本身不保证线程安全 。它允许从任意线程修改，但发出的通知会在修改属性的那个线程 上触发。如果你在后台线程修改了 @Published 属性，订阅者的闭包也会在后台线程执行，因此必须使用 receive(on: .main) 来确保 UI 更新在主线程。

class Counter: ObservableObject {
    @Published var count = 0
}

let obj = Counter()
obj.$count
    .receive(on: DispatchQueue.main)   // 强制后续处理在主线程
    .sink { value in
        // 此时已安全位于主线程
        print(Thread.isMainThread) // true
    }
    .store(in: &cancellables)

DispatchQueue.global().async {
    obj.count += 1   // 在后台修改，但通知会切换到主线程
}

最佳实践 ：永远为 @Published 的订阅链添加 receive(on: .main)，除非你明确不需要 UI 更新。

4.3 串行队列保护可变状态

当多个线程同时读写一个共享变量时，使用串行队列或 actor 来保护数据。

let queue = DispatchQueue(label: "counter.queue")
var _count = 0
var count: Int {
    get { queue.sync { _count } }
    set { queue.sync { _count = newValue } }
}

5. 性能优化

5.1 减少不必要的线程切换

每次 receive(on:) 都会带来上下文切换开销。应集中进行后台处理，最后一次性切回主线程。

// ❌ 频繁切换
publisher
    .receive(on: main)       // 主线程
    .map { lightOp($0) }
    .receive(on: global())   // 又切回后台
    .map { heavyOp($0) }
    .receive(on: main)       // 再次切回主线程

// ✅ 按工作性质分段，只切换必要的部分
publisher
    .subscribe(on: global())
    .map { heavyOp($0) }     // 全部后台
    .receive(on: main)       // 最终主线程
    .map { lightOp($0) }
    .sink { ... }

5.2 选择合适的 QoS

• 用户点击触发的操作 → .userInitiated。
• 下载、数据库写入 → .utility。
• 后台同步、清理缓存 → .background。

5.3 使用 ImmediateScheduler 进行测试

单元测试中，ImmediateScheduler.shared 会立即在调用线程同步执行，避免了异步等待的复杂性。

let testPublisher = [1, 2, 3].publisher
    .subscribe(on: ImmediateScheduler.shared)
    .map { $0 * 2 }
// 所有操作均在测试线程同步完成

6. 常见陷阱与解决

6.1 在后台线程更新 UI

症状：界面不刷新，或 Xcode 提示 "UI API called on a background thread"。

解决 ：在绑定 UI 前添加 .receive(on: DispatchQueue.main)。

6.2 多次 subscribe(on:) 只生效第一个

原因 ：subscribe(on:) 影响的是上游的订阅过程，链中后续的 subscribe(on:) 对已确立的执行上下文无效。

解决 ：只需在链的开头放置一次 subscribe(on:)。

6.3 主线程阻塞

症状：UI 卡顿。

解决 ：将耗时操作移到 subscribe(on: .global()) 之前或之中，仅将 UI 更新留在主线程。

6.4 死锁

在串行队列上使用 sync 调用自身会造成死锁。Combine 链中一般不会直接引发死锁，但如果在 receive(on:) 指定的串行队列内部同步等待同一个队列的结果，仍有风险。永远不要用 sync 调度到当前执行所在的串行队列。

7. 调度器与时间操作符的结合

时间操作符 debounce、throttle、delay、timeout 都需要指定一个调度器来执行等待和计时。

searchText
    .debounce(for: .milliseconds(300), scheduler: DispatchQueue.main) // 在主线程防抖
    .sink { performSearch($0) }
    .store(in: &bag)

这些调度器通常选择 DispatchQueue.main 以保持 UI 响应，但如果上游在后台，也可以使用自定义队列。

8. 实际项目示例：图片加载器

import UIKit
import Combine

class ImageLoader: ObservableObject {
    @Published var image: UIImage?
    @Published var isLoading = false
    @Published var errorMessage: String?

    private var cancellable: AnyCancellable?

    func loadImage(from url: URL) {
        isLoading = true
        errorMessage = nil

        cancellable = URLSession.shared.dataTaskPublisher(for: url)
            .subscribe(on: DispatchQueue.global(qos: .userInitiated))   // 后台下载
            .tryMap { data, response -> Data in
                guard let httpResponse = response as? HTTPURLResponse,
                      200..<300 ~= httpResponse.statusCode else {
                    throw URLError(.badServerResponse)
                }
                return data
            }
            .tryMap { data -> UIImage in
                guard let img = UIImage(data: data) else {
                    throw URLError(.cannotDecodeRawData)
                }
                return img
            }
            .receive(on: DispatchQueue.main)                            // 主线程更新
            .sink(receiveCompletion: { [weak self] completion in
                self?.isLoading = false
                if case .failure(let error) = completion {
                    self?.errorMessage = error.localizedDescription
                }
            }, receiveValue: { [weak self] image in
                self?.image = image
            })
    }
}

该示例完整示范了后台任务、映射错误和主线程 UI 更新的标准流程。

9. 最佳实践总结

• UI 更新永远在主线程 ：使用 receive(on: DispatchQueue.main)。
• 耗时操作在后台 ：在链开头放置 .subscribe(on: DispatchQueue.global(qos:))。
• 减少线程切换次数：将后台工作集中，只最后切回主线程。
• 为 @Published 订阅添加 receive(on:)：确保 UI 更新安全。
• 利用 CurrentValueSubject 实现跨线程安全。
• 测试时使用 ImmediateScheduler：简化异步测试。
• 避免死锁：不要在串行队列上同步调用自身。
• 合理选择 QoS：根据任务紧急程度匹配。

10. 总结

Combine 的调度器体系为数据流提供了精确的线程控制能力。理解 subscribe(on:) 与 receive(on:) 的职责边界，遵守"主线程更新 UI、后台执行工作"的黄金法则，并针对 @Published 等常见场景做好防护，就能构建出既流畅又稳定的响应式应用。在实际项目中，结合网络层、图片加载等经典案例打磨这些技巧，你会对 Combine 的执行模型了然于胸。