什么是Observer ?

从上面的图可以看到ObserverType核心的就是一个接收事件的函数

1

func on(_ event: Event<E>)

他是对事件处理者的抽象。通过on方法拿到事件，至于具体要怎么处理这个事件，就由实现这个协议的东西决定了。

AnoymousObserver

我们使用过程中经常用subscribe(一个block )这样的函数。起始其中的block会被封装为一个AnoymousObserver对象。这个对象既是一个observer也是一个disposable。为什么要加上disposable呢？observer的on也不需要返回disposable呀？其实是考虑到当sequence dispose之后，防止on方法仍然继续执行。所以他保存了一个isStopped变量。当dispose之后将其设置为true。并在on方法中加入判断，如果isstoped为true，将不执行on。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func dispose() {
    _ = AtomicCompareAndSwap(0, 1, &_isStopped)
}
func on(_ event: Event<E>) {
    switch event {
    case .next:
        if _isStopped == 0 {
            onCore(event)
        }
    case .error, .completed:
        if AtomicCompareAndSwap(0, 1, &_isStopped) {
            onCore(event)
        }
    }
}

什么是scheduler?

在开始使用scheduler之前，首先要明白他是什么。

总的来说，scheduler是一个任务执行的上下文。这个上下文可能是一个thread、dispatchqueue、OperationQueue等。

一个常见的误解是：scheduler等价于线程。但实际并不是这样 。如果你自定义一个scheduler（虽然并不推荐自定义）,你可以创建多个scheduler共用一个线程,或者一个scheduler构建在多个线程上(虽然比较奇怪,但确实可以)。

总之，scheduler并不是线程，他和线程并没有一对一的关系。

关于scheduler的两个操作符

Rx最重要的能力之一就是能够在任何时间切换scheduler。

subscribeOn

有时你希望改变 observable 生成element的代码的执行上下文环境( 比如：对于Observable.create{ … }，就是闭包中的那段代码 )。这个时候就可以使用subscribeOn操作符。

observeOn

如果你希望改变subscribe函数执行的上下文，那么你可以使用observeOn操作符。

Hot and Cold Observable

一个Observable什么时候开始发送他的elements呢？这取决于Observable。一个“Hot Observable”会在他创建完成后就开始emit elements，这样之后subscribe他的observer就能够在中间开始接收elements。一个“Cold Observable”会等到有Observer subscribe他时才开始emit elements，这样就保证了observer能够收到从头开始的所有elements。

陷阱

对于cold observable我们确实可以通过subscibeOn操作符来控制element在哪个线程上产生，因为他是在subscribe时才去生成elements的。但是对于一些Hot Observable，如果你想通过subscibeOn去切换scheduler，你会发现并不起作用，因为elements的生成在Observable创建时就会生成，之后我们就不能控制他的scheduler。

内置的scheduler

CurrentThreadScheduler

抽象了在当前线程上执行的任务。如果你没有执行scheduler，那么这个就是默认的scheduler。

SerialDispatchQueueScheduler

抽象了某个需要在 serial DispatchQueue上执行某个任务。他能够保证即使你传入的是一个Concurrent queue，他也会把他转化成serial。

非常重要的一点是这个scheduler是serial的，因为某些操作符会根据这个进行优化。

因为不能够检测到传入的是concurrent的还是serial的，所以在内部都会创建一个serail queue，然后所有的任务都是在这个内部的serail queue上执行。

MainScheduler

抽象了在主线程上执行任务，这个scheduler通常用于执行某些UI操作。继承自SerialDispatchQueueScheduler。这个scheduler对ObserveOn操作符有优化，所以如果你想要subscribe函数在主线程上执行，那么用MainScheduler。另外还有一个ConcurrentMainScheduler，这个scheduler对subscibeOn操作符有优化，所以，你如果希望element的产生在主线程上，那么用ConcurrentMainScheduler。

ConcurrentDispatchQueueScheduler

抽象了在某个concurrent dispatchqueue上执行的任务。这个scheduler通常用于某些需要在后台执行的任务。

OperationQueueScheduler

抽象了在某个OperationQueue上执行的任务。这个sechulder适合当你想要控制并发数量时用。

​

Disposable

他是对资源清理这一步的抽象。抽象也很简单，就是一个dispose方法。

1
2
3
4
5
6
7
8

protocol Disposable {
    func dispose() ///销毁
}
protocol Cancelable : Disposable {
    var isDisposed: Bool { get } //是否被销毁了。
}

但是具体要怎么清理呢？先看看大部分disposable的基类：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class DisposeBase {
    init() {
#if TRACE_RESOURCES
    let _ = Resources.incrementTotal()
#endif
    }
    
    deinit {
#if TRACE_RESOURCES
    let _ = Resources.decrementTotal()
#endif
    }
}

可以看到基类什么也没干，ok，我们又看看具体的子类。都是继承自DisposeBase，并实现了Cancelable接口

AnonymousDisposable

代表着一个 会在销毁时执行某个action的disposable。

BinaryDisposable

将两个disposable包裹为一个，在BinaryDisposable销毁时，同时释放两个包含的disposable。

