ios - `.drive()` 和 `.bind(to:)` 之间的区别

Question

我现在正在学习 RxSwift。

你什么时候用.drive(something)当.bind(to: something) ?

例子:

let disposeBag = DisposeBag()
let isEnabled = BehaviorRelay(value: true)
let button = UIButton()
// what is the benefit of this:
isEnabled.asDriver().drive(button.rx.isEnabled).disposed(by: disposeBag)
// over this:
isEnabled.bind(to: button.rx.isEnabled).disposed(by: disposeBag)
// or is the above better?

use RxSwift, driver and bind to中的答案真的没有帮助。我不明白为什么要添加 asDriver()甚至有必要让它成为一个不会失败的东西。

Answer 1

来自 RxSwift 的 GitHub 页面

This is the most elaborate trait. Its intention is to provide an intuitive way to write reactive code in the UI layer, or for any case where you want to model a stream of data Driving your application.

不能出错。

观察发生在主调度程序上。

股份方
效果(分享(重播:1，范围:.whileConnected))。

再次从同一页面复制

Its intended use case was to model sequences that drive your application.

现在回到差异？

驱动程序确保仅在主线程上发生观察:

Drive 是 RxSwift 中的特征之一，可确保仅在 MainThread 上发生观察。 , 这意味着无论在什么线程事件被触发和触发驱动程序，驱动程序将始终确保将事件转发到链中的下一个运算符(operator)或其在主线程上的订阅 block 。

在 Rx 中，所有事件都在事件发生的同一线程上传播。因此，如果您使用 subject.onNext( 在说线程 (100) 上触发主题，其订阅 block 将在同一个线程 (100) 上调用，直到且除非您使用 observedOn或 subscribedOn运算符(operator)确保手动线程切换。

如果您从 viewModel 中的 observables/subjects 驱动您的 UI 组件，那么驱动程序非常有意义。假设您在后台线程上进行 API 调用以从服务器获取数据，您不想在后台线程上访问您的 UI 组件，将您的可观察对象/主题连接/转换为驱动程序(使用 asDriver 并传递 onErrorJustReturn )并驱动您的通过驱动程序的 UI 组件将确保您的 UI 组件始终在主线程上访问

不能出错。

通常，当发生错误时，订阅将被终止，如果您正在驱动您的 UI 组件，您不希望每次发生错误事件时订阅/绑定(bind)都会中断。

示例:假设您通过 CoreData 驱动 tableView，并且由于某种原因从 CoreData 获取数据时发生错误，如果您不使用驱动器并且使用了平面 bind(to:它的 onError将被触发并且它与 UIComponent 的绑定(bind)将被破坏。如果您再次获取数据，您将不得不重新建立此绑定(bind)。对于获取/获取数据时的 UI 组件错误应该没有任何区别。它应该只是一个改变其状态的事件流。

bindTo只不过是 subscribe 上的语法糖衣所以如果你使用 bindTo或 subscribe要驱动 UI 组件，您将失去所有好处 drive天生就摆在桌面上。

您可以随时使用 observedOn确保手动切换线程到 main并且可能有一些重试机制来建立订阅回/在发生错误时保留订阅但最终您将最终编写自己的驱动器特征

什么时候应该使用驱动，什么时候应该使用 bindTo

拇指规则是您是否试图驱动 UI 组件使用 drive否则使用 bindTo .一般来说，如果您希望您的订阅只发生在主线程上并且不希望您的订阅出错(例如驱动 UI 组件)，请使用 driver否则坚持 bindTo或 subscribe
编辑 1:

OP在评论中的问题:

asDriver() in my example makes sure isEnabled is being observed on the main thread and I don’t have to pass onErrorJustReturn because BehaviorRelay also can’t fail? In this case drive() has the main thread benefit but not the failsafe benefit?

在我的示例中，确保在主线程上观察到 isEnabled - 是

我不必传递 onErrorJustReturn 因为 BehaviorRelay 也不能失败？ - 宾果游戏

如果您对 BehaviorRelay 进行更深入的检查，您会发现

/// BehaviorRelay is a wrapper for BehaviorSubject. /// /// UnlikeBehaviorSubject it can't terminate with error or completed.

很明显 BehaviorRelay 不会出错，因此编译器足够智能，可以理解并且不会要求 onErrorJustReturn .如果你真的想看一次使用 BehaviorSubject编译器会要求它:)

致 Daniel指出我的错误，驱动器并不是确保观察仅发生在 MainThread 上的唯一特征。因此编辑了我的答案以反射(reflect)相同的情况。谢谢