当Swift在5.5版本中引入原生并发支持时，现有的Sequence协议已经通过IteratorProtocol建立了同步迭代模型。Sequence协议要求一个makeIterator()方法返回一个变异的next()函数，该函数立即生成元素而不进行挂起。这个设计是在Swift的async/await范式之前创建的，造成了同步消费期望与异步生产能力之间的基本阻抗不匹配， necessitating并行层次。
核心冲突在于Sequence的next()方法签名不能包含async关键字。如果AsyncSequence要缩小Sequence，它将继承对同步元素访问的要求，这在数据从网络I/O或计时器异步到达时是不可能满足的。此外，允许同步代码触发异步操作将违反Swift的结构化并发保证，可能允许异步代码在Task上下文之外运行，并打破运行时的层次取消传播。
Swift架构师创建了一个独立的协议层次，AsyncSequence不继承自Sequence。AsyncIteratorProtocol定义了mutating func next() async throws -> Element?，明确在类型签名中标记挂起点。这个隔离确保了迭代只能在异步上下文中发生，允许Swift运行时管理续接，处理任务取消，并正确保存调用栈，同时防止同步代码意外调用依赖于挂起的操作。
// 尝试混合同步和异步（说明性失败） protocol BrokenAsyncSequence: Sequence { // 不能同时满足同步IteratorProtocol.next()和异步要求 } // 正确的异步设计 struct TimedEvents: AsyncSequence { typealias Element = Date struct Iterator: AsyncIteratorProtocol { var count = 0 mutating func next() async -> Date? { guard count < 5 else { return nil } count += 1 await Task.sleep(1_000_000_000) // 挂起点 return Date() } } func makeAsyncIterator() -> Iterator { Iterator() } }
场景：在健康监测应用中处理高频传感器数据。
问题描述：开发团队需要以60Hz的速度流式传输加速度计数据，以检测摔倒，使用CoreMotion。他们最初将传感器数据源建模为Sequence，在主线程中使用紧密的while循环轮询硬件。这种方法在数据收集期间阻塞了UI，并有导致应用程序终止的风险。他们考虑了三种架构方法来将异步传感器回调与数据处理管道集成。
解决方案1：线程阻塞桥接。
他们考虑将异步传感器API包装在DispatchSemaphore中，以强制同步等待一个自定义的Sequence迭代器。
优点：允许使用标准Array初始化程序和map/filter算法。
缺点：阻塞调用线程，冒着iOS上看门狗终止的风险，浪费CPU周期，同时防止在睡眠期间取消。
解决方案2：基于回调的委托。 他们考虑完全放弃Sequence的符合性，使用带有完成处理程序的代理模式来处理每个传感器更新。 优点：非阻塞，允许异步硬件访问而不冻结主线程。 缺点：失去了Sequence操作的可组合性，在链接转换时产生深度嵌套的“回调地狱”，且使得反压实现几乎不可能。
解决方案3：原生AsyncSequence与AsyncStream。
他们将CoreMotion回调包装在一个使用续接的AsyncStream中，然后使用for try await和AsyncAlgorithms包进行处理。
优点：与Swift并发集成，支持任务取消，使得使用throttle和debounce运算符成为可能，并保持响应性UI。
缺点：需要iOS 13+的部署目标，团队必须学习结构化并发模式。
选择的解决方案：团队采用了解决方案3，将CMMotionManager更新包装在带有.bufferingNewest(1)策略的AsyncStream中。这确保了如果数据处理滞后于60Hz硬件采样，只有最新的读数被保留，从而防止内存膨胀。
结果：跌倒检测算法在不丢帧的情况下保持完整的采样频率，与轮询方法相比，CPU使用率下降了70%，UI保持响应。系统在用户由于自动Task取消传播到流迭代器而将应用程序置于后台时，得当释放了硬件资源。
问题1：我可以在异步for循环中使用带标签的break或continue吗？对迭代器会发生什么？
回答：是的，带标签的控制流在for try await循环中可以正常工作。然而，候选人常常误解生命周期的影响。当您从异步循环中break时，AsyncIterator会立即超出范围。如果迭代器是值类型，它的deinit会运行，释放文件描述符等资源。如果它是引用类型，引用将被丢弃。至关重要的是，AsyncSequence本身没有cancel()方法；取消通过Task层次结构处理。迭代器的清理必须在其deinit中实现，而不是在单独的取消处理程序中，因为协议不能保证所有迭代器都是引用类型。
问题2：为什么AsyncSequence不支持像常规序列那样的Array(myAsyncSequence)初始化程序？
回答：Array的初始化程序要求其参数符合Sequence，而不是AsyncSequence。由于AsyncSequence没有缩小Sequence，因此不能直接传递给Array构造函数。候选人常常忽视您必须使用专为异步序列设计的Array初始化程序：try await Array(myAsyncSequence)。这是一个全局异步函数，而不是组成初始化程序，因为Swift在这个上下文中不支持异步初始化程序。该操作通过按顺序等待每个next()调用聚合所有元素，并尊重任务取消，在物化期间如果父Task被取消则抛出CancellationError。
问题3：反压是如何在AsyncStream与NotificationCenter的AsyncSequence中工作的？
回答：这揭示了一个关键的实现细节。AsyncStream支持反压：如果消费者缓慢，生产者的yield调用会挂起，直到消费者调用next()。这是通过基于续接的信号量来实现的。然而，NotificationCenter的序列不实现反压；它使用一个无限制的缓冲区，允许通知无限积累，如果消费者无法跟上。这使得候选人常常假设所有AsyncSequence实现都以统一的方式处理反压。现实是AsyncSequence是一个基于拉取的协议，但生产者的行为是实现定义的。理解AsyncStream是将推式API桥接到具有反压的基于拉动的异步序列的主要工具，对于防止在高吞吐量场景中内存耗尽至关重要。