RxSwift文档十（其他）

Subjects

所有行为都与此处描述的完全相同

Relays

RxRelay提供两种Relays：PublishRelay和BehaviorRelay。它们的行为与并行Subjects相似，有两处变化：

• Relays永远不会完成。
• Relays永远不会发出错误。

本质上，Relays只发出.next事件，永不终止。

冷热Observables

建议更多地将其视为序列的属性而不是序列的类型，因为它们完全由适合它们的相同抽象表示，Observable序列。

这是ReactiveX.io的定义

Observable何时开始序列元素？这取决于Observable。“热”Observable可以在创建后立即开始发出元素，因此任何后来订阅该Observable的观察者都可以开始在中间某处观察序列。另一方面，“冷”Observable直到在观察者订阅它之前开始发射元素，因此这样的观察者保证从一开始就看到整个序列。

热Observables	冷Observables
…是序列	…是序列
无论是否有任何观察者订阅，都要使用资源（“产生热量”）。	在观察者订阅之前，不使用资源（不产生热量）。
变量/属性/常量，点击坐标系，鼠标坐标系，UI控件值，当前时间	异步操作，HTTP连接，TCP连接，流
通常包含~N个元素	通常包含~1个元素
无论是否有任何观察者订阅，都会产生序列元素。	仅当存在订阅的观察者时才生成序列元素。
序列计算资源通常在所有订阅的观察者之间共享。	通常为每个订阅的观察者分配序列计算资源。
通常是有状态的	通常无状态的

Rx背后的数学

Observer和Iterator / Enumerator / Generator / Sequences之间的双重性

观察者模式和生成器模式之间存在双重性。这使能够从异步回调的世界转变到序列转换的同步世界。

简而言之，枚举器和观察者模式都描述了序列。枚举器定义序列的原因相当简明，但观察者稍微复杂一些。

然而，有一个非常简单的例子，不需要很多数学知识。假设在给定时间观察鼠标光标在屏幕上的位置。随着时间的推移，这些鼠标位置形成序列。实质上，这是一个可观察的序列。

可以通过两种基本方式访问序列的元素：

• Push interface - 观察者（观察到的元素随着时间推移产生一个序列）
• Pull interface - 迭代器/枚举器/生成器

还可以在此视频中看到更正式的说明：

• Expert to Expert: Brian Beckman and Erik Meijer - Inside the .NET Reactive Framework (Rx) (video)

与其他框架比较

与ReactiveSwift比较

RxSwift有点类似于ReactiveSwift，因为ReactiveSwift从Rx借用了大量概念。

该项目的主要目标之一是创建一个更加简单的界面，使其与其他Rx实现更加一致，提供更丰富的并发模型，提供更多的优化机制，并与内置的Swift错误处理机制更加一致。

还决定仅依赖Swift / llvm编译器，而不引入任何外部依赖项。

这些项目之间的主要区别可能在于其构建抽象的方法。

RxSwift项目的主要目标是提供以可观察序列形式抽象的与环境无关的组合计算粘合剂。

然后，我们旨在改善在特定平台上使用RxSwift的体验。为此，RxCocoa使用通用计算来构建更多实用的抽象并包装Foundation / Cocoa / UKit框架。这意味着，其他库使用上下文和通用计算引擎语义RxSwift提供了诸如Driver，Signal，ControlProperty，ControlEventS等等。

将所有这些抽象表示为一个单独的概念（observable sequences）的好处之一是，基于它们建立的所有计算的抽象也可以以相同的方式进行组合。它们都遵循相同的约定并实现相同的接口。这也很容易建立灵活的subscription（资源）共享策略或使用一个内置的：share，publish，multicast…

该库还提供了fine-tunable并发模型。如果使用并发调度程序，则可观察序列运算符将保留序列属性。相同的可观察序列运算符还知道如何发现和最佳地使用已知的串行调度程序。ReactiveSwift的并发模型更为有限，仅允许使用串行调度程序。

多线程编程确实非常困难，而检测不必要的等待循环则更加困难。这就是为什么所有操作符都以容错方式构建的原因。即使在元素处理（递归）过程中发生元素生成，操作符也将尝试处理这种情况并防止死锁。这意味着在最坏的情况下，编程错误将导致堆栈溢出，但用户不必手动终止该应用程序，并且将在错误报告系统中获得崩溃报告，以便查找并解决问题。