ReactiveCocoa vs RxSwift-优缺点？

因此，现在借助Swift，ReactiveCocoa人们已经在3.0版中对其进行了重写，以实现迅速

另外，还有另一个名为RxSwift的项目。

我想知道人们是否可以添加有关这两个框架在设计/ api /哲学上的差异的信息（请以SO的精神，坚持做对的事情，而不是对“最好的”观点）

[关于StackOverflow mod的说明：这个问题确实有明确的答案，答案是两个框架之间的差异。我认为，SO也很受关注]

首先，通过阅读自述文件给我的第一印象是：

• 作为熟悉Microsoft的“真实” C＃Rx的人，RxSwift看起来更加知名。
• ReactiveCococa似乎已经进入了自己的空间，引入了诸如Signals vs SignalProducers和Lifting之类的新抽象。一方面，这似乎可以澄清某些情况（什么是热信号还是冷信号），但另一方面，这似乎增加了很多框架的复杂性。

这个问题问得好。比较两个世界非常困难。Rx是Reactive Extensions在其他语言（例如C＃，Java或JS）中的移植。

Reactive Cocoa受到功能性反应式编程的启发，但在最近几个月中，它也受到Reactive Extensions的启发。结果是一个与Rx共享某些内容的框架，但其名称起源于FRP。

首先要说的是，根据Conal对概念的定义，RAC和RxSwift都不是功能性反应式编程实现。从这一点上讲，所有内容都可以简化为每个框架处理副作用和其他一些组件的方式。

让我们谈谈社区和元技术的东西：

• RAC是一个有3年历史的项目，出生于Objective-C，之后完全放弃了对Objective-C的工作，后来移植到了Swift（带桥）以进行3.0版本发布。
• RxSwift是一个数月的项目，目前似乎在社区中具有发展势头。对于RxSwift来说重要的一点是，它属于ReactiveX组织，并且所有其他实现都以相同的方式工作，学习如何处理RxSwift将使Rx.Net，RxJava或RxJS的工作变得简单，而仅此而已。语言语法。我可以说这是基于一次学到的哲学，无处不在。

现在是时候购买高科技产品了。

生产/观察实体

RAC 3.0具有2个主要实体，Signal并且SignalProducer，第一个发布事件，无论是否有订户都已订阅，第二个发布实体start实际上需要产生信号/事件。创建此设计的目的是将繁琐的热和冷可观察物概念分离开来，这已使许多开发人员感到困惑。这就是为什么可以减少差异以解决副作用的原因。

在RxSwift中Signal并将其SignalProducer转换为Observable，听起来可能会造成混淆，但是这两个实体实际上在Rx世界中是同一回事。必须Observable在RxSwift中创建带有s 的设计，考虑它们是热还是冷，这听起来可能是不必要的复杂性，但是一旦您了解了它们的工作原理（再次，热/冷/热只是关于订阅/观察时的副作用） ）他们可以被驯服。

在两个世界，订阅的概念基本相同，有一个点点区别在于RAC推出，是interruption当事件Signal已发送完成事件之前设置。概括地说，两者都有以下类型的事件：

• Next，以计算新的接收值
• Error，以计算错误并完成流，从而取消所有观察者的订阅
• Complete，以将流标记为已完成，所有订阅者都不再订阅

另外interrupted，RAC会在Signal正确完成或出现错误之前处置a时发送。

手动书写

在RAC中，Signal/ SignalProducer是只读实体，无法从外部进行管理Observable，RxSwift中也是如此。要将Signal/ SignalProducer变成可写实体，您必须使用该pipe()函数返回手动控制的项目。在Rx空间上，这是另一种类型，称为Subject。

如果读/写概念听起来很陌生，则可以用Future/ Promise进行类比。A Future是只读占位符，例如Signal/ SignalProducer和Observable，另一方面，a Promise可以手动实现，例如for pipe()和Subject。

调度程序

这个实体在两个世界中都非常相似，具有相同的概念，但是RAC仅是串行的，而RxSwift还具有并发调度程序的功能。

组成

组合是响应式编程的关键功能。组成流是这两个框架的本质，在RxSwift中，它们也称为sequence。

所有RxSwift可观察的实体类型的ObservableType，所以我们撰写的实例Subject，并Observable用相同的运营商，没有任何多余的顾虑。

在RAC空间，Signal和SignalProducer2个不同的实体，我们必须lift对SignalProducer能够构成生产什么用的实例Signal。这两个实体都有自己的运算符，因此当您需要混合使用某些事物时，必须确保某个运算符可用，另一方面，您会忘记热/冷观测值。

关于这部分，Colin Eberhardt很好地总结了一下：

从当前的API来看，信号操作主要集中在“ next”事件上，使您可以在不同线程上转换值，跳过，延迟，组合和观察。信号产生器API主要关注信号生命周期事件（完成，错误），其操作包括then，flatMap，takeUntil和catch。

额外

RAC还具有Action和的概念Property，前者是一种计算副作用的类型，主要与用户交互有关，后者在观察值以更改值时执行任务时很有趣。在RxSwift中，将Action转换再次转换为Observable，这在RxCocoaiOS和Mac的Rx原语的集成中很好地显示了。RAC Property可以在RxSwift中转换为Variable（或BehaviourSubject）。

重要的是要了解Property/ Variable是我们将命令式世界与反应式编程的声明性联系起来的方式，因此在处理第三方库或iOS / Mac空间的核心功能时，有时是基本组件。

结论

RAC和RxSwift是2种完全不同的野兽，前者在Cocoa领域拥有悠久的历史，并且有很多贡献者，后者相当年轻，但是依赖于已被证明在其他语言（例如Java，JS或Java）中有效的概念。 。净。优先选择哪个更好。RAC指出，必须将可观察到的冷/热分离，这是框架的核心功能，RxSwift说，将它们统一起来比分离更好，这还是关于如何管理/执行副作用。

RAC 3.0似乎在分离热/冷可观察对象的主要目标之上引入了一些意想不到的复杂性，例如中断的概念，在两个实体之间拆分运算符并引入了一些强制性行为，例如start开始产生信号。对于某些人来说，这些东西可能是一件好事，甚至是杀手级功能，对于另一些人，它们可能只是不必要的甚至是危险的。要记住的另一件事是，RAC试图尽可能地遵循Cocoa约定，因此，如果您是一位经验丰富的Cocoa Dev，那么与RxSwift相比，使用它应该更舒服。

另一方面，RxSwift伴随着Reactive Extensions的所有弊端，如热/冷的可观察物，还有好东西。从RxJS，RxJava或Rx.Net迁移到RxSwift是一件简单的事情，所有的概念都是相同的，因此这使得查找素材非常有趣，也许您现在面临的是同样的问题，已经由RxJava中的某人解决了，并且解决方案考虑到平台可以重新应用。

必须选择哪一个绝对是一个优先事项，从客观的角度看不可能说出哪个更好。唯一的方法是启动Xcode并尝试两者，然后选择一个使用起来更舒适的方法。它们是类似概念的2种实现，旨在实现相同的目标：简化软件开发。