Swift Evolution 提案学习笔记：async/await-六虎

背景

在过往的 iOS 开发中，异步履行使命需求用到回谐和闭包来完结。根据回调的异步编程有许多弊端，例如：

假如需求接连履行多个异步使命，很简单发生如下的多层嵌套，影响可读性。

func processImageData1(completionBlock: (_ result: Image) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource in
        loadWebResource("imagedata.dat") { imageResource in
            decodeImage(dataResource, imageResource) { imageTmp in
                dewarpAndCleanupImage(imageTmp) { imageResult in
                    completionBlock(imageResult)
                }
            }
        }
    }
}

处理代码抛出的异常 / 过错进行十分费事。如下图所示，每一层都需求用 guard 来查看过错，并调用完结回调。

func processImageData2a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            completionBlock(nil, error)
            return
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                completionBlock(nil, error)
                return
            }
            decodeImage(dataResource, imageResource) { imageTmp, error in
                guard let imageTmp = imageTmp else {
                    completionBlock(nil, error)
                    return
                }
                dewarpAndCleanupImage(imageTmp) { imageResult, error in
                    guard let imageResult = imageResult else {
                        completionBlock(nil, error)
                        return
                    }
                    completionBlock(imageResult)
                }
            }
        }
    }
}

假设咱们需求根据某些条件改变回调的传参，为了防止许多重复的代码，咱们就不得不先定义 swizzle 这个闭包。这会导致代码被「倒转」过来：swizzle 的代码原本是在后面履行，但却先于履行它的代码呈现，进步了了解本钱。此外，咱们还必须十分小心地重视回调里持有了哪些变量。

func processImageData3(recipient: Person, completionBlock: (_ result: Image) -> Void) {
    let swizzle: (_ contents: Image) -> Void = {
      // ...
    }
    if recipient.hasProfilePicture {
        swizzle(recipient.profilePicture)
    } else {
        decodeImage { image in
            swizzle(image)
        }
    }
}

简单踩坑：忘掉调用完结回调，或者是忘掉 return

func processImageData4a(completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    loadWebResource("dataprofile.txt") { dataResource, error in
        guard let dataResource = dataResource else {
            return // <- 忘了调用 completionBlock
        }
        loadWebResource("imagedata.dat") { imageResource, error in
            guard let imageResource = imageResource else {
                return // <- 忘了调用 completionBlock
            }
            ...
        }
    }
}
func processImageData4b(recipient:Person, completionBlock: (_ result: Image?, _ error: Error?) -> Void) {
    if recipient.hasProfilePicture {
        if let image = recipient.profilePicture {
            completionBlock(image) // <- 忘了 return
        }
    }
    ...
}

考虑到以上原因，回调的异步编程太简单犯错。这导致许多程序员在编程时潜意识地不愿意编写异步代码，失去了许多性能优化的时机。

async/await

根据协程（coroutine）模型，Swift 的 async/await 机制让咱们能像编写同步代码相同编写异步代码。这不仅能极大的进步代码可读性和 debug 的便利性，还能为未来推出的 Swift 并发特性提供基石。前文说到的、根据回调的异步代码用 async/await 重写之后会变得简洁明了：