BooleanDisposable

代表一个可以检查dispose状态的disposable.

CompositeDisposavle

包裹了 一组disposables，在CompositeDisposable销毁时同时销毁所有的disposable。

RefCountDisposable

与某个disposable绑定，只有当绑定的disposable销毁时，才销毁自己。

ScheduledDisposable

让销毁操作在某个线程上执行。

SerialDisposable

底层的disposable是可替换的，当替换时，会自动dispose前一个disposable。

SingleAssignmentDisposable

只能对底层的disposabel赋值一次，再次赋值将抛出异常。

其他

disposeBag

相当于一个disposables的容器，当bag释放时，会自动dispose其包含的disposable。

NopDisposable

代表销毁时什么也不执行的disposable。

Disposables

相当于一个公共方法结构体。包含一些常用的创建disposable方法。

总结

ok，上面的类基本是disposable所有的类了。我们看到，他的类主要抽象了销毁时我们应该执行什么操作以及处理需要销毁多个disposable的类。

当然首先第一个资源是raywenderlich的Reactive programming with swift。

什么是rxswift?

1
2

RxSwift is a library for composing asynchronous and event-based code by using observable sequences and functional style operators, allowing for parameterized execution via schedulers.
rxswift是一个用observable序列和函数式操作符让你编写异步的基于事件的代码的一个库，。。。

不大懂，没关系，一步一步来,竟然提到了异步，那么先来看看异步编程的术语，rxswift和异步，响应式，函数式编程等紧紧相关，所以如果你知道一些术语，能够帮助你更好的理解rxswift。

异步编程术语

1. 状态(state) ,特别是共享的可变状态(shared mutable state)

状态比较难定义，我们看下面的例子：

当你打开你的笔记本电脑，他正常运行。但是你用了几天或者几周后，他可能就变得有些异常，突然卡顿或者拒绝响应等。硬件和软件都是一样的，但是状态变了。只要你重启，同样的软件和硬件又能正常工作。

内存中的数据，磁盘上的数据，用户输入的响应以及所有从服务器拉取数据后残留的痕迹等，—-他们的总和就是你笔记本的状态。

2. 命令式编程(Imperative programming)

Imperative programming是一种 用陈述式语句来改变程序状态的一种范式。就像你和你的狗狗玩耍时说的：“过来” “躺下” “装死”。你也通过命令式的代码告诉你的app什么时候做什么事。不过这种命令式的代码会给我们带来许多问题，特别是在处理复杂的，异步的逻辑时。比如：

1
2
3
4
5
6
7

override func viewDidAppear(_ animated: Bool) {
  super.viewDidAppear(animated)
  setupUI()
  connectUIControls()
  createDataSource()
  listenForChanges()
}

这里并不知道这些方法到底干了什么，会改变viewcontroller的某个属性么？更让人不安的是，他们调用的顺序对么？如果某个人交换了他们的顺序并提交到git上。那么app可能因为函数的交换就不能正常运行了。

3.副作用（side effects）

副作用是当前作用域外的状态的改变。比如上面例子中的connectUIControls。他可能会为UI绑定时间，这就产生了副作用，因为view的状态改变了：函数调用前的行为和调用后的行为不一样了。任何时候你存储数据到磁盘或者更新label的text都引起了副作用。

副作用并不是指坏的影响。总之，我们的最终目的就是产生副作用。你的程序运行后需要改变状态。

副作用的问题在于是否已一种可控的方式执行(doing it in a controlled way)。你必须能够确定哪部分代码产生副作用，哪些是仅仅处理和输出数据。

Rxswift会解决上面的问题，我们看看下面的rxswift的一些概念。

4.描述式的代码（declarative code）

描述式的代码定义了一坨行为(behavior)，rxswift会在相关的事件到达时运行这些behavior，并且提供给behavior的输入是可以确定不变的。

这种方式也适用于异步代码。你不用再怀疑你的代码是否是按顺序，确定的执行的了。

5.响应式系统(reactive system)

他具有以下特性：

• Responsive: 总是保持UI是最新的。
• resilient：每种行为(behavior)都是隔离的，而且有一定的错误恢复机制
• Elastic：代码能够处理各种负载，这些特性包括：event throttling ，resource sharing等。
• Message driven：各个组件都通过事件来交流，从而实现重用和隔离，将类的生命周期和实现解耦。

rxswift的代码由三部分组成：Observables,operators，schedulers。

Observales

一个Observale能够发射三种类型的值：

• .next : 带有最新值得事件
• .completed：表示生命周期正常结束，不会再产生其他事件
• .error: 产生了错误退出，不会再产生任何事件

Operator

Rxswift提供了许多操作符：map,flatmap,zip,timer等，能让我们用描述的方式编写代码，以后再看

schedulers

scheduler等价于rx的dispatch queue实现。能帮助我们处理各种异步事件。

这一章主要就是介绍了rxswift想要解决的问题，对rxswift有个大概的了解，明天继续看Observables。

​
​
​

无语，换电脑时，之前的blog被我删了，好多文章都没了。。。