swift - RxSwift 在可调试性方面的技术限制是什么？

Question

上下文:我的团队正在开始一个新的中型 Swift 项目(大约 20 MM)，我正在考虑在 RxSwift 中开发它.我的一位经理怀疑，他曾经在 上的调试方面有过不好的经历。响应式(Reactive)编程 所以他建议避免使用 RxSwift 并使用经典的 Swift。我试图找出 RxSwift 的缺点，但没有找到 them ，提到了可调试性问题。

问题: RxSwift 在可调试性方面的实际技术限制是什么？

Answer 1

自 2015 年 RxSwift 首次问世以来，我一直在使用它。多年来，我将其用于许多中小型项目。我不会说它很难调试，但它与调试不同。正如@AjinkaSharma 在评论中提到的那样，跟踪堆栈跟踪是一种非常令人沮丧的体验，所以甚至不要打扰。更好的是把 .debug()战略地点的运营商。另一个有用的工具是TimeLane这将允许您在分析器中跟踪您的 observables。
更重要的是，如果你很难让可观察链按照你想要的方式工作，编写单元测试 .将一些逻辑包装到运算符中然后使用 RxTest 为其编写测试非常容易，我不知道为什么更多人不这样做，除了他们习惯于单元测试在使用 MVC 时很痛苦.
根据我的经验，最难调试的部分是资源泄漏。除非您包含 TRACE_RESOURCES，否则即使检测它们也可能很困难。调试版本中的标志。完成此操作后，您可以将以下内容放入您的应用程序委托(delegate)中:

#if DEBUG
_ = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance)
    .map { _ in RxSwift.Resources.total }
    .distinctUntilChanged()
    .subscribe(onNext: { print("♦️ Resource count \($0)") })
#endif

这样，您可以在屏幕之间返回和第四次时跟踪资源计数，以确保所有内容都正确释放。
最后，您最终得到的架构非常实用，并且与大多数 Swift 开发人员习惯的非常不同。如果做得好，你最终会得到更多的闭包和自由函数以及更少的协议(protocol)和扩展，所以这也需要习惯。
加入我们的 RxSwift slack，那里有一群知识渊博且积极的参与者，他们很乐意在一天中的任何时间回答快速问题或分享一些代码。 https://rxslack.herokuapp.com