为什么RxSwift可能不是您想要的解决方案。

世界再见！

以RxSwift github页面中的第一个示例为例。

使用以下代码段：

让searchResults = searchBar.rx.text.orEmpty.throttle（0.3，Scheduler：MainScheduler.instance）.distinctUntilChanged（）。flatMapLatest {query-> Observable  inif query.isEmpty {return .just（[]）}返回搜索GitHub（query）.catchErrorJustReturn（[]）}。observeOn（MainScheduler.instance） 

这是我的方法

使用以下代码段：

  rsTf.rxEndEditing〜<action {（s，vc）in 
  //为清晰起见，对字符串进行了一些检查，以确保清晰度api.search.withParam（“ q”，s）.loadIfNeeded（）?. onNewData {e in vc.data = e.json [P.items] .arrayValue}} 

而rsTf是符合UITextFieldDelegate的UITextField子类实例。 只要使用属性观察器认为合适，就会调用动作关闭。

rxEndEditing：Rx 是我创建的自定义事件，用于桥接属性观察器和操作关闭（使用自定义运算符〜<），并且是rsTf中的属性。 请注意，其通用类型是实际的消息类型，而不是某些抽象的“可观察”类型。

data是表视图的数据源，它触发另一个属性观察器重新加载表视图。

游戏结束，游戏结束。

至少在这个相当琐碎的示例中，我看不到RxSwift能击败我的解决方案的任何方式。

我可以使用专用的网络库，而不必担心Rx-fy他们。

我从具有特定消息类型（字符串与Observable 相对的字符串）的事件源开始，这使我能够进行类型安全的功能映射，并最终到达在其中更新VC内部状态的动作接收器。

我不需要关心任何流控制废话。

我使用标准的Swift功能，例如属性观察器，而不是KVO或其他一些黑魔法。

该框架总共少于100行。

开发人员可以创建自己的事件源，使用任何自定义UI类，甚至扩展框架（因为它少于100行）。 最好的是，学习曲线不存在。 我的意思是，看一下上面的代码，创建一些Rx事件源，将其桥接到动作关闭，然后回到在VC中编写命令式代码的常用方式。

从我作为iOS开发人员的日常经验来看，我永远不需要一个事件源来发送连续的事件流，而我必须对其进行监视并从中取出有用的部分。

但是根据我作为iOS开发人员的日常工作经验，我需要一个事件源来准确地向我提供我在要求或期望时想要的东西。 我不希望有任何意外，没有大海捞针。

物业观察员是这一切的关键

令人困惑的是，当我搜索RxSwift存储库时，找不到属性观察器的明确用法。 它要么被埋在某个神秘盒子中，要么根本不使用。 如果是后者，那么在不使用Swift最突出的反应式功能的情况下，如何调用Swift反应式框架？

但是请记住，我不是RxSwift的专家，所以请加一点盐。

底线

我不认为RxSwift是iOS Swift开发的顶峰。 根据到目前为止的了解，RxSwift接近过度工程的顶峰。 （在顶点附近，因为VIPER承担了过度工程的宝座）

您可以轻松找到有关为什么以及如何使用RxSwift的资料。 但是，要找到为什么除了难度之外不应该使用它的反论点要困难得多。

我在这里告诉您，根据我的经验，RxSwift可能不是您想要的解决方案。