Optional 与 Non-Escaping 兼具的闭包

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

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

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

  • 一个函数发起一个后台任务然后立刻返回, 通过一个 completion handler 回调去汇报结果
  • 一个 View 的类保存了一个闭包去处理按钮点击事件, 每次用户点击这个按钮的时候就会去调用这个闭包, 这个闭包就会逃出这个属性的生命周期
  • 你用 DispatchQueue.async 在一个线程里发起异步任务, 这个任务闭包就比发起异步任务的函数存活得更久.

与之相对的, 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 已经提上了日程并且应该会在下个版本里完成.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 210,978评论 6 490
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 89,954评论 2 384
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,623评论 0 345
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,324评论 1 282
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,390评论 5 384
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,741评论 1 289
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,892评论 3 405
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,655评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,104评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,451评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,569评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,254评论 4 328
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,834评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,725评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,950评论 1 264
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,260评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,446评论 2 348

推荐阅读更多精彩内容