func loadWebResource(_ path: String) async throws -> Resource
func decodeImage(_ r1: Resource, _ r2: Resource) async throws -> Image
func dewarpAndCleanupImage(_ i : Image) async throws -> Image
func processImageData() async throws -> Image {
  let dataResource  = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  let imageTmp      = try await decodeImage(dataResource, imageResource)
  let imageResult   = try await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

能够这么了解 Swift 的 async 异步函数：

异步函数本质上仍然是一般的函数，但它们还被赋予了「暂时让出当时线程」的才能；相比之下，同步函数不具有此项才能，它们只懂得堵塞当时线程，直到其中的所有代码履行完毕。
因为同步函数并不知道如何「让出」当时线程，一个同步函数不能够直接调用另一个异步函数。
异步函数能够仍然能够调用堵塞当时线程的其它同步函数。当一个异步函数履行到它本身或是它所调用的另一个异步函数的挂起点时，这条链路上的所有函数都会一起「挂起」，并让出当时线程给其它使命运用。
当挂起的异步函数康复履行时，它并不一定会回到被挂起前的线程。在编写 Swift 的并发逻辑时，咱们应该防止考虑线程 —— 这是底层的完结细节。在 Swift 的并发模型中，所有的办法都在某一个 actor 中履行。Swift 只保证异步函数在康复后会回到原本的 actor 中履行。
Actor 的细节在本文中暂不评论，它的效果相似于 GCD 中的串行行列。不同的是，actor 并不保证先进先出。

挂起点 Suspension points

在一个异步函数的履行过程中，其必须暂停履行并「让出」当时线程的时间被称之为「挂起点」。在 Swift 中，挂起点总是显式、明确的 —— 一个函数中所有或许的挂起点总会被明确地用await 标示出来。（注意，标示了await 的函数调用反过来并不一定便是一个挂起点 —— 当时函数在编译时并不知道其所调用的函数是否真的会「挂起」。）

为何对「挂起点」的标示如此重要？因为挂起操作会损坏代码履行的「原子性」—— 从函数被挂起到康复之间，当时的 actor 上或许已经运行了其它代码。举个例子：假设同一笔银行买卖 A 包括了「存款 + 取款」两步，但在「存款」之后 A 买卖的处理被暂时挂起了，那么不怀好意的人就有时机在挂起期间再度发起一笔「取款」B 买卖。在 A 买卖履行被康复后，A 买卖中的取款被持续履行 —— 这导致一笔存款被取出了两次。

规划细节

以下是 async/await 的一些语法规划细节。

异步办法

// 将一个函数标示为异步
func collect(function: () async -> Int) { ... }
// 结构办法也能够是异步的
class Teacher {
  init(hiringFrom: College) async throws {
    ...
  }
  private func raiseHand() async -> Bool {
    ...
  }
}

在 async/await 的提案中，包括deinit 和特点的拜访器（getter、setter、下标）在内的特殊办法不能是异步的。

在后来的SE-0310提案中 Swift 增加了对异步只读特点的支撑，但包括 setter 的特点仍然不能是异步的。async/await 原提案中对此的解说是：因为一个可写特点或许被作为inout参数传递，该特点中包括的子特点或许在别处被拜访或修改，而这意味着该可写特点的 setter 必须是同步且不会抛出任何异常的。SE-0310提案中则进一步说到，考虑到inout、_modify、didSet、willSet、特点包装器、下标等等特性的存在，要支撑异步可写特点工程量实在是十分巨大，所以暂不考虑支撑。

对于没有调用父类结构办法的子类异步结构办法，编译器仅会在父类包括一个无参数、同步、被指定的结构办法时，隐式添加super.init()。这是因为假如父类结构器也是异步的，那么对父类结构办法的调用构成了一个「挂起点」，而这必须被显式地标示出来。

异步办法类型转化

能够将同步办法隐式转化为异步办法，但反过来则不行：

struct FunctionTypes {
  var syncNonThrowing: () -> Void
  var syncThrowing: () throws -> Void
  var asyncNonThrowing: () async -> Void
  var asyncThrowing: () async throws -> Void
  mutating func demonstrateConversions() {
    // OK    
    asyncNonThrowing = syncNonThrowing
    asyncThrowing = syncThrowing
    syncThrowing = syncNonThrowing
    asyncThrowing = asyncNonThrowing
    // Error
    syncNonThrowing = asyncNonThrowing 
    syncThrowing = asyncThrowing      
    syncNonThrowing = syncThrowing 
    asyncNonThrowing = syncThrowing
  }
}

Await 句子

所有或许的「挂起点」仅能呈现在异步上下文中（例如在一个异步办法中），且必须用await进行标示：

// func redirectURL(for url: URL) async -> URL { ... }
// func dataTask(with: URL) async throws -> (Data, URLResponse) { ... }
let newURL = await server.redirectURL(for: url)
let (data, response) = try await session.dataTask(with: newURL)

一个await能够包括多个潜在的挂起点：

let (data, response) = try await session.dataTask(with: server.redirectURL(for: url))

await本身并不具备任何功能，它只是起到标示潜在挂起点的效果。一个被标示了await的目标也或许并不包括任何挂起点：

let x = await synchronous() // 警告：标示为 await 但并没有调用任何异步办法

await不能用在defer的闭包中。

闭包

闭包也能够是异步的：

{ () async -> Int in
  print("here")
  return await getInt()
}

包括await的匿名闭包会被隐式标示为异步：

let closure = { await getInt() } // 隐式异步
let closure2 = { () -> Int in     // 隐式异步
  print("here")
  return await getInt()
}

一个嵌套闭包被隐式标示为异步，并不会导致其上下级闭包被一起标示为异步：

// func getInt() async -> Int { ... }
let closure5 = { () -> Int in       // 非异步
  let closure6 = { () -> Int in     // 隐式异步
    if randomBool() {
      print("there")
      return await getInt()
    } else {
      let closure7 = { () -> Int in 7 }  // 非异步
      return 0
    }
  }
  print("here")
  return 5
}

过载函数时的抵触解决战略

现状

以下两个函数虽然表面上具有不同的签名，但调用时的代码却或许呈现堆叠：

func doSomething(completionHandler: ((String) -> Void)? = nil) { ... }
func doSomething() async -> String { ... }
doSomething() // 调用哪个？

按照现有的 Swift 过载函数战略，参数较少的那个函数（也便是第二个）会被调用。这导致开发者假如新增函数 2，所有原先的doSomething()代码都会立刻报错 —— 它们都会被改为调用函数 2，但函数 2 作为一个async异步办法，不能够在同步办法里被履行。这会给开发者造成巨大的迁移本钱，因为他们将不得不在「改名办法 1，所有本来的的doSomething() 代码立刻报错」和「给所有的新增async办法想一个新的名字」之间二选一。

持续考虑如下状况：

// 现有的同步接口
func doSomethingElse() { ... }
// 新的异步接口
func doSomethingElse() async { ... }
// 过错: 重复定义 `doSomethingElse()`.

因为现有的 Swift 过载规矩不允许两个办法签名完全一致、仅在「最终效果」上发生差异，这样的办法定义是不合法的。这也导致了迁移本钱，因为开发者没办法在保存现有同步接口的状况下，新增同名的异步接口。

改进的过载战略

随着 async/await 一起推出的新过载战略会根据上下文来判别要履行哪个办法：

在一个同步的上下文中，Swift 会优先挑选两个重名办法中的同步版别。这是因为在同步的上下文中，调用异步版别是不合法的。
在一个异步的上下文中，Swift 会优先挑选异步版别，因为异步代码应该尽或许防止调用会导致堵塞的同步代码。此刻，await关键字天然也是必不可少的。

明白了这些新的战略，咱们再来看看上一节说到的 doSomething 办法：

func f() async {
  // 因为处于异步上下文中，异步版别的 doSomething 被挑选了：
  await doSomething()
  // 过错：因为挑选了异步的 doSomething，必须添加 await
  doSomething()
}
func f() async {
  let f2 = {
    // 处于同步上下文中，同步版别的 doSomething 被挑选了：
    doSomething()
  }
  f2()
}

主动闭包

一个办法本身必须是async，它所接受的主动闭包参数才能够是async的。

// 过错：办法不是 async，参数中却有 async 主动闭包
func computeArgumentLater<T>(_ fn: @escaping @autoclosure () async -> T) { }

为什么会有这种约束？考虑以下代码：

// func getIntSlowly() async -> Int { ... }
let closure = {
  computeArgumentLater(await getIntSlowly())
  print("hello")
}

这种写法有几个问题：

await关键字呈现在了传参里，这会导致开发者误认为挂起点是在computeArgumentLater(_:)被履行之前，但实际上并非如此 —— getIntSlowly()是在computeArgumentLater(_:)内部被调用的。
根据第 1 点，因为await关键字的特殊方位，closure会被认为是异步的，但实际上closure里全都是同步代码。
好像应该写成await computeArgumentLater(getIntSlowly())，但考虑到参数是个主动闭包，这样又损坏了语义的完整性。

通过把async主动闭包限定为仅可在异步上下文中运用，咱们即可防止这些问题。

协议

async的协议办法要求能够被同步或异步的办法所完结，但协议中所规则的同步办法不得被async完结所满意。这和throw的协议要求相似。

protocol Asynchronous {
  func f() async
}
protocol Synchronous {
  func g()
}
struct S1: Asynchronous {
  func f() async { } // OK
}
struct S2: Asynchronous {
  func f() { } // OK，同步办法可满意协议的异步办法要求
}
struct S3: Synchronous {
  func g() { } // OK
}
struct S4: Synchronous {
  func g() async { } // 过错：异步办法无法满意协议的同步办法要求
}

Swift Evolution 提案学习笔记：async/await

背景

async/await

挂起点 Suspension points

规划细节

异步办法

异步办法类型转化

Await 句子

闭包

过载函数时的抵触解决战略

现状

改进的过载战略

主动闭包

协议

相关文章

Swift – LeetCode – 第一个错误的版本

程序员技术文章写作及分享技巧

大前端老司机的浅谈

iOS开发工具

作者信息