Swiftのasync/awaitについて

Swiftは非同期関数をサポートするようになりました - 一般にasync/awaitとして知られているパターンです。新しい構文でどのようにコードが読みやすく、理解しやすくなるかをご確認ください。関数がサスペンドする際に起きる事柄を学び、既存のコンプリーションハンドラを非同期関数に適応させる方法を説明します。

リソース

関連ビデオ

WWDC22

WWDC21

ダウンロード

♪ ♪ Nateです Swiftチームのエンジニアをしています本日 Robertとともにお伝えするのはSwiftの async/awaitについてです非同期のプログラミングは皆さんの多くが日常的に行っていることでしょうそのため書いてしまいがちな冗長で複雑な非同期コード間違うことさえありますそれに役立つのはSwiftの async/awaitです async/awaitを使えば通常のコードと同様に非同期コードを簡単に書くことができますそれによりアイデアはさらにコードに反映され安全性も高まりますさらにSDKには待機可能なメソッドが数多くあります例えばUIKitにあるのは UIImageからのサムネイル作成機能です実際そのタスクを行う同期と非同期両方の関数があります

簡単にご紹介しましょう同期型の関数つまり通常の古い関数を呼び出すとスレッドはブロックされその終了を待たなければなりませんつまり fetchThumbnail関数は UIKitの同期型関数である preparingThumbnailを呼び出すためスレッドでは終了まで何も実行できなくなるのですその一方 prepareThumbnail (of:completionHandler:)の非同期版を関数の実行中に呼び出してもスレッドでは他の作業を実行できます作業が完了したら完了ハンドラを呼び出して通知します SDKには多くの非同期機能がありいくつかの方法で完了を知らせてくれますこのように完了ハンドラを使う場合もあればデリゲートをコールバックする場合もあります多くは非同期と表示され値が返されるだけですこれらの非同期関数に共通しているのは関数を呼び出すと作業を開始したスレッドのブロック解除が即座に行われるという点です長時間に及ぶ作業を行っている間にそのスレッドで他の作業を完了させることができます違いを確認するため多くの方がよく目にする例を見てみましょう Robertと私が構築中のAppにあるアイテムリストの各行にはサーバーに保管されている画像をサムネイルとして表示していますサムネイルをリストに表示する準備ができたらビューモデルでは fetchThumbnailメソッドが呼び出され一連の手順で文字列はUIImageに変換されますまずビューモデルの thumbnailURLRequest メソッドが文字列からURLRequestを作成します次に URLSessionの dataTaskメソッドがそのリクエストデータを取得します UIImage initWithDataによりデータから画像が作成され最後に UIImage prepareThumbnailメソッドで元の画像のサムネイルが表示されます各操作はそれぞれ前の操作結果により決定されますつまり正しい順序で行わなければなりません

操作の中には文字列からのURLRequest作成データからのUIImage作成など素早く値を返すものもあり関数を実行中のスレッドでも問題はありませんこれらは同期的呼び出しとなりますが時間がかかるものもあります画像を構成するデータのダウンロードがそうですまた見栄えのするサムネイルに仕上げるには作業に時間をかけなければなりませんそのため SDKにはこれらのタスクを行うための非同期関数がありますそのためこの呼び出しは非同期で行う必要があります Robertと私が async/awaitを試みる前は完了ハンドラを使用して関数を書いていました

この関数では引数としての文字列最初の操作への入力と呼び出し元に返すための完了ハンドラを受け取ります fetchThumbnailが呼び出された場合 thumbnailURLRequestを最初に呼び出しますこのメソッドは同期型なので完了ハンドラは必要ありません次に dataTaskを共有されたURLSession インスタンスで呼び出し URLRequestと完了ハンドラを渡します URLSessionDataTaskが同期的に生成されると処理が再開され非同期の作業が開始されます fetchThumbnailが戻るとスレッドでは他の作業を行うことができます大きな問題となるのは画像のダウンロード中にデータのストリーミングを待機しているスレッドをブロックしたくないということです最終的に行きつくのは画像のダウンロード終了か問題発生のどちらかですいずれにしてもリクエストは完了し dataTaskに渡された完了ハンドラがオプションの値とともに呼び出されますそれらはデータレスポンスエラーなどです問題が発生した場合は完了ハンドラを呼び出しエラーを通知する必要があります問題がなかった場合UIImageの initWithDataを使用してデータから画像を作成しますこれらは同期型なので結果を処理するためには一般的な直線的コードを書きます画像が生成されない場合は終了です画像が生成された場合は最後に UIKitのprepareThumbnailメソッドを呼び出し完了ハンドラを渡します作業を仕上げる間スレッドのブロックは解除され他の作業が可能になります

