上下文：我的团队正在启动一个新的中型Swift项目（ 大约20 MM），我想用RxSwift开发它。我的一位经理怀疑，他曾经在Reactive Programming**上有过不好的调试经历，所以他建议避免使用RxSwift，使用经典的Swift。我试图找出RxSwift的缺点，我没有发现them，提到了可调试性问题。**问题：**RxSwift在可调试性方面的实际技术限制是什么？
RxSwift
bsxbgnwa1#
我从2015年RxSwift首次发布以来就一直在使用它。这些年来，我在许多中小型项目中使用了它。我不会说它很难调试，但它是 * 不同 * 调试。正如@AjinkaSharma在评论中提到的那样，跟踪堆栈跟踪是一种非常令人沮丧的体验，所以不要费心。更好的方法是将.debug()操作员放在战略位置。另一个有用的工具是[TimeLane][1]，它允许您在分析器中跟踪可观察数据。更重要的是，如果你有一点困难，让一个可观察链以你想要的方式工作，写一个单元测试。将一点逻辑 Package 到操作符中，然后使用RxTest为其编写测试是非常容易的，我不知道为什么更多的人不这样做，除了他们习惯于使用MVC时单元测试是一种痛苦。根据我的经验，最难调试的部分是资源泄漏。除非在调试版本中包含TRACE_RESOURCES标志，否则即使检测到它们也很困难。完成此操作后，您可以将以下内容放入应用委托中：
.debug()
TRACE_RESOURCES
#if DEBUG _ = Observable<Int>.interval(.seconds(1), scheduler: MainScheduler.instance) .map { _ in RxSwift.Resources.total } .distinctUntilChanged() .subscribe(onNext: { print("♦️ Resource count \($0)") }) #endif
这样，当您在两个屏幕之间来回切换时，您可以跟踪资源计数，以确保所有内容都被正确释放。最后，你最终得到的架构是非常实用的，与大多数Swift开发人员习惯的架构有很大的不同。如果做得好，你最终会得到更多的闭包和自由函数，以及更少的协议和扩展，所以这也需要习惯。Join us on the RxSwift slack，这里有一群知识渊博、活跃的参与者，他们很乐意在一天中的任何时候回答快速的问题或分享一些代码。
1条答案
按热度按时间bsxbgnwa1#
我从2015年RxSwift首次发布以来就一直在使用它。这些年来，我在许多中小型项目中使用了它。我不会说它很难调试，但它是 * 不同 * 调试。正如@AjinkaSharma在评论中提到的那样，跟踪堆栈跟踪是一种非常令人沮丧的体验，所以不要费心。更好的方法是将
.debug()操作员放在战略位置。另一个有用的工具是[TimeLane][1]，它允许您在分析器中跟踪可观察数据。更重要的是，如果你有一点困难，让一个可观察链以你想要的方式工作，写一个单元测试。将一点逻辑 Package 到操作符中，然后使用RxTest为其编写测试是非常容易的，我不知道为什么更多的人不这样做，除了他们习惯于使用MVC时单元测试是一种痛苦。
根据我的经验，最难调试的部分是资源泄漏。除非在调试版本中包含
TRACE_RESOURCES标志，否则即使检测到它们也很困难。完成此操作后，您可以将以下内容放入应用委托中：这样，当您在两个屏幕之间来回切换时，您可以跟踪资源计数，以确保所有内容都被正确释放。
最后，你最终得到的架构是非常实用的，与大多数Swift开发人员习惯的架构有很大的不同。如果做得好，你最终会得到更多的闭包和自由函数，以及更少的协议和扩展，所以这也需要习惯。
Join us on the RxSwift slack，这里有一群知识渊博、活跃的参与者，他们很乐意在一天中的任何时候回答快速的问题或分享一些代码。