不要打断链式结构：使用 RxJava的 compose() 操作符
编辑推荐：稀土掘金，这是一个针对技术开发者的一个应用，你可以在掘金上获取最新最优质的技术干货，不仅仅是Android知识、前端、后端以至于产品和设计都有涉猎，想成为全栈工程师的朋友不要错过！
-
原文链接： Don't break the chain: use RxJava's compose() operator
-
原文作者： Dan Lew
-
译文出自： 小鄧子的简书
-
译者： 小鄧子
-
校对者： hi大头鬼hi
-
状态： 完成
-
译者注：为了方便因Lambda（译文）还不够了解的同学进行阅读，本篇译文替换了原作中全部Lambda表达式。
RxJava的另一个好处在于，我们可以清楚地看到数据是如何在一系列操作符之间进行转换的。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Observable.from(someSource)
.map(
new
Func1<Data, Data>() {
@Override public Data call(Data data) {
return
manipulate(data);
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(
new
Action1<Data>() {
@Override public void call(Data data) {
doSomething(data);
}
});
|
如何将一组操作符重用于多个数据流中呢？例如，因为希望在工作线程中处理数据，然后在主线程中处理结果，所以我会频繁使用subscribeOn()和observeOn()。如果我能够通过重用的方式，将这种逻辑运用到我所有的数据流中，将是一件多么伟大的事。
糟糕的实现方式
下面这些代码是我在过去几个月里一直都在使用的，正好可以拿来当反面教材。
首先，使用schedulers（调度）创建一个方法：
|
1
2
3
4
|
<T> Observable<T> applySchedulers(Observable<T> observable) {
return
observable.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread());
}
|
然后，封装Observable数据链：
|
1
2
3
4
5
6
7
8
9
10
|
applySchedulers(Observable.from(someSource).map(
new
Func1<Data, Data>() {
@Override public Data call(Data data) {
return
manipulate(data);
}
})
).subscribe(
new
Action1<Data>() {
@Override public void call(Data data) {
doSomething(data);
}
});
|
虽然这样做也能达到目的，但是它看起来不仅丑，还容易让人产生困惑，applySchedulers()到底什么鬼？它不再符合操作符链路式结构，所以，看起来很难理解。然而，我找不到任何办法去格式化这段代码，因此，这并不尴尬。
现在，试想一下，如果在一个数据流中反复使用的话，这个反面教材将会变得要多烂有多烂。（译者注：OMG）
Transformers简介
聪明的同学可能已经意识到了这个问题，但是RxJava早已提供了一种解决方案：Transformer（译者注：有转换器意思），一般情况下可以通过使用操作符Observable.compose()来实现。
Transformer实际上就是一个Func1<Observable<T>, Observable<R>>，换言之就是：可以通过它将一种类型的Observable转换成另一种类型的Observable，和调用一系列的内联操作符是一模一样的。
接下来，我们一起创建一个Transformer与schedulers相结合的方法：
|
1
2
3
4
5
6
7
8
9
|
<T> Transformer<T, T> applySchedulers() {
return
new
Transformer<T, T>() {
@Override
public Observable<T> call(Observable<T> observable) {
return
observable.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread());
}
};
}
|
使用Lambda表达式，会变得更加优雅:
|
1
2
3
4
|
<T> Transformer<T, T> applySchedulers() {
return
observable -> observable.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread());
}
|
更新于2015年3月11日：如果使用 JDK 7或者更早版本进行编译的话，就不得不做出一些额外的改变，为compose()添加泛型。显式声明返回类型，就像这样：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Observable.from(someSource)
.map(
new
Func1<Data, Data>() {
@Override public Data call(Data data) {
return
manipulate(data);
}
})
.compose(
this
.<YourType>applySchedulers())
.subscribe(
new
Action1<Data>() {
@Override public void call(Data data) {
doSomething(data);
}
});
|
重用Transformers
上一个实例中，我在所有的方法调用中都new（译者注：新建）了一个Transformer实例。你可以创建一个实例化版本，节省不必要的实例化对象。毕竟，Transformers关乎着代码重用。
如果，总是将一个具体的类型转换成另一个具体的类型，那么可以很容易的创建一个Transformer实例：
|
1
2
3
|
Transformer<String, String> myTransformer =
new
Transformer<String, String>() {
// ...Do your work here...
};
|
那么scheduler Transformer（调度转换器）应该怎样实现呢？因为，它根本不需要关心类型，所以就无法定义一个泛型实例：
|
1
2
|
// Doesn't compile; where would T come from?（译者注：编译无法通过；因为根本不知道 T 从何而来。）
Transformer<T, T> myTransformer;
|
可能有人会这样定义Transformer<Object, Object>，然而这并没有什么卵用，并且造成的后果就是Observable将失去其类型信息。
为了解决这个问题，我从Collections中得到了一些启发，这个包装类有这样一堆方法，能够创建类型安全并且不可变的空集合（比如，Collections.emptyList()）。由于在其内部使用了一个无泛型实例，所以需要封装在一个添加泛型约束的方法里。
可以像下面这样定义我们的schedulers Transformer（调度转换器）实例：
|
1
2
3
4
5
6
7
8
9
10
|
final Observable.Transformer schedulersTransformer =
new
Observable.Transformer() {
@Override public Object call(Object observable) {
return
((Observable) observable).subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread());
}
};
<T> Observable.Transformer<T, T> applySchedulers() {
return
(Observable.Transformer<T, T>) schedulersTransformer;
}
|
现在我们终于把他做成一个“单例”了（译者注：此单例非彼单例）。
警告：如果不做类型转换检查，可能陷入麻烦。确保Transformer真正与类型无关。否则，即使代码通过了编译，在运行时仍然存在抛出ClassCastException异常的隐患。在当前场景中，我们知道它是安全的，因为schedulers（译者注：调度）并不会与发送出的事件产生任何的互动操作。
flatMap()操作符怎么样？
现在你可能会好奇，compose()操作符和flatMap()操作符有何区别。他们最终都会发送出Observable<R>，这就意味着，两者都能够用于操作符的重用？
不同点在于compose()操作符拥有更高层次的抽象概念：它操作于整个数据流中，不仅仅是某一个被发送的事件。具体如下：
-
compose()是唯一一个能够从数据流中得到原始Observable<T>的操作符，所以，那些需要对整个数据流产生作用的操作（比如，subscribeOn()和observeOn()）需要使用compose()来实现。相较而言，如果在flatMap()中使用subscribeOn()或者observeOn()，那么它仅仅对在flatMap()中创建的Observable起作用，而不会对剩下的流产生影响（译者注：深坑，会在后面的系列着重讲解，欢迎关注）。
-
当创建Observable流的时候，compose()会立即执行，犹如已经提前写好了一个操作符一样，而flatMap()则是在onNext()被调用后执行，onNext()的每一次调用都会触发flatMap()，也就是说，flatMap()转换每一个事件，而compose()转换的是整个数据流。
-
因为每一次调用onNext()后，都不得不新建一个Observable，所以flatMap()的效率较低。事实上，compose()操作符只在主干数据流上执行操作。
如果想重用一些操作符，还是使用compose()吧，虽然flatMap()的用处很多，但作为重用代码这一点来讲，并不适用。