サムネイルが生成された後サムネイルの準備に成功した場合完了ハンドラは画像とともに呼び出されるか nilとなります成功した場合完了ハンドラを呼び出し画像を渡します

ですが Robertが指摘したように問題があります fetchThumbnailの呼び出し元は作業終了の通知を要求します失敗した場合も同様です現在は呼び出し元を放置している状態です私は“guard else return”と書くことに慣れ過ぎてしまい完了ハンドラの呼び出しを２度も忘れた事がありますつまりデータからのUIImage生成やサムネイル作成の失敗などは fetchThumbnailの呼び出し元に通知されずそのため行がアップデートされることはありませんスピナーが表示され続けるだけです

そのため fetchThumbnailの制作者としてとても重要なのはどんな状況でも呼び出し元に通知するということですつまり関数を介したすべてのパスによって通知される必要があるのですそれにはエラー発生時に完了ハンドラを呼び出しそのエラーを渡さなければなりません通常の関数の場合通知することで呼び出し元にエラーを返します Swiftの場合関数を介した実行の進み具合にかかわらず値が返されない場合は確実にエラーが通知されますしかし Swiftでの通常のエラー処理方法は使えません問題が発生した場合これらの完了ハンドラの中からエラーを通知することはできません残念ですが Swiftに作業を確認させることはできません Swiftにとって fetchThumbnailのような完了ハンドラはクロージャにすぎません常に起動していることを確認したくとも Swiftには起動を強制する手段がありませんだからこそ例の２つのガードから戻った際コンパイルエラーは出ませんでした Robertが指摘してくれたおかげで解決することができましたそのため完了ハンドラが呼び出されるかどうかは最終的にあなた次第です私たち２人がこの関数を書いた時にはいくつかの操作を次々に行いたいと思っていました２つは同期型２つは非同期型で完了ハンドラを使用します成功はしましたが最終的に約20行のコードにはわずかなバグの可能性が５ヶ所にありました私たちが求めたものは４つの操作を順番に行うことでしたが成果としては順に実行することも正しく実行することも難しく意図は曖昧な状態です

しかし安全性を少し高める方法はあります例えば標準ライブラリのresult型を使うこともできましたこれで安全性は高まりますが形式を追加することでコードは見苦しくやや長くなります先物のような技術を使い非同期コードを別の方法で改善した人もいますしかしこれらの方法ではシンプルで簡単安全なコードは書けません async/awaitを使えばさらに改善できます私たちは関数を書き直しました４つの手順を実行するものにそして今回は async/awaitを使用しました

この関数も同様に文字列を引数として受け取ります先ほどは完了ハンドラも渡していましたが今回は代わりに関数が非同期となっています関数を非同期にする場合関数シグネチャである "throws"の直前にキーワードを入れます関数が通知されない場合は矢印の前に入れます関数を非同期にすることで関数とそのシグネチャをよりシンプルにできます画像のサムネイル作成に成功した場合サムネイルはそのまま返されますエラーが発生した場合はそのまま通知されます fetchThumbnailが呼び出されると引きつづき thumbnailURLRequestが呼び出されますこの関数は同期型なのでスレッドはブロック状態で作業をしています

次に共有のURLSession上で data(for: request)を呼び出しデータをダウンロードします dataTask 同様 Foundation によるメソッドのためこちらも非同期ですしかし dataTaskとは異なり dataメソッドは待機可能ですそのため呼び出した後は一時停止しスレッドのブロックを解除しますするとスレッドで他の作業が可能となります

