了解对闭包的不同 API 调用可能对你的 App 造成怎样的影响。
概览
你在 Swift 中使用的许多 API 都将闭包 (即以实例形式传递的函数) 视为参数。由于闭包可能包含与 App 中多个部分交互的代码,因此你务必要了解闭包所传递到的 API 调用闭包的不同方式。你传递给 API 的闭包可被同步 (立即) 或异步 (一段时间之后) 调用,并可能被调用一次或多次,也可能永不被调用。
重要信息
如果对何时调用闭包做出错误的假设,可能会造成数据不一致和 App 崩溃。
了解同步和异步调用的结果
在将闭包传递给 API 时,你需要考虑相对于代码中其他代码调用闭包的时间。在同步 API 中,闭包的调用结果会在你传递闭包后立即可用。在异步 API 中,该结果需要等待一段时间后才会可用;这一差别影响闭包“内”代码和闭包“后”代码的编写方式。
以下示例定义了两个函数:now(_:)
和 later(_:)
。你可以用相同的方式调用这两个函数:利用后置闭包而不使用其他参数。now(_:)
和 later(_:)
都接受闭包并调用它,但 later(_:)
则会等几秒才调用其闭包。
now(_:)
和 later(_:)
函数代表着你在 App 框架内接受闭包的方法中最常遇到的两种 API 类别:类似于 now(_:)
的同步 API,和类似于 later(_:)
的异步 API。
由于调用闭包可能会改变 App 的局部和全局状态,因此在编写传递闭包后的代码时需要仔细考量闭包被调用的时间。即便是打印一组字母这样简单的任务,也可能会受到闭包调用时机的影响:
运行上例中的代码通常会按照以下顺序打印字母:B
→ C
→ D
→ A
。尽管打印 A
的那一行位于代码的最前面,但在输出中排在后面。出现顺序差异的原因在于 now(_:)
和 later(_:)
函数的定义方式。如果你编写的代码依赖于特定的执行顺序,你需要知道每个函数调用其闭包的方式。
注释
A
相对于其他字母的打印顺序并不是一成不变的。在典型的系统条件下,它通常会在最后打印,但是当编写的代码依赖于异步调用相对于同步代码的顺序时,务必要更加小心地实现线程间同步。
在使用接受闭包的 API 时,你经常需要考虑这种基于时间的执行问题。在许多情形中,只有一种调用顺序对你的 App 来说是正确的,因此务必要根据你所使用的 API,仔细思考你的 App 将处于的状态。你可以结合使用 API 名称、参数名称以及相关的文档来判断 API 是同步还是异步的。
一个常见的时序错误是预计异步调用的结果可在同步调用代码中使用。例如,上文中的 later(_:)
方法与 URLSession
(英文) 类的 data
(英文) 方法相当,后者也是异步的。你应当避免下面这样的时序场景:在 App 的 view
(英文) 方法中调用 data
方法,并试图在作为完成处理程序传递的闭包外面使用其结果。
在会被多次调用的闭包中,不要编写代码来进行一次性更改
如果你要将一个闭包传递给可能要多次调用它的 API,请去掉旨在对外部状态进行一次性更改的代码。
以下示例会创建一个 File
(英文) 以及一组要写入该句柄所引用的文件的数据行:
要将每一行写入文件,应将闭包传递给 for
(英文) 方法:
File
使用完毕后,应使用 close
(英文) 来结束它。调用 close
的正确位置是在闭包外面:
如果你误解了 close
(英文) 的要求,可能会将调用放在闭包内。这样会导致你的 App 崩溃:
不要将重要代码放在可能不会被调用的闭包内
如果传递给 API 的闭包有可能不会被调用,请不要将对 App 继续运行至关重要的代码放在该闭包内。
以下示例定义了一个 Lottery
枚举,该枚举会随机挑选一个中奖号码并在正确数字被猜中时调用完成处理程序:
编写的代码不应依赖于要调用的完成处理程序,否则会很不可靠。因为随机猜测无法保证一定正确,如果将诸如支付账单等重要行为安排在中奖之后才发生,这些行为可能永远不会发生。