WWDC2019 推出了 Combine 结构。这是 RxSwift 的显着竞争对手，RxSwift 完成了反响式流标准。让咱们谈谈咱们的日子是否发生了变化。
是的，它是 beta 版。规划、功用、API 或许会变得更糟或更好。但许多事情现已很显着了。
我的文章将包括许多可点击的链接（这不是广告），由于现实上全部都现已说过了。剩余的仅仅将事物按照杰出的顺序组合在一起。今日咱们将预览：
[TOC]
Backpressure（背压？）
怎么处理 Observables 产生元素的速度比调查者消耗它们的速度快的问题？
从历史上看，RxSwift 不支撑 backpressure。 Flowable 和 Observable 之间没有像 RxJava 中那样进行分离。这是一个已处理的问题，在可预见的将来不会修正。您能够在此处阅览有关原因的更多信息：
为了处理这个问题，RxSwift 有一组有用的运算符和对重入异常的根本运转时查看，这肯定足以供给舒适的无过错开发。
Combine 支撑开箱即用的背压。receive 办法应返回订阅者想要接受的元素数。假如你不在乎，只需返回 Demand.unlimited 即可。
我想这很帅。但我现已编写了许多 RxSwift 代码，并且没有遇到任何需求背压支撑的情况。我总是能够运用可用的运算符集来处理它。
类型过错
这是一个十分抢手的问题，每次评论反响式流时都会出现。应该输入过错还是仅仅一个 Error？ RxSwift 认为 Error 就足够了。你能够在这里阅览人们关于这些内容的最新评论。
Combine 开箱即用。你有必要供给 Publisher 过错类型。也很少有操作符能够处理过错。您能够映射它、替换它、照旧处理下一个事情。
老实说，我不知道为什么咱们需求一个清晰的过错类型。在大多数情况下，咱们将过错视为抽象的东西。咱们有一些通用的弹出窗口，其中放置了咱们最喜爱的 “Something went wrong…”。否则，咱们不想处理过错，而是更喜爱显示一般的空屏幕或过错状态。我十分喜爱将过错处理作为独自的流，并且很少运用特定类型。在咱们的项目中，没有符合 Swift.Error 的自定义类型。
异常处理
我不知道为什么，可是 Combine 拆分了 throwing/not throwing 运算符。例如，假如你的 map 闭包或许会抛出异常，你应该通过 tryMap 使用它。
这样好吗？我想说，作为一名开发人员，我不在乎。我更喜爱默认抛出闭包的 RxSwift 办法。你不会以某种特定办法运用 try(map|filter|scan) 。你仅仅不需求那个逻辑。由于，老实说，开发人员不喜爱过错，也不知道怎么处理过错。
DisposeBag
DisposeBag 是 RxSwift 内存管理形式。您无需独自保存每个订阅并停止它，只需编写 .dispose(by: disposeBag) 并获取一个担任所有订阅处置的变量即可。当 disposeBag 引用计数变为零时，正常行为是在 deinit 中进行处理。默认情况下您期望这种行为。
可是，这一点以及废物收集器的缺失也引入了引用循环的大局问题，没有经验的用户很简略遇到这个问题。当然，有许多办法能够操控它；您甚至能够编写有关正确处理引用循环的测验。我将在下一篇文章中展现更详细的避免内存走漏的办法，订阅不要错失。
Combine 中没有与 DisposeBag 相似的东西。有一个 Cancellable（把我带回 Disposable），你能够撤销并释放所有资源。可是，在 ARC 中运用 Cancellable 或许会十分令人困惑。这是一篇很棒的文章，它通过示例展现了 Combine 的问题。
我是 DisposeBag 的忠诚粉丝。十分便利，并且十分简略。例如，有一种众所周知的铲除单元格中订阅的形式：
final class Cell: UITableViewCell {
private var disposeBag = DisposeBag()
func prepareForReuse() {
super.prepareForReuse()
disposeBag = DisposeBag()
}
...
}
我在当前项目中最大的单元中有七个订阅。或许我真的不想为七个 Cancellable 中的每一个编写这个整理代码。在我看来，增加一个相似类型的 CancelBag 是合乎逻辑的，但苹果工程师比我更了解他们的东西。因而，只能等候，祈祷。在极端情况下，您能够轻松供给自定义完成。
API
RxSwift vs Combine 不等于 Kotlin coroutines vs RxJava 问题。能够用来处理相似问题的东西和相似的东西并不相同。 API 是彻底相等的。是的，文字或许略有不同，但它们是相同的结构，仅仅以不同的办法编写。假如您对更多细节感兴趣，这里有来自 RxSwift 首要维护者之一、超卓的 Shai Mishali 的 RxSwift 和 Combine API 的比较。
是的，没有 flatMapLatest 或常见的特征，如 Maybe、Completable 或 Driver。但这仅仅实施细节。关于苹果来说，它们…… 没有必要。在测验 SwiftUI + Combine 时，我没有遇到任何因它们缺席而出现的问题。
RxSwift 不会仅仅仿制所有的 Combine API。但我会默默地窃取有含义且适用的运算符。例如，这里有一个很帅的 assign 运算符，它现已增加到 RxSwift 中。不要犹豫，RxSwift 运用起来会像 Combine 一样舒适。假如您有兴趣在 RxSwift 中运用您最喜爱的组合运算符，请参与本期。只要投票，我就会为你完成全部。
功用
我想说，RxSwift 和 Combine 一样快。但我不能对你撒谎。这是一个小测验用例，仅使用无含义的运算符。咱们一般便是这样编程的，对吗？
结果令人失望。是的，咱们很少过滤数百万个元素流，但尽管如此：
遗憾的是我没有额外的 6000 美元购买新的 Mac Pro，所以只要 1000 万个元素。该比率呈线性增加。我不会附上不同数量元素的图表，但您能够仿制粘贴此测验并自行运转。
RxSwift 在底层发动许多接收器现已不是什么秘密了。它便是这样规划的，我置疑有人会简单找到更好的处理方案。可是，Combine 的规划很长一段时间以来都着重功用。这不仅仅是言语。
嗯…… 很好。显然，来自苹果的开发者没有任何障碍，所有的资源都掌握在手中，能够比社区做得更好。老实说，我不认为它会更好。功用的大幅提升总是好的，可是…… 试着记住您最终一次运用 XCTestCase.measure 是什么时分？我激烈置疑你的 tableView 翻滚不够快仅仅由于 RxSwift。
Sugar（语法糖？）
你能够赞同也能够不赞同，但 RxSwift 和 Combine 实际上是相同的结构。Combine 彻底在现代 Swift 中完成，因而您能够运用它的协议并供给 Publishers 的自定义完成。但您不会编写自己的 Map，是吗？因而，我对这一变化不发表任何评论。开放性、扩展性杰出。但这种开放性却让开发者拄着拐杖写错了，不尊重契约。该结构应该供给开箱即用的所需全部，并且不允许用户更改规则或从头创造轮子。
行业价值
总会有置疑者。置疑论者企图让咱们信任电脑不适合简略用户，而 iPhone 则不或许。置疑论者表明，Swift 仅仅一个玩具，仅仅为了吸引新的开发者，苹果将继续用 ObjC 编写。总是有人持置疑态度，他们说反响式编程是黑魔法，没有什么比古老的托付形式更好的了。
现在社区很振奋，每个人都喜爱 SwiftUI。但只要少数人考虑了反响式，现实上，反响式是完成使用程序的新办法的核心特征。这取决于你，但我想说这…… 十分重要。
这是 RxSwift 的失利吗？不，这是苹果的成功。许多人现已注意到，这是长期以来开发者最耀眼的 WWDC。 SwiftUI 肯定很帅。在最新款 iPhone 销量不理想后，苹果需求从头夺回商场位置。他们剖析社区请求并尽全部努力哄骗开发人员。他们企图让世界上的每个开发人员都想为苹果编写使用程序。老实说，他们做到了。
便是这样。反响式编程。应该说，RxSwift 在 iOS 开发中并不是很盛行。尽管 Android 使用程序没有 RxJava 就无法完成，但咱们（iOS 用户）依然置疑是否应该测验这个库。 “这是第三方” 和 “代码太杂乱，太奇特了” 成为反对 RxSwift 的盛行论点。现在苹果公司宣布了一个反响式结构，意思是 “是的，店员们。这便是 iOS 开发的未来。现在正式了。处理它” 显然，现在更多的开发人员会将托付更改为 Rx。假如他们不是…… 他们应该是。
iOS 13.0+
较低的 iOS 版别不支撑 Combine。你能用它做什么？
- 假如你现在正在运用 RxSwift，那么一两年就不必担心了。我看不出将代码库迁移到 Combine 有任何含义。或许有一天你会觉得运用自定义 RxSwiftCommunity 库没有任何含义，由于所有这些库都能够在官方结构中开箱即用。然后…… 你能够测验删去 RxSwift。
- 假如您现在想测验在项目中做出反响，那么最好等候。从 RxSwift 迁移到 Combine 将相当杂乱。是的，您或许认为 API 十分相似，但信任我，您会遇到问题。因而，只需在宠物项目中查看它，无需将其增加到您的生产中。
- 假如你现在没有做出反响…… 好吧，正如我现已说过的…… 你肯定应该做出反响。
RxSwift 是现在呼应式编程的一个很好的替代方案。您不需求支撑 iOS 13.0+ 即可进行呼应式编程。我想你或许会看到苹果的新东西。我很惊奇人们会喜爱：“哇，一种设置表格视图的办法，太便利了，太现代了。” 苹果并没有像往常一样创造任何新东西，他们仅仅让旧的变得更好。关于较低的 iOS 版别，您现在能够用一行装备您的表（我现已运用它两年了）：
值得注意的是，反响式编程结构环绕其自身形成了大量便利的扩展。对我来说，反响性现已成为简洁的代名词。您能够在我的上一篇文章中了解 RxSwift 的便利性。
RxSwift 社区真的很棒。由于反响性不仅仅是处理异步事情的一种办法，并且是一种考虑、规划使用程序的办法。声明性、单向性、无状态组件…… 您现在就能够运用所有这些功用。相似的东西你有必要与 SwiftUI 一起运用。您现已了解 Flutter 中的所有 BLoC 内容。
何去何从
我真的很想说 RxSwift 将永久存在，有一天我会向我的儿子解说它。可是这是过错的。 RxSwift 几年后就会消亡。这不仅仅是炒作的话，而是现实。你能够在这里阅览更多。最特别有趣的是 Krunoslav Zaher 的评论，他让 iOS 开发者的日子变得更加幸福。
你能够随心所欲地解说它，但对我来说，这是一次哀痛的离别。这是一项很棒的作业，我希望我能早点出生，站在这个存储库的来源上。我为此付出的努力太少了，现在正努力追赶。咱们努力为对 Combine 感兴趣的用户供给更愉快的 RxSwift 体会。新的相似 Combine 的操作符行将推出。
但这全部都仅仅对愿望的追求。 RxSwiftCommunity 能够向 UIKit 增加任何扩展。但不幸的是，咱们永久无法直接为 Apple 结构做出贡献。Combine 看起来是一个经用的功用。 Apple 在 RealityKit 中支撑它，SwiftUI 在底层运用它。这是合乎逻辑的。 RxSwift 永久只能成为一个让开发变得更简略的第三方。
正确的问题不是 “我应该运用 Combine 吗？”，而是 “我到底应该什么时分开始这样做？”。这取决于您的要求。例如，在当前项目中，我的团队仅支撑 iOS 12，因而，咱们或许很快就会迁移到 SwiftUI + Combine 架构。店员们，这便是未来，仅有的问题是 “你们多久才干准备好抛弃你们的遗产，进入一个勇敢的新世界？”。没有人强迫你，但这是必要的。仅仅为了避免你的开发人员陷入抑郁。
开源
“为什么他们不开源 Combine？” 成为一个十分受欢迎的问题，这对我来说很奇怪。仅仅由于所有其他 Apple 结构都不是开源的。他们或许运用普通用户不允许的功用。他们不想处理问题、审查贡献者的 PR。由于他们比其他人能更好地处理这个问题。便是这样，我不想有任何其他理由赞同该政策。
Subjective
抱歉，Publisher 是一个十分糟糕的名字。咱们有一本由四人组成的书，具有众所周知的可调查形式。咱们有巨大的埃里克・迈耶，毕竟，你称其为 Publisher？当然，我会习气的，可是…… 在俄语中，Publisher 翻译为 “他”，Observable 翻译为 “它”。苹果，多样性怎么样？
此外，RxSwift 支撑开箱即用的 dark 形式，这一点我不能说 Joint。你的选择。
我的方案
首要，我要为 RxSwift 的美好日子喝点啤酒。我将进行一些有关 RxSwift 与 Combine 的技术讲座。老实说，我仅仅想让人们明白他们手中握着的是什么。不仅仅是大声喊出 “富丽”、“惊人” 或 “令人振奋” 等词语，而是真实理解为什么这是…… 令人振奋。这不仅仅是一个功用，它是 iOS 开发的新时代。我押注于 Combine 和 SwiftUI，并主张你也这样做。
10 年后，我打算成为一个白叟，告诉大家咱们是怎么运用 RxSwift 的。并且，该死的，太棒了。