データメソッドの"throws"が "try"を導いています以前のバージョンではエラーを確認してから完了ハンドラを明示的に呼び出す必要がありました待機可能版ではこれらのコードはすべて “try”キーワードだけに集約されています "try"で呼び出せる関数が"throws"と書かれているのと同様に "await"で呼び出される関数には "async"と書かれています式の中に複数非同期関数の呼び出しがある場合 "await"の書き込みは一度だけで問題ありませんそれは関数の呼び出しを複数行っている式でも "try"の書き込みが一度で済むのと同様ですつまり関数呼び出しには "try await"と書かれます通知する非同期の式を扱う場合 “await”の前に“try”を置く必要があります

最終的にデータのダウンロードが終了すると dataメソッドは再開され fetchThumbnailに戻りますその時データメソッドが返す値または通知されるエラーの値ですエラーが通知された場合 fetchThumbnail自身にも同様にエラーが通知されますその他の場合データと応答変数は定義されますこれは以前のバージョンで起動されたURLSessionの dataTaskメソッドに完了ハンドラが渡された時の fetchThumbnailと同様です

どちらのバージョンでも URLSessionの非同期メソッドで生成された値やエラーは現れましたしかし待機可能版はさらにシンプルです私たちの言いたいことをそのまま伝えてくれますリクエストを実行し戻ってきた値を変数に代入することで使用可能となり問題が発生した場合にはエラーを通知します

次に fetchThumbnailでダウンロードしたデータから UIImageを作成してみます成功した場合プロパティにアクセスすることでその画像のサムネイルが表示されますサムネイル生成の間そのプロパティが最終的に再開して fetchThumbnailに戻るまでスレッドでは他の作業が可能です

サムネイルが表示されると fetchThumbnailで返されるかエラーが通知されます完了ハンドラ版とは対照的にサムネイルが表示されない時 Swiftでは確実にエラーを通知するか値を戻しますが黙って失敗もできません以上ですこれが必要なコードの全貌です関数については以前の完了ハンドラ版とまったく同様ですしかしコードは20行でなくたったの６行ですまた全て直線的コードです正しい順序で実行すべき４つの操作が次々とリストアップされますまた Swiftでは問題が発生した場合にそれを戻すか通知することで関数の終了を確実に呼び出し元に通知しますこれは一例であり async/awaitの使用により非同期のSwiftコードをより安全により短くより意図を反映したものに変換できるのですそれではfetchThumbnailの実行方法について詳しくご紹介します最後から２行目に関数の呼び出しはありませんがサムネイルの表示を始める式には“await”と書かれていますサムネイルのプロパティが非同期のためです関数以外も非同期にできますプロパティもイニシャライザと同様に可能ですサムネイルのプロパティは現在 SDKには含まれません実は Robertが追加してくれました見てみましょう

このプロパティはUIImageの拡張機能で定義されその実装は短整数です CGSizeを生成し byPreparingThumbnail(ofSize) に渡した結果を待ちますちなみにselfでのこのメソッドは先ほど使用したメソッドの待機可能版です

いくつか注意すべき点もあります第一に明示的なゲッターについてですこれはプロパティを非同期にするために必要です Swift 5.5ではプロパティのゲッターも通知されます非同期関数のシグネチャと同様にプロパティが asyncかつthrowsである場合 “async”キーワードは “throws”の直前に入ります

次にプロパティにセッターがない場合読み取り専用プロパティのみ非同期にできます

関数プロパティイニシャライザにおいて awaitを式で使用することで関数がブロック解除する可能性があるスレッドを示すことができます awaitには別の使用法もあります非同期シーケンスを反復するループ処理などです非同期シーケンスはエレメントの送信が非同期であることを除けば通常のシーケンスと同じですそのため次のアイテムを取り出す際には awaitを付けて非同期だと示す必要があります

