这里是原文：Traits (formerly Units)
这一篇是整篇翻译的后半部分，建议先看看前半部分：RxSwift之traits前篇：RxSwift traits
RxCocoa traits
Driver
这是最复杂的trait，它的目标是提供一种简便的方式在UI层编写响应式代码，或者任何你想模拟驱动你的App的数据流的情况。
- 不能抛出错误
- 监听发生在主线程
- 分享副作用（
shareReplayLatestWhileConnected)
为什么命名为Driver
它的目标用例是作为驱动你的App的序列模型。
例如：
- 由CoreData模型驱动UI
- 使用其他UI元素（绑定）的值驱动UI
就像正常的操作系统驱动程序一样，假如一个序列抛出错误，你的应用程序就会停止响应用户操作。
那些元素在主线程被监听，这极其重要，因为UI元素和程序逻辑通常不是线程安全的。
此外，Driver建立了一个分享副作用的可观察序列。
例如：
实际使用的例子
这是一个典型的初学者例子：
let results = query.rx.text
.throttle(0.3, scheduler: MainScheduler.instance)
.flatMapLatest { query in
fetchAutoCompleteItems(query)
}
results
.map { "\($0.count)" }
.bind(to: resultCount.rx.text)
.disposed(by: disposeBag)
results
.bind(to: resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
cell.textLabel?.text = "\(result)"
}
.disposed(by: disposeBag)```
以上代码的预期行为是：
* 节流用户输入
* 联系服务器并获取用户结果列表（每次查询一次）
* 绑定结果到两个UI元素：results table view和一个显示结果数字的label
那么，这个代码有什么问题呢？
* 如果`fetchAutoCompleteItems `可观察序列抛出错误（连接失败或者是解析错误），这个错误将会解绑所有元素，并且UI不会再响应新的查询。
* 如果`fetchAutoCompleteItems`在某个后台线程返回结果，这些结果将会从一个后台线程绑定到UI元素上，这将会导致不确定的崩溃。
* 结果被绑定到两个UI元素上，这就意味着，对于每个用户查询，都会建立两个HTTP请求，每个UI元素对应一个，这并不是预期的行为。
一个更为合适的代码版本如下：
let results = query.rx.text
.throttle(0.3, scheduler: MainScheduler.instance)
.flatMapLatest { query in
fetchAutoCompleteItems(query)
.observeOn(MainScheduler.instance) // results are returned on MainScheduler
.catchErrorJustReturn([]) // in the worst case, errors are handled
}
.shareReplay(1) // HTTP requests are shared and results replayed
// to all UI elements
results
.map { "($0.count)" }
.bind(to: resultCount.rx.text)
.disposed(by: disposeBag)
results
.bind(to: resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
cell.textLabel?.text = "(result)"
}
.disposed(by: disposeBag)```
确保所有这些要求在大型系统中被正确处理很有挑战性，但有一种简单的使用编译器和traits来证明这些要求得到满足的方法。
下面的代码看起来几乎一样：
let results = query.rx.text.asDriver() // This converts a normal sequence into a `Driver` sequence.
.throttle(0.3, scheduler: MainScheduler.instance)
.flatMapLatest { query in
fetchAutoCompleteItems(query)
.asDriver(onErrorJustReturn: []) // Builder just needs info about what to return in case of error.
}
results
.map { "\($0.count)" }
.drive(resultCount.rx.text) // If there is a `drive` method available instead of `bindTo`,
.disposed(by: disposeBag) // that means that the compiler has proven that all properties
// are satisfied.
results
.drive(resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
cell.textLabel?.text = "\(result)"
}
.disposed(by: disposeBag)```
那么这里发生了什么？
第一个`asDriver`方法把trait`ControlProperty `转换成trait`Driver `。
query.rx.text.asDriver()```
注意没有任何特别的事情需要做。Driver拥有ControlProperty所有的属性，加上一些其他的。底层的可观察序列只是被封装成了一个Drivertrait，就是这样。
第二个变化是：
.asDriver(onErrorJustReturn: [])```
任何可观察序列都能被转化为`Driver`，只要它满足三个属性：
* 不能抛出错误
* 在主线程监听
* 分享副作用（`shareReplayLatestWhileConnected `）
那么如何确保这些属性得到满足呢？只使用标准的Rx操作符。
`asDriver(onErrorJustReturn: []) `和以下代码是等价的。
let safeSequence = xs
.observeOn(MainScheduler.instance) // observe events on main scheduler
.catchErrorJustReturn(onErrorJustReturn) // can't error out
.shareReplayLatestWhileConnected // side effects sharing
return Driver(raw: safeSequence) // wrap it up```
最后一件事是用drive代替bindTo。
drive只在Driver特性里定义。这就意味着，如果你在某些代码里看到drive，那个可观察序列绝不会抛出错误，并且它在主线程监听，这对于绑定一个UI元素来说是安全的。
注意，然而理论上，别人仍然可以为ObservableType或者是一些其他接口定义一个drive方法来工作，因此为了更加安全，在绑定UI元素之前用let results: Driver<[Results]> = ...创建一个临时的定义是有必要的。然而，我们将留给读者来决定这是否是一个现实的方案。
ControlProperty / ControlEvent
- 不能抛出错误
- 订阅发生在主线程
- 监听发生在主线程
- 分享副作用
