1.1　クロージャーのコールバックによる非同期処理の問題点

　非同期処理をクロージャーのコールバックで実装することは開発者が日常的に行っていることですが、簡単に可読性が下がり不注意によるバグも発生しやすいです。たとえば、URLSessionでHTTPリクエストを行う関数を考えてみましょう。HTTPリクエストを行い、そのレスポンスのURLからさらに画像を取得し、その画像をリサイズすることを想定しています。

リスト1.1: クロージャーによるコールバック

// Page: 1-1-request-with-closure
func request(url: URL,
             completionHandler: @escaping (Result<UIImage, Error>) -> ()) {
    // ①taskインスタンス取得
    let task = URLSession.shared
                         .dataTask(with: url) { data, response, error in
        // ③URLSession.shared.dataTaskのコールバック
        guard error == nil else { return }
        downloadImage(data: data) { result in
            // ④downloadImageのコールバック
            let image = try? result.get()
            resizeImage(image: image) { result in
                // ⑤resizeImageのコールバック
                completionHandler(result)
            }
        }
    }
    // ②リクエストの実行
    task.resume()
}

　3つのコールバックが順々に呼ばれており、ネストが深くなり読みづらいコードになっています。コードの実行順は①でURLSessionのdataTaskメソッドの戻り値taskインスタンスを取得し、②のresumeメソッドでリクエストを実行します。そして③、④、⑤のコールバックが順に呼ばれるという流れです。処理の実行順が上、下、真ん中と分かれるので注意して読み進めないと、どの順番でコードが実行されるかを間違えてしまうでしょう。さらにネストが深くなったり、コールバックの実行に条件分岐が加わるなどがあれば、さらにコードの可読性はさらに下がります。

　また、コールバックの呼び出し元はすべてのパスで確実に呼ばれることを想定していますが、実際に呼び出すかどうかは開発者の責任です。呼び忘れた場合は不具合の原因になるでしょう。

　リスト1.1ではエラーがある場合、guard文で早期リターンをするのみで、コールバックを呼んでいません。

リスト1.2: コールバックを呼ばないパスがある