関数が非同期シーケンスを何度もくり返すことで次のエレメントを待つ間にスレッドのブロックが解除されますその後次のエレメントでループ本体に移動するかエレメントがない場合はループ処理の後に再開されます

AsyncSequenceについての詳細は「AsyncSequenceについて」ををご覧くださいまた多くの非同期タスクを同時に実行したい方は「Swiftにおける構造化並行処理」をご覧ください

awaitを使える場面はたくさんありますこのキーワードには非同期関数が停止される可能性があります非同期関数が停止されるとは？それに答えるには関数を呼び出した時のことを考えてみましょう任意の関数を呼び出した場合関数を実行しているスレッドのコントロールを呼び出した関数に渡します通常の関数 thumbnailURLRequestなどを呼び出す場合スレッドはその関数に代わって作業を実行し関数が終了するまでは他の作業を行えません

その作業は関数本体またはその関数が呼び出す他の関数で行われます最終的にその関数が終了する時には値が返されるかエラーが通知されますそうしてコントロールが関数に戻されますこの唯一の方法により通常の関数はスレッドのコントロールを渡し終了となりますそれは関数によってのみコントロールが可能です非同期関数の呼び出しの場合状況は異なります通常の関数と同様に完了すると終了して関数にコントロールが戻されますしかし通常の関数とは全く異なる方法でスレッドのコントロールを渡しますつまりサスペンドです

通常の関数と同様にスレッドのコントロールは呼び出した非同期関数に渡されます

実行が始まると同期関数は停止可能になりますそうなるとスレッドのコントロールは渡されますしかしスレッドのコントロールは関数ではなくシステムに戻されますそうなると関数も停止してしまいますサスペンドとは関数をシステムに伝える手段ですやるべき作業がたくさんあるので最重要事項を決定してください” とても協力的ですそのため関数が停止されるとシステムはスレッド上で他の作業を実行できますある時点で先に中断した非同期関数を続けて実行することが最重要であるとシステムは判断しその時点でシステムは再開しますすると非同期関数はスレッドのコントロール下に戻り作業の続行が可能になります必要であれば再度の停止も可能です実際停止は何度でも可能です逆に停止の必要が全くない場合もあります非同期関数に停止の可能性はありますが asyncと書かれていても停止しない場合もあります同様に “await”と書かれていても確実に関数が停止されるわけではありませんしかし最終的には停止せずにまたは最後に再開した後でもその関数は終了し値やエラーとともにスレッドのコントロールを関数に戻します

fetchThumbnailのサスペンド時に起きる事をもう一度確認してみましょう

fetchThumbnailが呼び出す URLSessionの非同期データメソッドのみが可能な方法でスレッドの実行が停止されることこれがサスペンドでありスレッドのコントロールをシステムに委ね URLSessionのdataメソッドの作業をシステムに組み込みますしかしこの時点でシステムはコントロールされておりすぐに作業が始められない可能性があります代わりにスレッドを他の作業にあてることができます実際に見てみましょう fetchThumbnailが呼び出された後データのアップロードのためユーザーがボタンをタップしたと想定します例えばあるポストに反応したとしましょうするとシステムは先にキューイングされた作業の前にユーザーの反応を書き込む作業が可能になります

直前の作業が完了すると URLSessionのdataメソッドを再開することができますまたはシステムが別の作業を実行することもあります最後にdataメソッドが終了すると再び fetchThumbnailに戻ります関数の停止時に他の作業を実行するため Swiftは awaitを使用した非同期での呼び出しの書き込みを求めます関数の停止時はAppの状態が大きく変わる可能性があるのでご注意ください

