RxSwift - Why
Rx 可以使用一种声明的方法来构建 app
绑定
如下代码：
Observable.combineLatest(firstName.rx_text, lastName.rx_text) { $0 + " " + $1 }
.map { "Greetings, \\($0)" }
.bindTo(greetingLabel.rx_text)在 UITableView 和 UICollectionView 同样起作用：
viewModel
.rows
.bindTo(resultsTableView.rx_itemsWithCellIdentifier("WikipediaSearchCell", cellType: WikipediaSearchCell.self)) { (_, viewModel, cell) in
cell.title = viewModel.title
cell.url = viewModel.url
}
.addDisposableTo(disposeBag)官方建议总是使用 .addDisposableTo(disposeBag) 即使对于简单绑定来说那不是必要的。
重试
如果 API 不会失败，这将是非常好的，但是不幸的是 API 也会失败。请看一个 API 的方法：
func doSomethingIncredible(forWho: String) throws -> IncredibleThing如果你正在使用这个函数，万一失败真的很难重试，更不要说复杂建模 [指数退避]. 当然这是可能的，虽然代码可能包含了很多短暂的状态，但是你不用关心，并且他也不会复用。
理想情况下，你会想捕捉重试的本质，并应用到任何操作。
下面的代码是一个在 Rx 中使用重试的简单的例子：
doSomethingIncredible("me")
.retry(3)你也可以简单的创建自定义 retry 操作。
委托
使用下面的代码替代了复杂的操作：
public func scrollViewDidScroll(scrollView: UIScrollView) { [weak self] // what scroll view is this bound to?
self?.leftPositionConstraint.constant = scrollView.contentOffset.x
}偏移量：
self.resultsTableView
.rx_contentOffset
.map { $0.x }
.bindTo(self.leftPositionConstraint.rx_constant)KVO
如下面的代码：
-(void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context使用 rx_observe和rx_observeWeakly 来替代。
用法如下:
view.rx_observe(CGRect.self, "frame")
.subscribeNext { frame in
print("Got new frame \\(frame)")
}或者
someSuspiciousViewController
.rx_observeWeakly(Bool.self, "behavingOk")
.subscribeNext { behavingOk in
print("Cats can purr? \\(behavingOk)")
}通知
如下代码:
@available(iOS 4.0, *)
public func addObserverForName(name: String?, object obj: AnyObject?, queue: NSOperationQueue?, usingBlock block: (NSNotification) -> Void) -> NSObjectProtocol... 只需要写成这样：
NSNotificationCenter.defaultCenter()
.rx_notification(UITextViewTextDidBeginEditingNotification, object: myTextView)
.map { /*do something with data*/ }
....过渡状态
在编写异步程序的时候过度状态还是有很多问题，一个典型的例子就是自动搜索框；
如果你没有使用 Rx 编写了自动完成代码，第一个问题可能就是当输入『abc』中的『c』时需要解决，挂起『ab』的请求，挂起的请求会被取消。不过不是很难解决，你只需要添加一个附近爱的变量来持有挂起的请求就可以了。
下一个问题是如果请求失败，你需要做的就是混乱的重试逻辑，捕获需要被清理的重试操作。
如果程序在向服务器发送请求之前会等待一段时间，那将是会非常好的。
还有一个问题就是当执行搜索的时候，屏幕上需要显示什么，如果搜索失败了重试操作的时候应该显示什么。
编写所有的这些情况以及核实的测试都将会让人感到麻烦，但是使用 Rx 可以完成同样的逻辑。
searchTextField.rx_text
.throttle(0.3, scheduler: MainScheduler.instance)
.distinctUntilChanged()
.flatMapLatest { query in
API.getSearchResults(query)
.retry(3)
.startWith([]) // clears results on new search term
.catchErrorJustReturn([])
}
.subscribeNext { results in
// bind to ui
}没有附加的标志或请求字段，Rx 关心所有的过渡。
组合处理
让我们假设有一个场景，你想要在 tableView 上显示模糊的图片。首先，图片应该从一个 URL 获取，然后解码，接着进行模糊处理。
如果对 tableView 上可见的 cell 取消额外的操作是非常好的，因为绑定宽度和处理器对于模糊处理都是很费时的。
当 cell 刚进入 tableView 的可视区域的时候，我们才去获取图片，这种做法也是可以的，因为如果用户滑动的太快，那么很多的请求就会被取消了。
如果我们限制并发图片操作的数量也是很好的，因为模糊图片是费时的操作。
我们可以使用 Rx 来完成这些操作。
// 这是一个概念上的解决方案
let imageSubscription = imageURLs
.throttle(0.2, scheduler: MainScheduler.instance)
.flatMapLatest { imageURL in
API.fetchImage(imageURL)
}
.observeOn(operationScheduler)
.map { imageData in
return decodeAndBlurImage(imageData)
}
.observeOn(MainScheduler.instance)
.subscribeNext { blurredImage in
imageView.image = blurredImage
}
.addDisposableTo(reuseDisposeBag)当 imageSubscription 被处理的时候，上面的代码会完成所有的操作，它将会取消所有依赖的异步操作，并且确保没有恶意的图片绑定到 UI 上。
聚合网络请求
如果你需要发送两个请求，并且当它们都完成的时候把结果聚合到一起，应该怎么办呢？
当然，有 zip 操作符：
let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<Friends> = API.getFriends("me")
Observable.zip(userRequest, friendsRequest) { user, friends in
return (user, friends)
}
.subscribeNext { user, friends in
// bind them to the user interface
}如果那些 api 将会在后台进程返回结果，那么绑定操作必须在主界面线程上发生吗？有一个方法 observeOn。
let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<[Friend]> = API.getFriends("me")
Observable.zip(userRequest, friendsRequest) { user, friends in
return (user, friends)
}
.observeOn(MainScheduler.instance)
.subscribeNext { user, friends in
// bind them to the user interface
}使用 Rx 还有更多实际的情况。
状态
允许变化的语言可以更容易地访问全局状态并且改变它。不受控制的改变共享的全局状态可以轻易地导致[组合崩溃] (https://en.wikipedia.org/wiki/Combinatorial_explosion#Computing)。但是在另一方面，当使用一种巧妙的方式，命令式语言可以编写出更高效的代码，从而更接近硬件。
通常对抗组合崩溃的方法是尽可能简单的保持状态，并且使用单向数据流来获取模型数据。
这就是 Rx 的亮点所在。
Rx 是在函数和必要世界之间的平衡点。它可以让你使用不可变的定义和虚函数，在一个可靠的组合方式里来处理可变状态的快照。
那么什么是一些简单的例子呢？
容易集成
如果你需要创建你自己的 observable应该怎么操作呢？那相当简单。这些代码是从 RxCocoa 和所有你需要使用 NSURLSession包装 HTTP 请求。
extension NSURLSession {
public func rx_response(request: NSURLRequest) -> Observable<(NSData, NSURLResponse)> {
return Observable.create { observer in
let task = self.dataTaskWithRequest(request) { (data, response, error) in
guard let response = response, data = data else {
observer.on(.Error(error ?? RxCocoaURLError.Unknown))
return
}
guard let httpResponse = response as? NSHTTPURLResponse else {
observer.on(.Error(RxCocoaURLError.NonHTTPResponse(response: response)))
return
}
observer.on(.Next(data, httpResponse))
observer.on(.Completed)
}
task.resume()
return AnonymousDisposable {
task.cancel()
}
}
}
}好处
简而言之，使用 Rx 就爱你过会使你的代码：
- 可以组合的 <- 因为 Rx 是组合的昵称
- 可复用的 <- 因为它是可组合的
- 可声明的 <- 因为定义是不可改变的，而只是数据改变
- 可理解的和简洁的 <- 提高抽象水平并且移除过渡状态
- 稳定的 <- 因为 Rx 代码通过了单元测试
- 更少的状态 <- 因为你是单向数据流的建模应用程序
- 没有泄露 <- 因为资源管理是容易的
这不是全部
通常好的想法，你可能使用 Rx 来为你的大部分应用程序建模。
但是如果你不知道所有的操作符以及是否存在一些在特殊情况下建模的操作符那么该怎么办呢？
所有的 Rx 操作符都基于数学，并且非常直观。
好消息是大约10-15个操作符覆盖了大多数典型的使用情况。并且，这些名单已经包括了一些熟悉的操作符，比如map, filter, zip, observeOn, ...
有一个所有 Rx 操作符 巨大的列表，并且列出了包含所有 支持当前 RxSwift 的操作符。
每个操作符，都对应一个 宝石图 解释了它的用法。
但是如果你需要一些操作符没有在列表上怎么办？好吧，你可以创建你自己的操作符。
如果创建某种操作符由于某些原因非常困难，或者你有一些遗留的状态代码那该怎么办呢？你已经把自己搞得一团糟了，但是你可以容易地 跳出 Rx monads 处理数据，并且返回到它。