RxSwift:ReactiveX for Swift 翻译
RxSwift
|
|-LICENSE.md
|-README.md
|-RxSwift --- 平台核心
|-RxCocoa --- 对UI,NSURLSession,KVO...的扩展
|-RxBlocking --- block 操作符集合,仅用于单元测试
|-RxExample ---
|-Rx.xcworkspace --- 包含所有project的workspace
闲来逛逛哦rxswift.slace.com
1. Why
写出稳定而又快速的代码是何其的难,这个过程中有许多坑,这些坑足以让你毁了你的所有的辛勤付出。
State 状态
允许修改的语言很容易访问全局状态并修改它,未受控制的状态的修改很可能会导致程序的混乱崩溃(combinatorial explosion),但是从另一方面来说,强类型语言能都写出更高效的代码,这中方式就是尽可能地保持状态简单,并使用单项数据流来模型化数据,这就是Rx
的闪光处
Bindings 绑定
当你写UI app的时候,理想情况就是用户界面可以随着状态的改变而改变,并且不会出现不一致的情况,这就是所谓的binding。
observable.combineLatest(firstName.rx_text,lastName.rx_text) { $0 + " " + $1 }
.map { "Greeting \\($0)" }
.bindTo(greetingLabel.rx_text)
官方建议使用
.adddisposableTo(disposeBag)
即使对于简单地bindings
来说这并不是必要的
Retries
我们很期望APIs 不会失败,但是这并不能如我们所愿,下面我们就来看一个:
func doSomethingIncredible(forWho: String) throws -> IncredibleThing
这个函数如果执行失败很难再次retry,即使是retry了,这也会产生很多的transient states,这并不是我们想要的,Rx 实现起来就很简单
doSomethingIncredible("me")
.retry(3)
Transient State
在写 async
程序的时候会有许多的 瞬态问题,最典型的就是输入框的自动搜索,先输入ab
,发送一次请求,再输入c
,又会发送一次请求,之前的请求可能需要cancel掉,或者使用另外一个变量引用。
另外一个问题就是,如果请求失败,就需要大量的retry 逻辑处理,如果成功,之前的retry 也需要清理。
如果我们在触发请求之前能有一丢丢时间的间隔,那就会非常完美,毕竟有些输入操作需要较长的时间。
还有一个问题就是在搜索请求执行过程中,屏幕上显示啥呢?失败了,又要显示啥?(公司产品要求,你懂得,处理起来极其繁琐),下面就是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
}
throttle
节流,在设定的时间内多次发送请求,仅仅触发最后一次distinctUntilChanged
求异去同,比较前后两个值,如果相同则不会触发,不同则触发startWith
开始设定的值,可以认为是占位符或者placeHolder
整合网络请求
你想一同发送两个请求,当两个请求都成功后,将两者的结果整合起来处理,这... 好伤脑筋啊!!!
没关系,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 user interface
}
zip
将两个信号合并成一个信号,并压缩成一个元组返回,前提是两个信号均成功
还有个问题是,这些请求是在后台,绑定还没有在主线程发生,这就要用到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 user interface
}
轻松整合RX
实现自己的observable,那真是太简单了,(so easy,老板再也不担心我写不出代码了)
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()
}
}
}
}
综合处理 (Compositional disposal)
设想一下几个场景: 在tableView上展示一个模糊的image,这个image首先需要获取,然后解码,然后模糊处理
- 在cell 退出了可显示区域,整个操作可以取消
- 当用户快速滑动cell,cell 进入可现实区域,不会立刻去获取image。cell仅仅是昙花一现,这需要发送很多的request 和 cancel 操作。
- 我们可以限制并发数量
以上场景如果可以优化并满足要求,改多好,是吧 !
让我们看看 Rx
是怎么做的
// this is conceptual solution
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)
代理(Delegates)
代理一般用于回调和作为一种观察机制。
传统的delegate 在设置setter 方法时,不会触发初始值,因此你需要通过其他的途径来读取初始值。RxCocoa
不仅提供了UIKit
的封装,而且还提供了一套通用机制-
ClassDelegateProxy
,使你能够封装你自己的
delegate 并作为可观察的Sequence 暴漏出来。
来看一下整合后的UISearchbar
It uses delegate as a notification mechanism to create an Observable<String> that immediately returns current search text upon subscription, and then emits changed search values.
extension UISearchBar {
public var rx_delegate: DelegateProxy {
return proxyForObject(RxSearchBarDelegateProxy.self, self)
}
public var rx_text: Observable<String> {
return defer { [weak self] in
let text = self?.text ?? ""
return self?.rx_delegate.observe("searchBar:textDidChange:") ?? empty()
.map { a in // a 包含了searchbar:textDidChange:的参数,第一个是Searchbar,第二个是值
return a[1] as? String ?? ""
}
.startWith(text)
}
}
}
RxSearchBarDelegateProxy
可在这里找到 here
下面是该API的使用
searchBar.rx_text
.subscribeNext { searchText in
print("Current search text '\\(searchText)'")
}
通知 (Notificatioins)
通知可以注册过个观察者,但是他们也是未知类型的,值需要从userInfo
中提取。
冗余的形式:
let initialText = object.text
doSomething(initialText)
// ....
func controlTextDidChange(notification: NSNotification) {
doSomething(object.text)
}
你可以使用rx_notification
来创建一个观察序列,减少逻辑和重复代码的散播。
let subscription = notificationCenter.rx_notification("testNotification", object: targetObject)
.subscribeNext { n in
numberOfNotifications += 1
}
KVO
KVO 是一个很方便的观察机制,但是也不是没有缺点,他最大的缺点就是让人模糊的内存管理。
在观察一个对象的一个属性时,该对象必须要比注册的KVO observer 活的时间长,都则会遇到crash
`TickTock` was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object.
另外还有一套规则你还得遵守,否则结果有可能很诡异。还的实现一个笨拙的方法
-(void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
RxCocoa
提供了一套很方便的观察序列--rx_observe
和 rx_observeWeakly
使用方法:
view.rx_observe(CGRect.self, "frame")
.subscribeNext { (frame: CGRect?) in
print("Got new frame \\(frame)")
}
or
someSuspiciousViewController.rx_observeWeakly(Bool.self, "behavingOk")
.subscribeNext { (behavingOk: Bool?) in
print("Cats can purr? \\(behavingOk)")
}