RxSwift:ReactiveX for Swift 翻译

最新推荐文章于 2024-05-19 18:35:12 发布

weixin_30546189

最新推荐文章于 2024-05-19 18:35:12 发布

阅读量112

点赞数

文章标签： rxswift swift ui

原文链接：http://www.cnblogs.com/melons/p/5791971.html

版权

RxSwift:ReactiveX for Swift 翻译

字数1787 阅读269 评论3 喜欢3

图片发自简书App

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 Class的封装，而且还提供了一套通用机制-DelegateProxy,使你能够封装你自己的 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)")
    }

someSuspiciousViewController.rx_observeWeakly(Bool.self, "behavingOk")
    .subscribeNext { (behavingOk: Bool?) in
        print("Cats can purr? \\(behavingOk)")
    }

转载于:https://www.cnblogs.com/melons/p/5791971.html

weixin_30546189

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
RxSwift:ReactiveX for Swift 翻译

RxSwift:ReactiveX for Swift 翻译字数1787阅读269评论3喜欢3图片发自简书AppRxSwift||-LICENSE.md|-README.md|-RxSwift --- 平台核心|-RxCocoa --- 对UI,NSURLSession,KVO...的扩展|-RxBlocking...
复制链接

扫一扫