优点和缺点？
因此，现在迅速，ReactiveCocoa人已经在3.0版中将其改写为swift
另外还有一个项目叫做RxSwift。
我想知道人们是否可以增加关于这两个框架的设计/ api /哲学差异的信息（请按照SO的精神，坚持真实的事情，而不是关于哪个是最好的意见）
[注意StackOverflow mods：这个问题有确定的答案，答案是两个框架之间的差异。 我认为这也是高度关注的话题]
要开始，阅读他们的自述文件的最初印象是：
这个问题问得好。 比较这两个世界是非常困难的。 Rx是Reactive Extensions在C＃，Java或JS等其他语言中的一个端口。
Reactive Cocoa灵感来自功能反应式编程，但在过去的几个月里，Reactive Cabling也受到了Reactive Extensions的启发。 结果是一个框架，与Rx共享一些东西，但在FRP中有起源的名称。
首先要说的是，根据Conal对这个概念的定义，RAC和RxSwift都不是功能反应编程的实现。 从这一点来说，一切都可以归结为每个框架如何处理副作用和其他一些组件。
我们来谈谈社区和元技术：
现在是科技的时候了。
生成/观察实体
RAC 3.0有两个主要实体， Signal和SignalProducer ，第一个发布事件，无论用户是否连接，第二个实体需要start实际产生信号/事件。 这种设计是为了分离热和冷的可观测量的繁琐概念而设计的，这已成为许多开发人员的混淆之源。 这就是为什么差异可以减少到他们如何管理副作用 。
在RxSwift中， Signal和SignalProducer转化为Observable ，它可能听起来令人困惑，但这两个实体在Rx世界中实际上是相同的。 RxSwift中的Observable s的设计必须考虑它们是否热或冷，这可能听起来不必要的复杂性，但是一旦你明白它们是如何工作的（再次热/冷/暖只是在订阅/观察）他们可以被驯服。
在这两个世界中，订阅的概念基本上是相同的，RAC引入了一个小差异，并且是在发送完成事件之前处理Signal时的interruption事件。 回顾两者有以下几种事件：
Next ，计算新收到的值 Error ，要计算错误并完成流，请取消订阅所有观察者 Complete ，将流标记为完成取消订阅所有观察者 此外，在正确完成或发生错误之前，处理Signal时，RAC还会interrupted发送。
手工写作
在RAC中， Signal / SignalProducer是只读实体，它们不能从外部管理，同样的事情也适用于RxSwift中的Observable 。 要将Signal / SignalProducer转换为可写入的实体，必须使用pipe()函数返回手动控制的项目。 在Rx空间中，这是一种名为Subject的不同类型。
如果读/写概念听起来不熟悉，可以与Future / Promise做一个很好的类比。 Future是一个只读占位符，如Signal / SignalProducer和Observable ，另一方面，可以手动完成Promise ，如pipe()和Subject 。
调度程序
这个实体在两个世界中都是非常相似的，相同的概念，但是RAC是仅串行的，相反，RxSwift还具有并发调度器功能。
组成
组合是反应式编程的关键特征。 构成流是两个框架的精髓，在RxSwift中它们也被称为序列。
RxSwift中的所有可观察实体都是ObservableType类型，因此我们使用相同的运算符组合Subject和Observable实例，而没有任何额外的关注。
在RAC空间中， Signal和SignalProducer是两个不同的实体，我们必须lift SignalProducer以便能够组合使用Signal实例生成的内容。 这两个实体都有自己的操作员，所以当你需要混合的东西时，你必须确保某个操作员可用，而另一方却忘记了热/冷的可观察物。
关于这部分，Colin Eberhardt很好地总结了这一点：
看看当前的API，信号操作主要集中在'下一个'事件上，允许您在不同线程上转换值，跳过，延迟，合并和观察。 信号生成器API主要关注信号生命周期事件（完成，错误），操作包括然后，flatMap，takeUntil和catch。
额外
RAC还有Action和Property的概念，前者是一种计算副作用的类型，主要与用户交互有关，后者在观察值发生变化时执行任务时很有趣。 在RxSwift中， Action再次转换为Observable ，这在RxCocoa很好地展示，这是iOS和Mac的Rx基元的集成。 RAC的Property可以在RxSwift中转换为Variable （或BehaviourSubject ）。
理解Property / Variable是我们必须将命令式世界与Reactive Programming的声明性本质联系起来的方式很重要，所以在处理第三方库或iOS / Mac空间的核心功能时，它有时是一个基本组成部分。
结论
RAC和RxSwift是两种完全不同的野兽，前者在Cocoa领域有很长的历史，还有很多贡献者，后者相当年轻，但依赖于已被证明在Java，JS或其他语言中有效的概念。净。 优先选择哪一个更好。 RAC指出，热/冷可观察性的分离是必要的，这是该框架的核心特征，RxSwift表示，它们的统一比分离更好，同样也是关于如何管理/执行副作用。
RAC 3.0似乎在分离热/冷可观测量的主要目标（如中断概念，在两个实体之间分离运算符并引入一些必要行为，如start开始产生信号）的主要目标之上引入了一些意想不到的复杂性。 对于某些人来说，这些东西可能是一件好事，甚至有杀手功能，但对于其他人来说，他们可能只是不必要的，甚至是危险的。 还有一点需要记住的是，RAC尽量跟上Cocoa的惯例，所以如果你是一个经验丰富的Cocoa Dev，你应该感觉更适合使用它而不是RxSwift。
另一方面，RxSwift存在诸如热/冷可观察性等所有缺点，但也包含Reactive Extensions的好处。 从RxJS，RxJava或Rx.Net转到RxSwift是一件简单的事情，所有的概念都是一样的，所以这使得找到材料非常有趣，也许你现在面对的同样的问题，已经被RxJava中的某个人解决了，解决方案考虑到平台可以重新应用。
选择哪一个肯定是一个偏好问题，从客观的角度来看，不可能说出哪一个更好。 唯一的方法是启动Xcode并尝试使用它们，然后选择感觉更舒适的工作。 它们是类似概念的2个实现，试图实现相同的目标：简化软件开发。
链接地址: http://www.djcxy.com/p/47705.html上一篇: pros and cons?