ちなみにこちらは完了ハンドラを使用する場合にも当てはまりますしかしasync/awaitコードに伴う形式やインデンテーションはないためコードブロックがトランザクションとして実行されないことはキーワードの awaitによって通知されます関数が停止したり関数の行間での停止時に別の事態が起こる可能性もありますそれだけでなく全く別のスレッドで関数が再開されることもあります「Swiftアクターによるミュータブルステートの保護」をご覧くださいここでasync/awaitの重要事項を紹介しますまず関数にasyncと書くことでその関数は停止が可能になります関数自体による停止は呼び出し元も停止させますつまり呼び出し元も非同期である必要があります次に非同期関数の中で停止する可能性がある箇所を指摘するために “await”が使われます第３に非同期関数の停止時スレッドはブロックされていませんシステムは他の作業を組み込むことが可能です後から開始された作業でも先に実行することができますつまり関数の停止時に Appの状態が大きく変化する可能性があります最後に非同期関数が再開すると呼び出された非同期関数が返す結果は元の関数に戻され中断したところから実行は再開されます Swiftでのasync/awaitの仕組みを見てきました次に Robertからプロジェクトでの活用方法を紹介してもらいますありがとう Nate 先ほど私たちが構築中の Appをご紹介しました async/await採用のために変換したthumbnail関数は複数の場面で呼び出されたため並行処理を行うためにもそれらの移行が必要です現代のソフトウェア開発における必須事項から始めましょうそれはテストです非同期コードのテストを同期コードと同様に行うため革新的な XCTestによる非同期のサポートが行われます以前は期待値を設定しテスト対象のAPIを呼び出し期待値を満たし任意の時間待つという面倒なプロセスでしたが今後はテストを行う関数に “async”を追加しXCTestの期待値やその実行結果明示的なawaitを削除し先ほどNateから紹介があった非同期のfetchThumbnail関数の呼び出し結果を待つことになります

テストについては終わり Appコードを見てみましょう注目はリスト各行のサムネイル表示の背後にあるSwiftUIコードです

画像セルはポストごとに作成され各ポストのIDを viewModelに渡すことで非同期でのサムネイル取得が可能となりますテストコードから呼び出しを変換する方法はすでにご覧いただきましたでは試してみましょうまず完了ハンドラを削除しエラーを処理する“try”と非同期関数の呼び出しを完了する“await”を追加しますしかしこのコードはうまく作成できません Swiftのコンパイラによるとそれ自体が非同期ではないため非同期関数を呼び出せないということですここではonAppearの修飾子が非同期かつプレーンなクロージャを取っているため同期と非同期のギャップを埋める方法が必要になります

解決するには非同期のタスク関数を使用します非同期タスクとはクロージャ内の作業をまとめてシステムに送り次に利用可能なスレッドでの実行を準備するものでグローバルディスパッチキューの非同期関数と同様ここでの主な利点は同期コンテキストの中から非同期コードを呼び出すことができる点です

作成し直すことでコンパイラは成立します非同期タスクは API系統に不可欠な要素で使いやすく自然に構造化されたスタイルで内容豊富な並列の Swiftコード作成が可能です「Swiftにおける構造化並行処理」をご覧くださいまた SwiftUI Appでの非同期コード活用法は「SwiftUIでの並行処理」をご覧ください

fetchThumbnail関数を呼び出していた場所の移行はすべて終了していますしかし Appにasync/awaitを採用する機会は多くありますすぐに運用を開始するために既存のAPIへの非同期の代替手段導入から始めることをお勧めします SDKには完了ハンドラを使用する多くのAPIがあり我々に代わって非同期的に作業を行いますこれらのAPIを並べてみるとパターンが見えてきます

これらの機能は名称や目的が異なっていてもAPIコントラクトは本質的には同じですそれらを呼び出すと提供された完了ハンドラを使用して呼び戻され得られた結果が渡されます先ほど Nateから紹介があったように非同期関数の結果を待つことでより自然なコードを書くことができますコールバックブロックを非同期関数に変換できたら素晴らしいですよね Swift 5.5ではまさにこれが実現しました SwiftのコンパイラはObjective-Cからインポートされた完了ハンドラのコードを自動的に確認し非同期の代替手段を提供しますそれだけではありませんデリゲート型APIにも完了ハンドラを渡すメソッドが多くありますハンドラを呼び出すと非同期タスクが完了した時点でフレームワークに協調的に通知されます例えば ClockKitの複雑なデータソースでは fetchThumbnailを呼び出して規定のポストのタイムラインエントリを表示します