// Page: 1-1-request-with-closure
func request(url: URL,
             completionHandler: @escaping (Result<UIImage, Error>) -> ()) {
    let task = URLSession.shared
                         .dataTask(with: url) { data, response, error in
        // エラーがある場合にコールバックを呼んでいない
        guard error == nil else { return }

　すると、呼び出し元で不具合が発生する可能性があります。たとえば、リクエストの処理中には画面のローディングViewを表示する場合を考えましょう。呼び出し元でリクエスト前にローディングViewを出し、処理が終わったらローディングViewを非表示にするとします。コールバックが呼ばれないパスがある場合、ローディングViewがいつまでも表示されてしまいます。

リスト1.3: 呼び出し元:リクエスト中にローディングViewを表示する

// Page: 1-1-request-with-closure
let url = URL(string: "https://example.com")!
request(url: url) { result in
    // コールバックが呼ばれないとisLoadingがfalseにならず、
    // ローディングViewが表示しっぱなしになるかもしれない
    isLoading = false
    switch result {
        case .success(let image):
            print(image)
        case .failure(let error):
            print(error.localizedDescription)
    }
}

　コールバックの呼び出しはコンパイラはチェックをしないので、開発者は注意深くすべてのパスで呼ばれるかどうかをチェックする必要があります。

1.2　async/awaitで解決する

　Swift Concurrencyのasync/awaitは、この問題を解決します。関数の定義にasyncをつけることで、その関数を非同期関数¹として定義ができます。非同期関数を呼び出すためには、awaitが必要です。awaitをつけると、その式をシステムに待機可能なプログラムということを伝えます。待機可能なプログラムの意味は後述します。

　ひとまず、先ほどのrequest関数をasync関数として実装し直し、記述がどう変わるのかを見てみましょう。

リスト1.4: request関数をasync関数として実装

// Page: 1-2-request-with-async
func request(url: URL) async throws -> UIImage {
    let (data, response) = try await URLSession
                                        .shared
                                        .data(from: url, delegate: nil)
    let image = try await downloadImage(data: data)
    let resizedImage = try await resizeImage(image: image)
    return resizedImage
}

　たった6行ほどで、非同期処理を記述できるようになりました。戻り値の矢印->の前にasync throwsのキーワードをつけて、エラーをスローする非同期関数として定義します。戻り値が定義されているため、すべてのパスでreturnをするかエラーをスローしなければコンパイルエラーとなります。つまり、コールバックを使用していたときとは異なり、正常系も異常系も実装忘れがないことをコンパイラが保証してくれています。処理は同期的なコードと同じように上から下に流れていくため、読みやすいコードとなっています。

　非同期関数を呼び出す際は、awaitキーワードが必要です。awaitキーワードをつけることで、システムにプログラムが待機可能性があること伝えます。また、非同期関数やメソッドは並行処理のための特別なコンテキストで、実行が必要です。本書では、この特別なコンテキストを非同期コンテキストと呼ぶことにします。ここではTask.detachedを利用しましょう。Task.detachedについての詳細は第4章「Task」で解説しますが、今回は非同期コンテキストを作成してくれるものとして考えていただければ大丈夫です。

リスト1.5: async関数を呼び出す

// Page: 1-2-request-with-async
var isLoading = true
Task.detached {
    do {
        let url = URL(string:
            "https://api.github.com/search/repositories?q=swift")!
        // 非同期関数を呼び出す
        let response = try await request(url: url)
        // エラーがなければ必ず通る
        isLoading = false
        print(response)
    } catch {
        // エラーの場合でも必ず通る
        isLoading = false
        print(error.localizedDescription)
    }
}

　requestメソッドの前に、try awaitをつけてメソッドを呼び出しています。戻り値はresponse変数に代入され、通常の変数と同じように利用できます。ここでは、print関数で変数の中身を出力しています。また、エラーが発生すればcatchブロックが呼ばれます。コールバック形式の場合とは異なり、処理の流れは上から順に実行されて読みやすいです。リクエスト中に表示するローディングViewもこの場合ではエラーある場合、ない場合、どちらでも必ずisLoadingをfalseにできます。ローディングViewがずっと表示されたままになる不具合は、非同期関数の場合はなくなります。

1.3　プログラムの待機可能性とは？

　awaitキーワードは、プログラムにそのメソッドやプロパティーが待機可能であることを伝えるものです。awaitがつけられると、実行中のメソッドやプロパティーは待機状態となります。そのメソッドやプロパティーを実行していたスレッドはブロックを解除し、他の作業を行います。システムがそのメソッドやプロパティーを再開すると、処理が完了し、戻り値があれば左辺に変数が代入されます。

　図で説明しましょう。リスト1.5で示したrequest（url:）メソッドの呼び出しを見てみます。

　awaitキーワードをつけることで、システムにrequest（url:）メソッドが待機可能であることを伝えます。実際にコードが実行されたとき、request（url:）メソッドは中断されます。

　スレッドはブロックを解除し、他のタスクを行います。たとえば、もしかしたらユーザーがボタンタップしたり、スクロールをするなどのUIイベントが発火されるかもしれません。Timerなどのグローバルな通知イベントが発火するかもしれません。その場合でもスレッドはブロックされず、他のタスクを実行します。

　そしてrequest（url:）メソッドが再開されると、結果が左辺のresponse変数に代入されます。

　このようにSwift Concurrencyでは、実行中のメソッドやプロパティーを中断、再開して非同期処理を行います。開発者はスレッドの管理を気にすることなく、同期的なコードと同じような書き方で、非同期処理を実行できます。

　ちなみに、awaitキーワードで実行した後のスレッドは、その前で実行されたものと同じとは限りません。

リスト1.6: await前後でスレッドは同じとは限らない

// Page: 1-2-request-with-async
let url = URL(string:
            "https://api.github.com/search/repositories?q=swift")! // A
let response = try await request(url: url)
isLoading = false
print(response) // Aと同じスレッドで実行されるとは限らない

　今回の例でいえば、Aが実行された行とprint関数が実行される行のスレッドが必ず同じとは限りません。request（url:）でスレッドが変わる可能性があります。