Futures/Promises 概览:我是如何爱上 GCD 的

OliSwope 3年前
   <p>这是一篇关于 Swift 中的 Futures/Promises 架构概览,演讲者为我们着重介绍了 FutureKit 的使用方式,从而避免再去调用恼人的 dispatch_async 。同时这也是一篇关于异步处理的简要介绍,演讲者讲述了 Futures/Promises 框架是如何帮助我们来实现异步处理的。</p>    <p>通过本次讲演,我们会了解到以下内容:</p>    <ul>     <li>如何将 Promise 和 Future 互相结合</li>     <li>如何使用 executor 从而让 GCD 更简单</li>     <li>不用再编写带有回调闭包属性的函数了</li>     <li>如何将您喜爱的异步库封装到 Future 当中(例如 Alamofire、ReactiveCocoa 等等)</li>     <li>创建稳定的 (rock solid) 错误处理,以及异常简单的取消操作 (cancellation)</li>    </ul>    <p>我同样也会对诸如缓存 (caching)、并发执行 (parallel execution)、 NSOperationQueues 、基于 FIFO 的运行之类的编码模式,来对 Futures 做一个简要的概述。</p>    <p>今天我想要谈论的是 <strong>FutureKit</strong> 这个框架。它不仅仅是 Futures-Promises 架构的 Swift 实现,并且我觉得它与其他解决方案相比要更为 “Swift 化”。我们将会谈论一下 Future、Promise 等这些术语究竟是什么意思,以及为什么实际上没有人能完全遵守这些观念。</p>    <p>格的不同而已。至于您喜不喜欢这个解决方案,这完全取决于您自己,但是您至少应该了解一下这些解决方案的不同之处。</p>    <p>在我们讨论 Futures/Promises 的概念之前,我们需要先讨论一下代码块 (Block) 和闭包 (Closure)。</p>    <h3><strong>代码块与闭包</strong></h3>    <p>代码块与闭包的好处都有啥?它可以让您摆脱那些恼人的委托协议 (delegate protocol)。尽管有些委托协议还是没法摆脱,但是要注意的是,您可以只定义一个带有回调闭包 (callback block) 的函数。比如说在 GCD (Grand Central Dispatcher) 当中,如果您想要在非主线程当中执行某些操作的话,那么您就需要闭包的帮忙。</p>    <p>现在我们要讨论一下这么做的缺点。</p>    <pre>  <code class="language-javascript">func asyncFunction(callback:(Result) -> Void) -> Void {     dispatch_async(queue) {    let x = Result("Hello!")    callback(x)   }  }</code></pre>    <p>这是一个很常见的例子了。我封装了一个 asyncFunction 方法,从中我创建了某种 Result,但是如果我想要将这个 Result 回调的话,那么我就必须要提供一个回调例程(callback routine)。</p>    <p>如果您经常处理异步事务的话,那么这种代码您此前也一定写过。这里是我所编写的一个例子,无论如何,我们都要进入到一个后台线程 (background queue) 当中,然后在那里生成我们所要的 Result,接着将 Result 回调回去。</p>    <h3><strong>回调闭包的问题所在</strong></h3>    <p>事实上,我将会讨论一下 <strong>AFNetworking</strong> 的相关设计。我觉得之所以 AFNetworking 能够成为 iOS 开发者首选的第三方库,是因为它摈弃了存在于 NSURL 当中的那些可怕的委托协议。它是基于回调进行的。</p>    <pre>  <code class="language-javascript">Alamofire.request(.GET, "https://httpbin.org/get", parameters: ["foo": "bar"])   .response { request, response, data, error in    print(request)    print(response)    print(data)    print(error)  }</code></pre>    <p>这是 Alamofire 的一个例子,是它最新版本的一个示例。我在这里不会讲解 Alamofire 的相关知识。虽然我不喜欢 Alamofire 这个第三方库,但是我觉得以它为例来介绍回调闭包是再好不过的了,我们提出了一个网络请求以获取相关数据。这里我将会获取到某种网络回应 (response) 对象,并且您可以看到这些选项—— request 、 response 、 data 以及 error ——这些选项都是可能在这个异步 API 调用的时候出现的。</p>    <p>好的,大家可能会问了,这看起来挺正常的啊,怎么会有问题呢?实则不然,当您运行了某个带有回调闭包的函数时,就会出现很诡异的现象。举个例子,这个闭包将在何处运行呢?</p>    <p>一旦您开始编写异步代码,这就意味着这段代码将不能在主线程当中运行,因为如果您将这段代码写到了主线程上,那么您的应用会卡顿在那儿,因此您必须要将这些代码放到后台来执行。因此,当您运行一个本身就在后台运行的回调函数时,按正常道理来说它随后会将结果回调给您,但是问题来了,这个回调的结果 <em>在哪里</em> 呢?这个回调闭包现在是否必须要派发 (dispatch) 到主线程上呢?但是如果这个回调我仍然不希望它在主线程上运行呢?</p>    <p>另外的问题是,我们该如何进行错误处理呢?我是不是要实现两个回调?我看到过有 API 提供了一个成功时调用的回调代码,以及一个失败时调用的回调代码。我用一个例子给大家演示一下,为什么绝大多数人会使用 Swift 的枚举来规避这个情况的发生,当然如果您这么做也是很好的一个解决方案。但是这仍然存在一个问题,您该如何界定错误的范围呢?</p>    <p>此外就是取消操作 (cancellation) 了。多年以来,对于这些第三方库来说有这么一个经久未决的问题:那就是如果我有一个操作,然后我取消了这个操作,那么是否需要调用取消的回调呢?以及,我该如何处理这个取消操作呢?</p>    <pre>  <code class="language-javascript">func getMyDataObject(url: NSURL,callback:(object:MyCoreDataObject?,error: ErrorType) ->  Void) {   Alamofire.request(.GET, url, parameters: ["foo": "bar"]).responseJSON { response in    switch response.result {    case .Success:     managedContext.performBlock {      let myObject = MyCoreDataObject(entity: entity!,       insertIntoManagedObjectContext: managedContext)      do {       try myObject.addData(response)       try managedContext.save()       dispatch_async(dispatch_get_main_queue(), {        callback(object: myObject, error: nil)       })      } catch let error {       callback(object: nil,error: error)      }     }    case .Failure(let error):     callback(object: nil,error: error)    }   }  }</code></pre>    <p>这是一个典型的获取数据的函数,用标准的 GCD 回调写成。我执行了 Alamofire 网络请求,准备去 GET 数据。然后我得到了相应的网络回应,它是以枚举的形式返回,这是一个很好的范例。</p>    <p>再提及一遍,之所以给大家展示 Alamofire 的原因不是因为我喜欢它,而是我觉得它在使用回调方面无出其右,但是我们还是来看一下它的缺点所在。</p>    <p>现在我们获取到了 response 对象。如果成功的话,呃,这是一个 API 调用,然后我想要从服务器那里返回一个模型对象。我们使用这个 URL 来进行 Alamofire 的网络访问,假定我得到的网络回应是成功的。</p>    <p>这时候,我会创建一个相应的管理对象上下文 (managed object context),然后对其执行 performBlock ,由于管理对象上下文处于不同的上下文当中,并且我还要确保我没有在主线程执行这个方法。因此我需要使用后台进程。</p>    <p>这时候让我们去调用这个 performBlock 。现在我位于另一个线程当中了,所以也就是说,我现在是很安全的,这个时候我们就来构造 MyCoreDataObject ,然后使用这个 addData 方法,这个方法是我自行编写的,它可能会抛出一个错误。</p>    <p>这里我们就要借助 Swift 的错误处理机制来实现错误处理了,因为可能我访问的服务器并没有返回合法的 JSON 给我。之后就是尝试将更改操作保存到 Core Data 里面,这个操作也可能会抛出错误。</p>    <p>最后,由于我知道当前我正位于后台线程当中,因此我不希望在 Core Data 的队列当中返回我想要的结果,因此我需要在主线程执行这个回调。</p>    <p>通过这样,将使得其他人在调用这个 API 时不会犯太多的错。它们可以直接在回调中修改界面,以及执行其他适合在主线程当中完成的事情。因此我会在 dispatch_async 当中完成这段操作。如果发生了错误,那么我就必须要返回一个错误类型。</p>    <p>实际上,您可以很清楚地看到,在这其中出现了三次嵌套 (interaction) 的回调。这些回调甚至还有可能会嵌套到五次、六次,而这则会导致更糟糕的事情发生。</p>    <h3><strong>为什么要使用 Futures/Promises</strong></h3>    <p>那么什么是 Futures/Promises 呢,为什么人们要使用它们呢?基本上,它们可以帮您摆脱回调的困扰。</p>    <p>我们使用过大量的 JavaScript Promises,它们用起来真的很棒。那么 Future 和 Promise 有什么区别呢?毕竟它们都是用来让您摆脱回调的困扰的,这是它们最主要的作用。</p>    <p>那么这两个词到底什么意思呢,我该什么时候用 Future,什么时候用 Promise 呢?在我见过任何一种实现中,这两者都不一致。JavaScript 只是将事件称之为 Promise,但是 JavaScript 是动态类型的,所以使用起来比较单。此外也有只使用 Future 的相关实现,因为在理论中,所有的操作都可以在一个单独的对象当中完成。</p>    <p>我从 Scala 那里窃取来了 FutureKit 的实现。再次强调一点,这只是一种选择,因为这些实现方案基本上是非常相似的。对于 FutureKit 来说,我们在用户界面当中需要使用 Future 对象。这意味着您的函数很可能需要返回一个 Future 对象。</p>    <p>如果您正在定义诸如函数之类的东西,那么您所提供给用户的 API 需要返回一个 Future 对象,而 Promise 则更为底层,它是用来生成 Future 的东西。我喜欢 Promise 这个词语,因为当您创建一个 Promise 的时候,您必须要信守诺言 (keep promise)。如果您创建了一个 Promise,并返回了一个 Future,那么您就必须要完成这个操作,否则的话您的代码就会异常终止。</p>    <pre>  <code class="language-javascript">func getMyDataObject(url: NSURL) -> Future<MyCoreDataObject> {   let executor = Executor.ManagedObjectContext(managedContext)     Alamofire.request(.GET, url, parameters: ["foo": "bar"])    .FutureJSONObject()    .onSuccess(executor) { response -> MyCoreDataObject in     let myObject = MyCoreDataObject(entity: entity!,      insertIntoManagedObjectContext: managedContext)     try myObject.addData(response)     try managedContext.save()     return MyCoreDataObject    }   }  }</code></pre>    <p>这段代码和我们之前所看到的那一段代码在功能上是一样的。不同的是,这是用 FutureKit 所实现的。</p>    <p>首先,您会看到顶部的函数结构非常不一样,现在回调已经不存在了。它现在只是,接收一个我需要获取数据的 URL 地址,然后返回一个 Future<MyCoreDataObject> 。注意到 MyCoreDataObject 的可选值已经不存在了。</p>    <p>随后我在这里创建了一个 executor 。这是另一个我基于 ManagedObjectContext 所创建的 FutureKit 产物。如果您使用过 Core Data 的话,就会明白,在这里它为您封装好了 performBlock 。</p>    <p>好的,现在我执行了 Alamofire 的网络请求,这个 FutureJSONObject 是 FutureKit 对 Alamofire 的一个扩展,它可以将 response 对象从 Alamofire 的形式转换为 Future。</p>    <p>现在我就可以说了, onSuccess(executor) 意味着,后面的这个闭包就是在 performBlock 当中要运行的那段代码。如果您注意到这里的架构的话,就会发现我可以获取到我所获取的 response 对象,然后返回 Core Data 对象即可。</p>    <p>随后就是 try 操作了。注意到我们没有添加任何的 do 或者 catch 。这是因为这些错误处理已经由 handler 自行帮我们处理好了。因此现在我就可以直接使用 try 来添加数据、保存数据,然后将对象返回即可。</p>    <p>这里的关键在于,这个函数要返回一个名为 Future 的对象,Future 当中拥有许多 handler 来处理里面的内容。</p>    <h3><strong>最主要的 handler: onComplete</strong></h3>    <p>在 FutureKit 当中最主要的 handler 当属 onComeplete 了。如果您切实了解了 onComplete handler,那么您就能明白 FutureKit 当中的其他 handler 是如何工作的了。您会看到,其他的 handler 都是基于这个 onComplete 的便利封装而已。</p>    <pre>  <code class="language-javascript">let newFuture = sampleFuture.onComplete { (result: FutureResult<Int>) ->  Completion<String> in   switch result {     case let .Success(value):    return .Success(String(value))     case let .Fail(err):    return .Fail(err)     case .Cancelled:    return .Cancelled   }  }</code></pre>    <p>我调用了 Future 对象的 onComplete 方法,然后得到了这个名为 FutureResult 的枚举对象。再次强调一下,这个对象是一个泛型,因此这里我们得到的一个包含某种整数值的 FutureResult,然后最后我们会返回一个 Completion 对象。现在我来具体说明一下这两个对象。</p>    <pre>  <code class="language-javascript">public enum FutureResult<T> {   case Success(T)   case Fail(ErrorType)   case Cancelled  }</code></pre>    <p>首先第一个是 FutureResult 。这基本上是每个 Future 结束的时候都会生成的玩意儿。</p>    <p>与其他 Future 的实现所不同的是,FutureKit 增加了一个名为 Cancelled 的枚举。我们来详细解释一下这个 Cancelled ,为什么要把它单独提取出来,而不是放到 Success 或者 Fail 当中,而这种做法往往是其他异步实现方案所做的。</p>    <pre>  <code class="language-javascript">public enum Completion<T> {   case Success(T)   case Fail(ErrorType)   case Cancelled   case CompleteUsing(Future<T>)  }</code></pre>    <p>这是另一个名为 Completion 的枚举。 Completion 似乎很容易让人困惑,但是实际上它很好理解。</p>    <p>最简单的方式就是将 Completion 视为结束 Future 的一项操作。您可以将其视为另一个 Promise,这样它看起来就有点像是 FutureResult,但是它拥有了额外的枚举值:我希望先完成括号里面的 Promise,然后再来完成当前的这个 Promise。这样当我们开始组合 Promise 的时候,它就非常有用了。在这个 onComplete 当中,您实际上可以看到这样的做法。</p>    <pre>  <code class="language-javascript">case let .Success(value):    return .Success(String(value))     case let .Fail(err):    return .Fail(err)</code></pre>    <p>这里实际上有两个不同的枚举。第一个是 FutureResult,第二个是 Completion。</p>    <p>绝大多数时候,您都不会去调用 onComplete 。您只需要在有特殊情况的时候才去调用它。大多数人基本上都只会去调用 onSuccess 。</p>    <pre>  <code class="language-javascript">let asyncFuture5 = Future(.Background) { () -> Int in   return 5  }  let f = asyncFuture5.onSuccess(.Main) { (value) -> Int in   let five = value   print("\(five)")   return five  }</code></pre>    <p>这是一个很典型的例子,它展示了在 FutureKit 当中我们该如何使用这个 onSuccess 。首先我在第一行创建了一个 Future 对象。这是创建 Future 最轻松、最简单的方法了。这里使用了 .Background ,随后我们会对其进行更深的讲解,这是一个很有意思的 executor。</p>    <p>我这里的做法是在后台当中创建一个 Future 对象,我们这里所做的就是生成这个数字 5。假定出于某种特殊的原因,执行这项操作会占用大量的时间,因此我希望在后台完成这项操作,所以我使用这种方法来生成 Future 对象。它实际上会给我们返回一个数字 5,好的现在让我们来看看这个 onSuccess 。</p>    <p>现在我可以说,我需要确保 onSuccess 在主线程上运行,因为我需要执行某种 I/O 操作。我获取 Future 所返回的值,然后将其打印出来。好的现在这个时候, value 实际上是一个值类型,而不是一个枚举了,也就是说,它已经是我们所期望的值了。</p>    <pre>  <code class="language-javascript">let stringFuture = Future<String>(success: "5")    stringFuture      .onSuccess { (stringResult:String) -> Int in          let i = Int(stringResult)!          return i      }      .map { intResult -> [Int] in          let array = [intResult]          return array      }      .onSuccess { arrayResult -> Int? in          return arrayResult.first!      }</code></pre>    <p>Future 不仅能够执行 onSuccess ,而且还可以将其映射为一个新的 Future 对象。</p>    <p>假设我创建了这样一个 stringFuture ,我是从一个函数当中所获取到的。这里我们用了一个简便的方法,来创建一个已完成的 Future 对象。这个 Future 对象会返回一个字符串,并且它已经成功结束了。</p>    <p>接着,在第一个闭包当中,我使用了 onSuccess ,我需要将字符串转换为 Int 类型。Swift 编译器的类型推断非常好用,它会自行知道下个 map 当中实际上会是什么类型,当然您也可以将 onSuccess 称之为 map ,因为这两者的行为非常相似。</p>    <p>现在我会将我所得到的结果映射为 Int 数组。基本上,您可以将任何一种 Future 转换为另一种 Future。您会注意到我们这里的语法非常简明,如果您写过很多函数式和反应式代码的话,那么这种风格您一定不会陌生。因为这些风格非常相似,虽然有所不同,但是都非常简洁、美观、没有任何回调。</p>    <pre>  <code class="language-javascript">func coolFunctionThatAddsOneInBackground(num : Int) -> Future<Int> {   // let's dispatch this to the low priority background queue   return Future(.Background) { () -> Int in    let ret = num + 1    return ret   }  }    let stringFuture = Future<Int>(success: 5)    stringFuture   .onSuccess { intResult -> Future<Int> in        return coolFunctionThatAddsOneInBackground(intResult)   }   .onSuccess {        return coolFunctionThatAddsOneInBackground($0)   }</code></pre>    <p>这就是 Future 所带来的好处了,它可以使得用户界面变得高度可组合 (highly-composable)。这里我给大家展示一个稍微详细一点的示例。</p>    <p>我创建了这个可以在后台执行数字运算的函数。这个函数需要在后台运行,然后将传递进去的数字加一,至于这样做的理由,是出于某种原因我们不希望在主线程运行它。现在,如果您注意到的话,我创建了这个 stringFuture ,这个 stringFuture 和之前的相同,但是我要做的是返回一个新的 Future,而不是返回一个新的数值。因此我们可以使用 map ,将这个值映射到另一个 Future。</p>    <p>Futures/Promises 让代码变得易于组合。所有的 Future、Promise 的实现基本上都是由这些基本结构所组成的。这个特性非常讨人喜欢。</p>    <p>那么什么是 Promise 呢?假设您需要在某个地方去创建一个 Future 对象。我创建了一个 Promise,这个 Promise 会返回一个字符串数组。随后,当我调用 completeWithSuccess 之后,我就可以得到这个真正的字符串数组了。</p>    <p>```swift</p>    <p>let namesPromise = Promise<[String]>()</p>    <p>let names = [“Skyler”,”David”,”Jess”]</p>    <p>namesPromise.completeWithSuccess(names)</p>    <p>let namesFuture :Future<[String]> = namesPromise.Future</p>    <p>namesFuture.onSuccess(.Main) { (names : [String]) -> Void in</p>    <p>for name in names {</p>    <p>print(“Happy Future Day (name)!”)</p>    <p>}</p>    <p>}</p>    <pre>  <code class="language-javascript">这意思是说,我实现了这个 Promise,如果 Promise 允诺了,那么我们就得到了结果。您会注意到,所有的 Promise 都包含这样一个名为 `.Future` 的成员。这就是您可以返回的 Future 对象,这是用来让 Promise 操作用户界面的方式之一。这样我现在就可以来实际执行这个 Promise。    ```swift    func getCoolCatPic(catUrl: NSURL) -> Future<UIImage> {     let catPicturePromise = Promise<UIImage>()     let task = NSURLSession.sharedSession().dataTaskWithURL(catUrl) { (data, response, error) ->  Void in    if let e = error {     catPicturePromise.completeWithFail(e)    }    else {     if let d = data, image = UIImage(data: d) {      catPicturePromise.completeWithSuccess(image)     }     else {      catPicturePromise.completeWithErrorMessage("didn't understand response from \  (response)")     }    }   }   task.resume()      // return the Promise's Future.   return catPicturePromise.Future  }</code></pre>    <p>通常情况下,当您需要 Promise 的时候,这就意味着您需要封装某种接收回调为参数的东西。如果您遇到了某个使用了回调的第三方库的话,那么你可以借助 Promise 将它们 Future 化,以将它们转换成 Future 的形式。</p>    <p>这里我举了一个很典型的例子,我是从 FutureKit 当中的 Playground 取出来的例子,这段代码的作用是获取一些可爱的猫咪照片。在幻灯片里面效果不是很好,因为在 Playground 当中,您可以切实看到猫咪的图片,但是这里你只能想象这段函数能够获取到猫咪的图片。</p>    <p>我需要这样一个函数,给定 URL,然后返回图片给我。仔细想一下,为了获取这个图片对象,我不仅需要访问网络,从我的网络层那里将数据对象拉取下来,还需要将这个数据对象转换为 UIImage ,然后再将其返回。所有的这些步骤都已经封装在这个函数里面了。</p>    <p>我将准备使用标准的 NSURLSession 。它接收我的 URL 为参数,然后现在我完成了这个回调 response 的设置。我从中拿取到了我需要的 data、response 和 error 对象,然后我就可以开始对其进行解析了。</p>    <p>如果我接收到了错误,那么我就需要让我的 Promise 以失败告终。如果我接收到了 data,并且还可以将其转换成为图片,那么我的 Promise 就是成功的。如果这个操作失败了,并且我也不想创建一个自定义的错误类型的话,那么我就使用这个内置的错误方法,提示“我无法识别这个 response”。我们以这个 NSURLSession 开始,然后以 Future 结束。</p>    <p>如果您对它运行的方式有疑问的话,其实这整个内部的闭包随后才会运行,但是这个 Future 会被立即返回。您可以知道这个 Future 当中封装了哪些内容。</p>    <h3><strong>如何进行错误处理呢?</strong></h3>    <p>现在让我们来看一下错误和错误处理。这正是我觉得 Future 的妙处所在,因为这样只要您的步骤正确,那么您就不用考虑潜在的问题了,Future 的错误处理非常好用。</p>    <p>当我们在处理回调的时候,对于每个封装的单独 API 回调来说,我们都必须要处理错误情况。您必须要大量地检查错误。我不喜欢在回调中大量添加错误处理,因为它们会让回调变得更加复杂、更加糟糕。</p>    <p>例如,假设您准备调用某个 API。然后突然发生了网络问题。假设我正从服务器获取一个 JSON 对象,因此有可能是我的 JSON 解析发生了错误,也有可能是验证出现了问题。好的现在我要对这些问题进行处理了,一旦我成功对对象进行了解析,那么我就需要将其存储在数据库当中。然后又发生了文件 I/O 的问题,或者也有可能是数据库内部数据验证的问题。</p>    <p>这些问题都很有可能会发生。我希望能够给调用者提供一个高度封装的 API,它只执行某一件事情,而其他的错误则不必去关心。在 Future 的世界里,这意味着如果您的操作一切正确,那么 Future 将会输出正确的结果。</p>    <p>FutureKit 并不会让您去定义特定错误类型的 Future。当您尝试去创建特定错误类型的 Future 时,它实际上破坏了架构的可组合性 (composability),正如您前面所看到的那样。因为这样的话您就必须要将所有的组合进行过滤,不停地进行 map 转换以分别处理不同的错误情况。您可能会觉得这种做法挺好的,但实际上它使得代码变得更糟了。</p>    <p>另一个关于 FutureKit 的是,由于它没有特定错误类型,因此您会注意到它同样也没有 ErrorType 。有人总会建议您去创建一个不会返回 Error 的 Future,但是我们发现,这种做法实际上还是破坏了 Future 的可组合性。对于异步来说,它的核心思想在于这个操作有可能不会成功。就算现在不会出错,那么将来的某一天还是可能会出错。那么这种类型的 Future 来说,它们只能在没有错误发生的条件下才能正常工作。</p>    <p>那么让我们来看一下 FutureKit 是怎么做的,如果您创建了一条 Future 调用链,但是您忘记在末尾加上错误处理的话,那么您会得到一个编译警告。它会告诉您:“您调用了 Future,但是我没有发现您对错误有任何的处理。”</p>    <p>关于 FutureKit 的另一个好处在于,您所看到的这些 handler: onComplete 、 onSuccess 、 onFail 。它们都内置了 catch 。因此您就不必再用 catch 或者 do 去包装这些方法了。如果您调用的 Swift 方法需要使用 try 的话,那么不必担心。直接加上 try 即可,Future 在内部已经自行帮您完成了基础的错误处理了。</p>    <pre>  <code class="language-javascript">func getMyDataObject(url: NSURL) -> Future<MyCoreDataObject> {   let executor = Executor.ManagedObjectContext(managedContext)     Alamofire.request(.GET, url)    .FutureJSONObject()    .onSuccess(executor) { response -> MyCoreDataObject in     let myObject = MyCoreDataObject(entity: entity,         insertIntoManagedObjectContext: managedContext)     try myObject.addData(response)     try managedContext.save()     return MyCoreDataObject    }.onFail { error in     // alert user of error!   }  }</code></pre>    <p>现在,您就可以看到这个好用的 onFail handler 了。我回到我之前的例子当中,然后添加了这个 onFail handler,因为如果我对老代码进行编译的话,那么我会得到一条编译警告。现在我加上这条之后,就没有任何副作用了。</p>    <p>在 FutureKit 当中,还有一点和其他解决方案不同。 onFail handler 并不会去干涉错误。这和 JavaScript 不同,您会选择去调用 catch,因为这样您就不用去理会错误了。但是实际上 catch 仍会对错误有所干涉,也就是说如果您如果在函数中使用了 catch 的话,那么人们很有可能会忘记您实际上对这个错误添加了某些副作用,如果不对这个错误进行处理,那么程序就很可能会发生崩溃。</p>    <p>FutureKit 强制要求需要对错误编写 handler,因为您写的函数是异步的,我们都知道,异步操作很有可能会失败。 onFail 的目的在于处理错误,而不是捕获错误。因此您没必要将错误进行传递;您必须要使用 FutureKit 中的 onComplete 。</p>    <p>虽然这可能只是所谓的习惯问题,因为 onFail 实际上已经可以执行很多操作了,但是我对我手下的开发者们并不信任,它们不一定会对去写 onFail 。</p>    <p>现在您知道,当您在使用 onComplete 的时候,有人可能会将 onComplete 的涵义混淆起来,例如将一个失败的 Future 转换为一个成功的 Future。这种情况只占十分之一。其余的时候,如果 Future 失败了,您可能只是希望能够将中间数据清理掉,然后通知用户即可。</p>    <h3><strong>取消操作 (Cancellation)</strong></h3>    <p>好的,另一个您会在 FutureKit 当中看到的重要东西就是取消操作了。这是每个异步操作都可以使用的操作。当您开始一个异步操作的时候,您或许会意识到这个操作的结果是不需要的。您不希望那些 handler 被运行,因为这些 handler 已经毫无意义了。举个例子,您打开了某个视图,然后开始从网络上提取需要的数据,然后接着您点击了返回,关闭了这个视图控制器。而这个时候这个异步操作仍然还在运行,这个时候我们需要将其清除掉。</p>    <p>现在,我们可以添加 onCancel 操作了。当我需要知道某个异步操作有没有被取消的时候,我们通常使用 onComplete 来完成。FutureKit 的取消操作非常好用。如果您看过 Github 上的源码的话,您会发现虽然代码不是很长,但是要明白它实际的运行原理还是非常困难的。</p>    <p>现在让我们看一下这个会返回 Future 的函数:</p>    <pre>  <code class="language-javascript">let f = asyncFunc1().onSuccess {   return asyncFunc2()  }  let token = f.getCancelToken()  token.cancel()</code></pre>    <p>这个函数已经和一个 onSuccess 组合在了一起,它接着会返回第二个 Future。问题是,如果我在上面调用了 onCancel ,那么我是取消了 asyncFunc1 还是取消了 asyncFunc2 呢?</p>    <p>实际上这两个函数都会被取消掉。它会先取消第一个函数,然后如果第一个已经完成了,那么您也不必担心,它会取消第二个函数。如果您需要实现取消操作的话,那么很简单。在 Promise 上有一个 handler,它可以标明需要一个可取消的 Future。当您被告知 Future 被取消之后,您就需要对相关内容进行清除操作了。</p>    <pre>  <code class="language-javascript">let p = Promise<Void>()    p.onRequestCancel { (options) ->  CancelRequestResponse<Void> in   // start cancelling   return .Continue  }</code></pre>    <p>这实际上是一个枚举的 response,您既可以声明您暂时还不想要取消 Future,因为需要等待清理操作完成,或者也可以直接取消 Future。</p>    <pre>  <code class="language-javascript">public extension AlamoFire.Request {   public func Future<T: ResponseSerializerType>(responseSerializer s: T) -> Future<T.SerializedObject> {    let p = Promise<T.SerializedObject>()    p.onRequestCancel { _ in     self.cancel()     return .Continue    }    self.response(queue: nil, responseSerializer: s) { response -> Void in     switch response.result {     case let .Success(t):      p.completeWithSuccess(t)     case let .Failure(error):      let e = error as NSError      if (e.domain == NSURLErrorDomain) && (e.code == NSURLErrorCancelled) {       p.completeWithCancel()      }      else {       p.completeWithFail(error)      }     }    }    return p.Future   }  }</code></pre>    <p>您可以在 handler 中同时完成两个操作。我回到之前我用 FutureKit 对 Alamofire 做的扩展封装示例当中。我在这里对 Alamofire 序列化对象进行操作。这个函数是个泛型函数,允许我将 Alamofire 序列化对象转换为 Future。</p>    <p>第一个事情是为试图序列化的对象创建一个 Promise,然后为其添加取消 handler。</p>    <p>如果我需要执行取消操作的话,那么我就会调用这个 self.cancel ,这是内置的 Alamofire 取消请求方法,然后如果需要继续执行的话。那么接下来您会看到在这里,我对错误结果进行了处理,如果我发现错误是用户取消操作的话,那么我就让其 completeWithCancel 。</p>    <h3><strong>新的 Swift 反面模式 (anti-pattern)</strong></h3>    <p>一旦您理解了 Future 的原理,那么当您再去看自己的代码时,就会意识到原来的代码已经变成了一种全新的反面教材。当您看到别人的代码时,您会坐立不安:“请一定不要继续这么下去了!“</p>    <p>其中一个反面模式就是那些带有回调属性的函数。当您看到它们的时候,就意味着麻烦来临了。另一个反面模式就是,我注意到,当初学者开始使用 Future 的时候,他们通常都会创建带有可选值结果的 Future。一般而言,这是不必要的。我们一般情况下是不会需要可选值的存在的。</p>    <p>因为在回调中,之所以回调方法需要接受可选值作为参数,是因为所得到的不一定是实际结果,也有可能得到错误。如果没法得到预期结果的话,那么就说明这个过程肯定是失败了,这才是正确的做法。</p>    <p>还有一件非常重要的事,这可以让您写出优秀的 Future 实现,就是如果我需要能够运行在后台的操作的话,那么我们应该让函数自身来定义自己的运行环境上下文 (execution context)。</p>    <p>因此,对于我的这个图像库而言,我不希望它会在主线程上运行,而且我也不用让调用 API 的人员来操心这件事。我只需要让函数自身前往到合适的线程上去运行即可。我们接下来会谈论一下这是如何工作的。</p>    <h3><strong>Executors</strong></h3>    <p>FutureKit 当中,另一块重要的部分就是 executor 了。在 Future 其他语言的实现当中,它的名字可能会被命名为 ExecutionContext 。这是受到了 Bolts Executors 的启发。</p>    <p>FutureKit 的 executor 实际上是一个枚举。正如您所注意到的,FutureKit 非常喜欢使用枚举。FutureKit 当中的 Executor 类所有的枚举值都与内置的 GCD 建立了镜像关系。绝大多数时间,您都只是使用内置的 GCD。很快,我就收到了反映这些名字的一系列数字。</p>    <pre>  <code class="language-javascript">let asyncFuture5 = Future(.Background) { () -> Int in   return 5  }  let f = asyncFuture5.onSuccess(.Main) { (value) -> Int in   let five = value   print("\(five)")   return five  }</code></pre>    <p>这就是我觉得 FutureKit 设计得非常好的地方。我创建了一个 Future,然后我希望它能够在后台运行,然后我运行了它。也就是用这个 onSuccess 命令来执行。我可以在这里添加一个 executor。</p>    <p>实际上,executor 的种类有很多种。不过有一些是比较特殊的。首先是 .Immediate executor。这个即时 executor 意味着,我不在乎这个代码块在何处运行。它可以在任何地方运行。通常而言这是最常用、最有效率的 executor 了。我们通常而言都会直接使用这个 executor。比如说我们这里接收一个整数为参数,然后将其转换成字符串,而它运行的地方我们并不在乎。因此我们不必重新调整线程。</p>    <p>此外还有 .MainImmediate ,这意味着我希望代码块在主线程运行,但是如果代码已经在主线程上运行了,那么就不用对线程进行调整了。如果没有的话,那么就将线程调整到主线程。还有 .MainAsync ,它意味着代码始终需要异步派遣 (async dispatch)。比如说某个委托非常奇怪,您必须要让委托结束运行,但是你还需要这段代码能够运行。</p>    <p>然后还有一些 executor,比如说您已经创建了自己的派遣队列,那么您可以将这个队列封装到一个 executor 当中。您也可以将 NSOperationQueue 封装到 executor 当中。如果您还需要处理闭包操作的话,您还可以将管理对象上下文 (managed object context) 封装到 executor 当中。</p>    <p>然后,还有一些非常智能的 executor。我毕竟倾向于使用这些 executor,因为它们实际上将多个 executor 的行为整合在了一起。您可以在代码当中声明它们,然后它们会在运行时映射为实际需要的 executor。最好用的一个就是 .Current 了。如果您已经使用了一个 executor 了,那么它会接着使用这个 executor。因为事实证明,对于程序员来说,因为您已经使用了一个 executor 了,一般那么就没必要再去创建一个新的了。代码一旦在后台执行了,那么就说明这段代码会一直想留在后台运行。</p>    <p>好的,如果您在某个 executor 当中封装了自己的执行操作,或者并没有给 FutureKit 定一个 executor 的话,那么它会自行去推断合适的 executor。是谁在调用这段代码呢?这段代码位于何种运行操作上下文当中?我会确保这个闭包会自行进入到运行操作上下文档中,即使内部的方法决定需要去后台执行,它也会一直如此。</p>    <p>下一个 executor 就是 .Primary 了。所谓的 .Primary 就是指那种您没有告知 FutureKit 您正在使用的是何种 executor,也没有说明您需要何种 executor,这是 executor 的默认值。最后四个都是可配置的,它们都是某种 FutureKit 的操作。</p>    <p>我倾向于使用的 executor 是这个 .Async ,这意味着,我需要前往后台的某处来运行这段代码,或许随后我会决定要不要为默认操作改变 QoS。</p>    <p>最后就是这个 .Custom 了, .Custom 允许您构建属于自己的 executor。举个示例,假设我有这样一个所需要的操作,它需要在主线程当中运行,但是我可能需要在后台队列当中花点时间来处理这段操作,因为这个操作并不是很重要。</p>    <p>我们来举个比较怪异的例子吧,我们可以创建一个 executor,它会在后台执行,然后等待某个事件完成之后,又重新回到主线程来执行。</p>    <pre>  <code class="language-javascript">let ex: Executor = .Background    let f = ex.execute {   let data = expensiveToComputeData()   return data  }</code></pre>    <p>executor 同样也有很好用的执行方法,这也是一种生成 Future 的简单方式。您在这里可以注意到,我创建了一个在后台运行的 executor,然后我调用了它的 execute 方法。我调用了某个方法,这个方法用来获取数据,但是非常地耗时间,然后我需要将这个数据返回。此外,还有一些带有延迟和额外事件的 execute 方法。</p>    <pre>  <code class="language-javascript">let shiftFuture = model.getShift()  let vehicleFuture = model.getVehicle()    combineFutures(shiftFuture, vehicleFuture)   .onSuccess { (shift,vehicle) -> Void in    print("\(shift),\(vehicle)")  }</code></pre>    <p>接下来,我们要做的就是将 Future 联合起来。在这个例子当中,我们需要并发执行。当我们有一系列需要一起运行的操作时,我们并不希望让它们一个个地运行。我们想要让这些操作全部立刻执行,因为您可能实在进行某种配置操作。让我们来运行以下这段代码,没有理由我们必须要将它们序列化。</p>    <p>combineFutures 是一个非常好用的、类型安全的函数,它接收两个 Future 为参数,然后会创建一个带有双元结果的新 Future。或许我有某种能够生成 Shift 模型对象或者 Vehicle 模型对象的模型,现在我将准备把这两个 Future 组合成一个单独的 Future。当两个操作都成功之后,它将会把结果返回给我。再强调一遍,只要任意一个 Future 失败了,那么整个 Future 集都将失败。</p>    <pre>  <code class="language-javascript">public protocol CompletionType {   associatedtype T   var completion : Completion<T> { get }  }</code></pre>    <p>我想要再深入地谈一下 FutureKit 所做的东西。这个 CompletionType 协议是一个更高级的玩意儿。这是 FutureKit 的一个扩展,它可以让您自行建立想要的东西,它已经是异步化的了。</p>    <p>或许您想要将 Alamofire 的网络请求改造成一个 Future,那么您可以使用这个协议对其进行扩展,然后将其转换成相应的类型,这样 FutureKit 就可以自行将其翻译,最后生成一个 Future。因此,这个新的请求就可以被加到 Future 的 handler 当中,这确实非常方便。</p>    <pre>  <code class="language-javascript">public protocol ErrorTypeMightBeCancellation : ErrorType {    var isCancellation : Bool { get }  }</code></pre>    <p>这里有一个问题,我之前说过,取消操作并不是错误。但是如果您的某个库将取消操作视作错误的话,并且您还希望将这个错误转变为对应的取消操作,那么您可以使用这个 ErrorTypeMightBeCancellation 对错误进行扩展。之后您就可以计算 isCancellation 属性是否为真。只要为真,一旦这个错误在 handler 当中发生,那么 FutureKit 会自行将它转换为取消操作。</p>    <h3><strong>进阶事项及结论</strong></h3>    <p>既然您对这些基础知识已经有所了解了,那么我们下面就来聊一聊进阶事项吧!我不会去将这些第三方库的实现细节,但是我会给大家大概讲解一遍。</p>    <pre>  <code class="language-javascript">NSCache.findOrFetch(key, expireTime:NSDate? = nil,  onFetch: () -> Future<T>)</code></pre>    <p>为 Future 建立缓存是我一直想要做的事情。之所以这么做,是因为当您进行了一个时间耗费长的操作时,那么这项操作就必须异步进行,然后当该操作完成之后,您就可以将这个操作的结果缓存起来,这样就不用再次去执行这个操作了。比如说图像缓存之类的时间耗费长的操作就很适合进行缓存。</p>    <p>但是缓存同样也会带来不好的问题,因为当这个异步操作开始的时候,只有当其成功结束之后才能够保存到缓存当中。当您用多了 Future 或者之类的异步后台运行代码的时候,您会发现很可能会有多个地方都需要执行这个操作,那么在第一个操作结束缓存之前,那么这些地方都仍将继续执行异步操作。</p>    <p>我们可以通过一点小小的技巧来规避这个问题,这就要用到 NSCache 上的一个既有的扩展了。也就是 findOrFetch 函数,它允许您通过定义键来寻找缓存,如果查找失败,那么您就可以返回一个方法,这个方法返回一个 Future,接着 NSCache 就会去进行检索。接下来,如果其余的请求命中了这块缓存的话,那么它们所得到的都将是同一个 Future。它们都将获取同一个结果,这样您就可以加快这个异步请求的速度了。</p>    <p>此外,还有一个名为 FutureBatch 的对象。当 combineFutures 力不从心的时候,尤其是您拿到了一个未知类型的 Future 数组并且也不知道里面有多少个 Future 的时候, FutureBatch 就派上用场了。此外,当其中的某个子 Future 失败的时候,如果您还需要进行很多控制和决定,比如说决定整个批次的 Future 是否都会全部失败,还是仅失败的那个子 Future 失败?如果您需要得到每个子 Future 的独立结果,那么请使用 FutureBatch 。</p>    <p>此外还有 FutureFIFO ,麻雀虽小,五脏俱全。</p>    <pre>  <code class="language-javascript">let fifo: FutureFIFO()  let f:Future<UIImage> =   fifo.add {    return functionThatBuildsUImage()  }</code></pre>    <p>另一件严肃的问题是,当您在撰写大量的异步代码时,您会意识到您需要进行序列化操作。 FutureFIFO 的特性是先进先出。它为您提供了一个 add 方法,您只需要重新返回一个 Future 即可。它确保这些要允许的代码块,在上一个代码块完成其 Future 之前,都不会运行。</p>    <p>这和队列分割有所不同,队列分割会确保代码块一定会运行。这里是逻辑上的异步队列。最好的例子就是下面这个经典调用:</p>    <p>首先,我要去与服务器通信。这时候我进行了某种 REST 操作,我要确保我能够执行 API 调用,并且还能够得到返回的 JSON 数据,之后我要去修改数据库,然后将数据写入到数据库当中,最后将结果返回,然后我就不想要进行下一个 API 调用了。我希望下次能够直接从数据库当中读取这个已写入好的数据。</p>    <p>但是由于每次调用都位于不同的异步队列当中,这意味着所有的操作都会被执行。在这儿,您可以将其推入到 FIFO 队列当中,这样在前一个操作完成之前,后面的模型操作都不会进行。</p>    <pre>  <code class="language-javascript">NSOperationQueue.add<T>(block: () throws -> (Future<T>)) ->  Future<T>    let opQueue: NSOperationQueue  let f:Future<UIImage> =   opQueue.add {    return functionThatBuildsUImage()  }</code></pre>    <p>NSOperation 写起来很烦人,但是当您使用诸如 Future 之类的实现方式的时候,那么写起来就会很容易了。</p>    <p>让我们说一说我的想法,我不想使用 FIFO,也不是对并行层级进行控制。假设,我有一个图像操作的批处理集,并且我知道在我的 iPad 上有三个核心,然后我想要同时运行两个图像操作。我或许会使用 NSOperationQueue ,将兵法层级设定为 2,然后我就可以添加运行这些代码块的方法,从而在 NSOperationQueue 内部运行。</p>    <p>现在我们使用 Future 来干掉这些恼人的委托。如果大家看过这些委托代码的话,就会意识到委托是异步操作当中最可怕的东西之一,它会将您的 iOS 或者 macOS 代码变得杂乱不清的毛线团,因为代码逻辑将会缠绕在一起,很难分离。</p>    <p>有些时候人们甚至还会与视图控制器进行交互,当视图控制器完成之后,就会有某种回调的委托来通知您结果如何。我们要做的就是给视图控制器添加一个属性,如果您想要知道用户何时选择了某样东西的话,那么您需要创建一个 Future。如果要进行操作的东西有很多不同的输出的话,那么我们可以创建一个枚举值。用户选取之后,就会生成 Future 结果。</p>    <pre>  <code class="language-javascript">public extension SignalProducerType {    public func mapFuture<U>(transform: Value ->  Future<U>?) -> SignalProducer<U?, Error>  }</code></pre>    <p>关于 Future 和 <strong>Reactive</strong> 之间的区别,有很多人问了我这个问题了。但事实上,Future 和 Reactive 可以很好的协同工作,只要您了解何时使用 Future,何时使用 Reactive 即可。</p>    <p>我发现很多人使用 Reactive 代码来完成本该是 Future 所做的事,因为他们知道这些工作该如何在 Reactive 当中进行。假设我有一个会随时变化的信号量,并且我想要进行监听,那么您就需要使用 Reactive 了,例如 RxSwift 或者 ReactiveCocoa。</p>    <p>如果您只是到后台当中执行操作,然后返回一个简单的结果,最后就把信号量给关闭掉,那么您应该使用 Future 而不是 Reactive,因为 FutureKit 当中的可组合性正是您所希望的。</p>    <p>如果您尝试将这些异步第三方库当中的异步操作给组合起来,您会发现这会非常、非常困难。而使用 Future 的话,你只需要匹配和回取数据,然后在后台执行,最后就可以得到一个结果,万事大吉。</p>    <h3><strong>问答时间到</strong></h3>    <p><strong>问:可否动态组合 Future 呢?也就是说,当您需要向服务器进行某些 Pull 操作,但是在操作完成之前又无法知道需要多少 Pull 操作的时候,对于 API 的使用者来说,能否用简单的 Future 来完成这项操作呢?</strong></p>    <p>Michael:这个时候您需要使用 Promise。您不应该去试图组合 onComplete 和 onSuccess ,我们已经有一个方法表明可以前往服务器,然后尝试拉取数据,接着如果读取失败的话就返回,而不应该去封装这个步骤,我们只要找到这个所需的 Promise 对象即可,非常简单,呃,我需要尝试多少次呢?完全无需进行重试,睡一觉起来再试就行了。所以实际上这个问题并不是很困难,但是正如您所说的,这并不是一个很直观的思路。</p>    <p><strong>问:我所开发的 App 已经用了很多 Reactive 了,比如 RxSwift。我在想您能否分享一些 Future/Promise 与 Reactive/Rx 之间互用的编程范式呢?</strong></p>    <p>Michael:典型的例子就是:您可能会需要进行一系列操作,然后您想要将其插入到某个异步操作当中。那么使用 Future 和 ReactiveCocoa 来构建动作是非常简单的。与此同时,也有很多 Reactive 能实现而 Future 不能实现的操作。我通常情况下会告诉人们,Future 的好处在于降低组合的难度。我们可以把多个 Future 组合在一起,然后同时等到一个期望的结果。这就是 Future 的优势所在。</p>    <h3><strong>参考资料</strong></h3>    <ul>     <li><a href="/misc/goto?guid=4959719947989183939" rel="nofollow,noindex">FutureKit for Swift</a></li>    </ul>    <p> </p>    <p> </p>    <p>来自:http://www.tuicool.com/articles/ZfAf6vN</p>    <p> </p>