先ほど同様すべてのパスで完了ハンドラを呼び出す必要がありますがクロージャが原因となり不必要なノイズも多く存在しています

async/awaitではそうはなりませんこのデリゲートメソッドには代わりに使用できる非同期の代替手段がありますまず非同期の代替手段の名前として使用するため先頭の“get”を削除します非同期関数では呼び出しの結果が直接返されないことを知らせる“get”などの先頭の語を削除することをお勧めします結局のところ非同期の代替関数のためタイムラインエントリは直接返されます非同期コンテキストを設定したので非同期版のfetchThumbnailを呼び出します最後にタイムラインエントリをメソッドから返し削除済の完了ブロックの呼び出しは行いません

ご紹介した非同期型APIはほんの一部に過ぎません APIそのものやasync/awaitを採用する際の使い方についての詳細はこちらのセッションをご覧ください

これらすべては Swiftがあなたに代わって非同期の代替手段を作成する状況の例ですしかしコードの中には非同期の代替手段を自分で作らなければならない場所が必ずあります

どのようなものか実際に見てみましょう

このAppでは getPersistentPosts関数を使い Core Dataの記憶装置に永続化したポストを取得しますこの関数は App内での呼び出しが非同期のサムネイル関数よりも多くすべての場所で非同期を使用するという点で大きな変更ですまた我々が使用している NSAsynchronousFetchRequest という関数は非同期の代替手段として完璧な候補と言えそうですまず非同期関数を作り戻り値を変換しますこの関数にはエラー発生の可能性があるのでこの関数にも“throws”と書きます

次に完了ハンドラ版の getPersistentPostsを呼び出しますがこれではうまくいきません

コールバックの結果を非同期のpersistentPosts関数の呼び出しを待っている場所に戻す必要がありますそれだけでなく呼び出し元は停止状態です私たちは適切なタイミングと適切なデータで復帰させ他の作業を実行可能にしなければなりません

先ほど Swiftとシステムが共同で行う非同期コードの復帰処理の様子を紹介しましたサスペンドとリジュームのプロセスがどのように機能するかを知ることで問題解決のヒントがあるかもう少し見てみましょう

非同期版のpersistentPostsが呼び出されCore Dataを呼び出しますその後 Core Dataは完了ハンドラを呼び出しフェッチリクエストの結果を渡しますこちらは先ほど紹介した fetchThumbnail関数が停止した非同期関数呼び出しの再開を Core Dataではなくシステムに要求した時の状況とほぼ同じです

あとは完了ハンドラを待ちフェッチリクエストの結果を伴って再開するためのブリッジが必要ですこのパターンはよく現れるものでその名前を“継続”といいます今回のセッションではNateと私から継続についての多くの例をご紹介しましたそれは完了ブロックをとるメソッドでした

メソッドの呼び出し元は関数呼び出しの結果を待ち次に何をすべきかを指定するクロージャを提供します関数の呼び出しが完了すると完了ハンドラが呼び出され結果に対して呼び出し元が要求するすべての作業が再開されますこのような協調実行は Swiftにおいて非同期が機能する仕組みとまったく同じですこれを明確にするために Swiftにはハイレベルかつ安全な方法で継続処理を作成管理再開できる機能があります

先ほどの例に戻り継続処理がどのようにして非同期の代替手段を書くのに役立つかを見てみましょう

withCheckedThrowing－ Continuation関数はエラーが発生した完了ブロックを Swiftの非同期型スローイング関数までリフトします withCheckedContinuationsは関数が絶対にエラーを出さないとわかっている状況に対応するものですこれらの関数は停止された非同期関数を再開するために使用可能な継続の値にアクセスするための手段ですこれでgetPersistentPostsの呼び出し待機が可能となりブリッジの最初の部分も構築されます

それではブリッジを完成させましょう継続の値により完了ハンドラからの結果を置くためのレジューム関数が提供されます加えてレジュームは persistentPosts関数の結果の呼び出し停止を解除するために必要なミッシングリンクを提供しますこれで適切なパッケージに完了ハンドラから非同期関数への完成したブリッジが作られます

