Swiftがバージョン5.5でネイティブの並行処理サポートを導入したとき、既存のSequenceプロトコルはすでにIteratorProtocolを通じて同期イテレーションモデルを確立していました。Sequenceプロトコルは、中断なしにすぐに要素を生成する変更可能なnext()関数を返すmakeIterator()メソッドを要求します。この設計は、Swiftのasync/awaitパラダイムよりも前に存在しており、同期的な消費の期待と非同期的な生成能力との間に根本的なインピーダンスミスマッチを生じさせ、平行な階層を必要としました。
コアの対立は、Sequenceのnext()メソッドシグネチャにasyncキーワードを含めることができないことから生じます。もしAsyncSequenceがSequenceを拡張すると、非同期でデータが到着する場合に満たすことができない同期的な要素アクセスの要求を受け継ぐことになります。さらに、同期コードが非同期操作をトリガーすることを許可すると、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() } }
シナリオ: 健康モニタリングアプリでの高頻度センサーデータの処理。
問題の説明: 開発チームは、CoreMotionを使用して転倒を検出するために60Hzで加速度計データをストリーミングする必要がありました。最初、彼らはハードウェアをメインスレッドでタイトなwhileループでポーリングしてセンサーフィードをSequenceとしてモデル化しました。このアプローチはデータ収集中にUIをブロックし、アプリが終了するリスクがありました。彼らは、非同期センサーコールバックをデータ処理パイプラインに統合するための三つのアーキテクチャアプローチを考慮しました。
解決策1: スレッドブロッキングブリッジ。
彼らはカスタムSequenceイテレーター内で同期的な待機を強制するために、非同期センサーAPIをDispatchSemaphoreでラップすることを考えました。
プロ: 標準のArray初期化子とmap/filterアルゴリズムの使用を許可します。
コンサ: 呼び出しスレッドをブロックし、iOSでのウォッチドッグ終了のリスクがあり、スピンによってCPUサイクルが浪費され、スリープ中のキャンセルを防ぎます。
解決策2: コールバックベースのデリゲーション。 彼らは完全にSequenceの準拠を放棄し、各センサー更新のために完了ハンドラーを伴うデリゲートパターンを使用することを考えました。 プロ: 非ブロッキングで、メインスレッドをフリーズさせずに非同期ハードウェアアクセスを許可します。 コンサ: Sequence操作の合成性を失い、変換をチェーンする際に深く入れ子になった「コールバック地獄」を生み出し、バックプレッシャーの実装がほぼ不可能になります。
解決策3: ネイティブAsyncSequenceとAsyncStream。
彼らはCoreMotionのコールバックを続きでAsyncStreamにラップし、for try awaitおよびAsyncAlgorithmsパッケージを使用して処理するとしました。
プロ: Swiftの並行性と統合され、タスクキャンセルをサポートし、throttleおよびdebounce演算子の使用を可能にし、応答性のあるUIを維持します。
コンサ: iOS 13+のデプロイメントターゲットが必要であり、チームは構造化された並行性パターンを学ばなければなりません。
選択された解決策: チームは、CMMotionManagerの更新をAsyncStreamに.bufferingNewest(1)ポリシーでラップする解決策3を採用しました。これにより、データ処理が60Hzのハードウェアサンプリングに遅れた場合に、最新の読み取りのみが保持され、メモリの膨張が防止されました。
結果: 転倒検出アルゴリズムはフルサンプリング周波数を維持し、フレームがドロップされることはなく、CPU使用率はポーリングアプローチと比較して70%低下し、UIは応答性を保ちました。ユーザーがアプリをバックグラウンドにした際には、自動的なTaskキャンセルがストリームイテレーターに伝播され、ハードウェアリソースが適切に解放されました。
質問1: 非同期のforループでラベル付きのbreakやcontinueを使用できますか？その場合、イテレーターはどうなりますか？
回答: はい、ラベル付きの制御フローはfor try awaitループで機能します。ただし、候補者はしばしばライフサイクルの影響を誤解しています。非同期ループからbreakすると、AsyncIteratorはすぐにスコープから外れます。イテレーターが値型の場合、そのdeinitが実行され、ファイルディスクリプタのようなリソースが解放されます。参照型の場合、参照がドロップされます。重要なことに、AsyncSequence自体にはcancel()メソッドはなく、キャンセルはTask階層を通じて処理されます。イテレーターのクリーンアップは、プロトコルがすべてのイテレーターが参照型であることを保証できないため、別のキャンセルハンドラーではなく、そのdeinit内で実装する必要があります。
質問2: なぜArray(myAsyncSequence)初期化子が通常のシーケンスのようにサポートされていないのですか？
回答: Arrayの初期化子は、その引数がSequenceに準拠することを必要としますが、AsyncSequenceには準拠していません。したがって、AsyncSequenceをArrayのコンストラクタに直接渡すことはできません。候補者は、非同期シーケンス専用に設計されたArray初期化子try await Array(myAsyncSequence)を使用する必要があることを見逃すことがよくあります。これは、メンバー初期化子ではなく、グローバルな非同期関数です。なぜなら、Swiftではこのコンテキストで非同期初期化子をサポートしていないからです。この操作は、各next()呼び出しを順次待機してすべての要素を集約し、タスクのキャンセルを尊重し、親Taskがマテリアライゼーション中にキャンセルされた場合にはCancellationErrorをスローします。
質問3: AsyncStreamとNotificationCenterのAsyncSequenceではバックプレッシャーはどのように機能しますか？
回答: これは重要な実装の詳細を明らかにします。AsyncStreamはバックプレッシャーをサポートし、消費者が遅い場合、プロデューサーのyieldの呼び出しは消費者がnext()を呼び出すまで中断されます。これは続きに基づくセマフォを介して実装されています。しかし、NotificationCenterのシーケンスはバックプレッシャーを実装しておらず、無制限のバッファを使用し、消費者がペースを維持できない場合、通知が無限に蓄積されることを許可します。候補者はよく、すべてのAsyncSequence実装が一様にバックプレッシャーを処理すると思い込みます。実際には、AsyncSequenceはプルベースのプロトコルですが、プロデューサーの動作は実装で定義されています。バックプレッシャーを伴うプッシュベースのAPIをプルベースの非同期シーケンスにブリッジするための主要なツールとしてAsyncStreamを理解することが、高スループットシナリオにおけるメモリ枯渇を防ぐために重要です。