iOS Developer

Optional 与 Non-Escaping 兼具的闭包

2016-11-30  本文已影响113人  kemchenj

原文: Optional Non-Escaping Closures
作者: Ole Begemann
译者: kemchenj

Swift 里如何区分 escaping (逃逸)和 non-escaping (非逃逸)的闭包呢? escaping closure(逃逸闭包)作为函数参数在函数 return 之后(可能会)被调用. 也就是说这个 escaping 闭包被传递到了外部, 逃出当前的函数的作用域.

逃逸闭包经常会跟异步操作联系在一起, 就像下面的例子:

与之相对的, DispatchQueue.sync 会等到任务闭包执行完成, 然后再 return -- 这个闭包就永远不会逃逸了. 类似的还有 map 和其它标准库里常用的序列和集合的算法.

为什么区分开 escaping 和 non-escaping 的闭包那么重要?

四个字概括, 内存管理. 一个闭包会持有闭包内捕获的变量的强引用, 如果你访问了成员变量和调用了函数的话, 还会对 self 产生强引用, 因为这会隐式地把 self 作为参数传入.

一不小心就会非常容易引入 reference cycles(循环引用), 这就是编译器要求你显式地在闭包内写出 self 的原因. 这会强制你去思考潜在的循环引用风险并且手动通过 capture lists(捕获列表) 去解决它.

但无论如何, 都不可能会在一个 non-escaping 的闭包里发生循环引用 -- 编译器会保证在函数 return 的时候, 闭包会 release 所有捕获的变量. 所以, 编译器只要求在 escaping 的闭包里显式地把 self 写出来. 这会让 non-escaping 的闭包更容易使用.

non-escaping 闭包的另一个好处就是编译器可以采取更激进的性能优化. 例如, 编译器因为知道了闭包的生命周期, 所以可以删掉一些不必要的 retainrelease. 另外, 非逃逸的闭包的上下文也可以保存在栈而不是堆里, 虽然我不知道现在 Swift 的编译器对这个优化得怎么样 (open March 2016 bug report 这个提案好像说到了 Swift 还没做这个优化)

闭包默认为 non-escaping ...

从 Swift 3开始, non-escaping 闭包闭包默认声明为 non-escaping , 如果你想让参数闭包逃逸的话, 你需要加上一个 @escaping 去修饰类型. 举个现实的例子, 下面是 DispatchQueue.async (escaping) 和 DispatchQueue.sync (non-escaping) 的声明:

class DispatchQueue {
    ...
    func async(/* other params omitted */, execute work: @escaping () -> Void)
    func sync<T>(execute work: () throws -> T) rethrows -> T
}

Swift 3 之前, 是另一种做法: 默认为 escaping, 并且你需要加上 @non-escaping 修饰. 新的做法更好, 因为默认情况下是安全的(不会发生循环引用): 一个函数参数如果有潜在的循环引用的风险, 就必须显式地书写出来. 这样子, @escaping 修饰符就可以作为开发者使用函数时的一个安全提示存在.

... 但只适用于"即时函数参数"(immediate function parameters)

默认 non-escaping 有一个很重要的规则: 它只适用于作为参数传入函数的闭包, 例如: 任何作为参数传入的闭包. 其它所有闭包都是 escaping 的.

作为"即时函数参数"是什么意思?

让我们来看一些例子. 最简单的例子就是像 map 这样的高阶函数: 一个接收闭包参数的函数. 就像我们看的的这样, 这是一个 non-escaping 的闭包(这里删掉了一些跟讨论无关的 map 的细节):

func map<T>(_ transform: (Iterator.Element) -> T) -> [T]

函数参数总是逃逸的

与此不同的是闭包类型的变量或者属性, 它们都默认为 escaping, 甚至不用显示地声明(实际上, 显式地加上 escaping 还会报错). 这其实很合理, 因为把一个值赋值给变量很明显就会让这个值逃逸到变量的作用域, non-escaping 的闭包明显就不能这么做. 说起来可能会让你觉得有点晕, 但显而易见的是, 参数列表里的闭包跟任何别的情况都不一样.