継続処理とは強力な方法であり非同期関数の実行を手動でコントロールするものですが注意すべき点がいくつかあります継続にはシンプルかつ重要なコントラクトがあることレジュームは各パスで確実に１回呼び出すことですが心配は無用です Swiftはあなたの味方です

レジュームが呼び出されずに継続が破棄された場合 Swiftのランタイムは警告を記録し非同期の呼び出しが停止されることはありませんしかし同一関数内で複数回継続が再開された場合はより深刻なエラーとなりプログラムデータが破損する可能性がありますこの問題に対処するため Swiftのランタイムはレジュームの複数回呼び出しを検出し２回目の再開点で決定的なエラーが発生するようにします

これを念頭に置いてチェックされた継続を使用する可能性のある別の重要な場所を紹介しましょう

APIの多くはイベント駆動型ですデリゲートコールバックをすることでこれらは特定の重要なポイントでAppに通知し Appが適切に対応できるようにします async/awaitを適切に採用するためには継続を保存して後で再開する必要があります先ほど同様チェックされた継続を作成します

その後それを保存し作業を開始します

チェックされた継続の APIコントラクトを優先するために作動中の継続を確実に再開し最後にnilにすることで２回以上の呼び出しが起きないようにします

常に覚えておいてほしいのはチェックされた継続の値がここで表すのは APIへの非同期呼び出しに対する手動での再開機能でありそれはすべてのパスで呼び出される必要がありますデリゲート型APIが何度も呼び出される場合や特定の状況で全く呼び出されない場合作動中の継続を確実に１回だけ再開することが重要です

継続を含む Swiftの並行処理における下位レベルの詳細については「SSwiftの並行処理: 舞台裏」をご覧ください

Swiftでのasync/awaitを駆け足でご紹介しました “async”と“await”が実行時に機能する仕組みまた Appやフレームワークに採用する方法を紹介してきました運用開始に際しSDKにおいて利用可能な非同期APIの一部をご紹介し既存のコードを同期から非同期の世界に移行する方法をご紹介しました

async/awaitとは Swiftの並行処理機能全体の基礎となるものですそれを活用して皆さんが作り上げるものが楽しみですありがとうございました

3:43 - Writing a function using completion handlers

func fetchThumbnail(for id: String, completion: @escaping (UIImage?, Error?) -> Void) {
    let request = thumbnailURLRequest(for: id)
    let task = URLSession.shared.dataTask(with: request) { data, response, error in
        if let error = error {
            completion(nil, error)
        } else if (response as? HTTPURLResponse)?.statusCode != 200 {
            completion(nil, FetchError.badID)
        } else {
            guard let image = UIImage(data: data!) else {
                completion(nil, FetchError.badImage)
                return
            }
            image.prepareThumbnail(of: CGSize(width: 40, height: 40)) { thumbnail in
                guard let thumbnail = thumbnail else {
                    completion(nil, FetchError.badImage)
                    return
                }
                completion(thumbnail, nil)
            }
        }
    }
    task.resume()
}

8:00 - Using completion handlers with the Result type

func fetchThumbnail(for id: String, completion: @escaping (Result<UIImage, Error>) -> Void) {
    let request = thumbnailURLRequest(for: id)
    let task = URLSession.shared.dataTask(with: request) { data, response, error in
        if let error = error {
            completion(.failure(error))
        } else if (response as? HTTPURLResponse)?.statusCode != 200 {
            completion(.failure(FetchError.badID))
        } else {
            guard let image = UIImage(data: data!) else {
                completion(.failure(FetchError.badImage))
                return
            }
            image.prepareThumbnail(of: CGSize(width: 40, height: 40)) { thumbnail in
                guard let thumbnail = thumbnail else {
                    completion(.failure(FetchError.badImage))
                    return
                }
                completion(.success(thumbnail))
            }
        }
    }
    task.resume()
}

8:30 - Using async/await