Optional 的闭包必须为 escaping

更让人意外的是, 参数作为闭包, 但是被封装到别的类型里(例如元组, 枚举或者是可选类型), 就都是 escaping 的. 因为这里的函数都不是作为即时参数传入, 它会自动转变为 escaping. 这造成的结果就是, Swift 3.0 里你没办法在函数的参数里声明一个既是 Optional 又是 non-escaping 的闭包. 思考下面的例子, transform 函数接收一个 Int 类型的参数 n 和一个 Optional 类型的闭包 f. 它会返回 f(n), 而 f 为 nil 的时候返回 n:

/// 如果 `f` 为 nil 的话直接返回 `n`
/// 如果 `f` 不为 nil 的话就返回 `f(n)`
func transform(_ n: Int, with f: ((Int) -> Int)?) -> Int {
    guard let f = f else { return n }
    return f(n)
}

这里, 闭包 f 是 escaping 的, 因为 ((Int) -> Int)? 其实是 Optional<(Int) -> Int> 的简写, 而不是作为即时参数存在. 这不是我们想要的, 因为这里 f 不可能逃逸.

用默认值去取代 optional

Swift 团队注意到了这个做法的局限性并且计划在以后的版本里修复它. 现在必须留意到这一点, 但现在还是没有办法把一个 escaping 的闭包强制转换为 non-escaping, 不过在很多情况下, 你可以通过给闭包参数一个默认值去避免让参数声明为 Optional. 在下面的例子里, 默认值是直接把原参数传回的闭包:

/// 当 f 没有传入的时候, 直接给 f 提供一个默认的实现
func transform(_ n: Int, with f: (Int) -> Int = { $0 }) -> Int {
    return f(n)
}

使用重载提供 Optional 和 non-escaping 两个版本

如果不能够提供默认值的话, Michael Ilseman 建议使用重载作为一种变通方法, 你可以写给函数写两个版本, 一个用 Optional 作为参数, 另一个使用 non-optional, non-escaping:

// 重载 1: optional, escaping
func transform(_ n: Int, with f: ((Int) -> Int)?) -> Int {
    print("Using optional overload")
    guard let f = f else { return n }
    return f(n)
}

// 重载 2: non-optional, non-escaping
func transform(_ input: Int, with f: (Int) -> Int) -> Int {
    print("Using non-optional overload")
    return f(input)
}

我加上了一些说明去示范一下这些函数怎么被调用. 让我们用不同的参数来测试一下, 不出意外, 如果你传 nil, 那么类型检查的时候就会选择重载 1:

transform(10, with: nil) // → 10
// 使用了 Optional 版本的重载

如果你传入一个 Optional 的闭包也会是同样的重载:

let f: ((Int) -> Int)? = { $0 * 2 }
transform(10, with: f) // → 20
// 使用了 Optional 版本的重载

甚至变量的类型是 non-optional的, Swift 也会选择第一个重载. 这是因为闭包被保存在变量里的时候会自动逃逸, 所以这里不适用于第二个重载, 虽然我们希望重载的是第二个:

let g: (Int) -> Int = { $0 * 2 }
transform(10, with: g) // → 20
// 使用了 Optional 版本的重载

但是如果你是直接把闭包传入就会变得不一样了, 现在会重载到 non-escaping 的版本:

transform(10) { $0 * 2 } // → 20
// 使用了 non-optional 版本的重载

现在调用高阶函数传入闭包已经变得习以为常, 在大多数情况下, 使用这种方法可以让你用一种更加愉悦的方式去传入 nil. 如果你打算这么做的话, 请确保你在文档里列清楚为什么你需要两种重载.

Typealias 必须 escaping

最后一件你要注意的是, 在 Swift 3里你给闭包起别名的时候不能声明 escaping 或者 non-escaping. 如果你使用闭包别名作为函数参数类型的话, 需要注意这个闭包是且只能是 escaping 的. 一个 Fix for this bug 已经提上了日程并且应该会在下个版本里完成.

上一篇下一篇

猜你喜欢

热点阅读