func fetchThumbnail(for id: String) async throws -> UIImage {
    let request = thumbnailURLRequest(for: id)  
    let (data, response) = try await URLSession.shared.data(for: request)
    guard (response as? HTTPURLResponse)?.statusCode == 200 else { throw FetchError.badID }
    let maybeImage = UIImage(data: data)
    guard let thumbnail = await maybeImage?.thumbnail else { throw FetchError.badImage }
    return thumbnail
}

13:15 - Async properties

extension UIImage {
    var thumbnail: UIImage? {
        get async {
            let size = CGSize(width: 40, height: 40)
            return await self.byPreparingThumbnail(ofSize: size)
        }
    }
}

14:17 - Async sequences

for await id in staticImageIDsURL.lines {
    let thumbnail = await fetchThumbnail(for: id)
    collage.add(thumbnail)
}
let result = await collage.draw()

21:22 - Testing using XCTestExpectation

class MockViewModelSpec: XCTestCase {
    func testFetchThumbnails() throws {
        let expectation = XCTestExpectation(description: "mock thumbnails completion")
        self.mockViewModel.fetchThumbnail(for: mockID) { result, error in
            XCTAssertNil(error)
            expectation.fulfill()
        }
        wait(for: [expectation], timeout: 5.0)
    }
}

21:56 - Testing using async/await

class MockViewModelSpec: XCTestCase {
    func testFetchThumbnails() async throws {
        XCTAssertNoThrow(try await self.mockViewModel.fetchThumbnail(for: mockID))
    }
}

22:30 - Bridging from sync to async

struct ThumbnailView: View {
    @ObservedObject var viewModel: ViewModel
    var post: Post
    @State private var image: UIImage?

    var body: some View {
        Image(uiImage: self.image ?? placeholder)
            .onAppear {
                Task {
                    self.image = try? await self.viewModel.fetchThumbnail(for: post.id)
                }
            }
    }
}

25:56 - Async APIs in the SDK

import ClockKit

extension ComplicationController: CLKComplicationDataSource {
    func currentTimelineEntry(for complication: CLKComplication) async -> CLKComplicationTimelineEntry? {
        let date = Date()
        let thumbnail = try? await self.viewModel.fetchThumbnail(for: post.id)
        guard let thumbnail = thumbnail else {
            return nil
        }

        let entry = self.createTimelineEntry(for: thumbnail, date: date)
        return entry
    }
}

26:59 - Async alternatives and continuations

// Existing function
func getPersistentPosts(completion: @escaping ([Post], Error?) -> Void) {       
    do {
        let req = Post.fetchRequest()
        req.sortDescriptors = [NSSortDescriptor(key: "date", ascending: true)]
        let asyncRequest = NSAsynchronousFetchRequest<Post>(fetchRequest: req) { result in
            completion(result.finalResult ?? [], nil)
        }
        try self.managedObjectContext.execute(asyncRequest)
    } catch {
        completion([], error)
    }
}

// Async alternative
func persistentPosts() async throws -> [Post] {       
    typealias PostContinuation = CheckedContinuation<[Post], Error>
    return try await withCheckedThrowingContinuation { (continuation: PostContinuation) in
        self.getPersistentPosts { posts, error in
            if let error = error { 
                continuation.resume(throwing: error) 
            } else {
                continuation.resume(returning: posts)
            }
        }
    }
}

31:44 - Storing the continuation for delegate callbacks

class ViewController: UIViewController {
    private var activeContinuation: CheckedContinuation<[Post], Error>?
    func sharedPostsFromPeer() async throws -> [Post] {
        try await withCheckedThrowingContinuation { continuation in
            self.activeContinuation = continuation
            self.peerManager.syncSharedPosts()
        }
    }
}

extension ViewController: PeerSyncDelegate {
    func peerManager(_ manager: PeerManager, received posts: [Post]) {
        self.activeContinuation?.resume(returning: posts)
        self.activeContinuation = nil // guard against multiple calls to resume
    }

    func peerManager(_ manager: PeerManager, hadError error: Error) {
        self.activeContinuation?.resume(throwing: error)
        self.activeContinuation = nil // guard against multiple calls to resume
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。