不要打断链式结构:使用 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() {
       @Override public Data call(Data data) {
         return  manipulate(data);
       }
     }).subscribeOn(Schedulers.io())
     .observeOn(AndroidSchedulers.mainThread())
     .subscribe( new  Action1() {
       @Override public void call(Data data) {
         doSomething(data);
       }
     });

如何将一组操作符重用于多个数据流中呢?例如,因为希望在工作线程中处理数据,然后在主线程中处理结果,所以我会频繁使用subscribeOn()和observeOn()。如果我能够通过重用的方式,将这种逻辑运用到我所有的数据流中,将是一件多么伟大的事。

糟糕的实现方式

下面这些代码是我在过去几个月里一直都在使用的,正好可以拿来当反面教材。

首先,使用schedulers(调度)创建一个方法:

1
2
3
4
 Observable applySchedulers(Observable 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() {
       @Override public Data call(Data data) {
         return  manipulate(data);
       }
     })
).subscribe( new  Action1() {
   @Override public void call(Data data) {
     doSomething(data);
   }
});

虽然这样做也能达到目的,但是它看起来不仅丑,还容易让人产生困惑,applySchedulers()到底什么鬼?它不再符合操作符链路式结构,所以,看起来很难理解。然而,我找不到任何办法去格式化这段代码,因此,这并不尴尬。

现在,试想一下,如果在一个数据流中反复使用的话,这个反面教材将会变得要多烂有多烂。(译者注:OMG)

Transformers简介

聪明的同学可能已经意识到了这个问题,但是RxJava早已提供了一种解决方案:Transformer(译者注:有转换器意思),一般情况下可以通过使用操作符Observable.compose()来实现。

Transformer实际上就是一个Func1, Observable>,换言之就是:可以通过它将一种类型的Observable转换成另一种类型的Observable,和调用一系列的内联操作符是一模一样的。

接下来,我们一起创建一个Transformer与schedulers相结合的方法:

1
2
3
4
5
6
7
8
9
   Transformer applySchedulers() {
  return  new  Transformer() {
    @Override
    public Observable call(Observable observable) {
      return  observable.subscribeOn(Schedulers.io())
          .observeOn(AndroidSchedulers.mainThread());
    }
  };
}

使用Lambda表达式,会变得更加优雅:

1
2
3
4
 Transformer 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() {
        @Override public Data call(Data data) {
          return  manipulate(data);
        }
     })
     .compose( this .applySchedulers())
     .subscribe( new  Action1() {
       @Override public void call(Data data) {
         doSomething(data);
       }
     });

重用Transformers

上一个实例中,我在所有的方法调用中都new(译者注:新建)了一个Transformer实例。你可以创建一个实例化版本,节省不必要的实例化对象。毕竟,Transformers关乎着代码重用。

如果,总是将一个具体的类型转换成另一个具体的类型,那么可以很容易的创建一个Transformer实例:

1
2
3
Transformer myTransformer =  new  Transformer() {  
    // ...Do your work here...
};

那么scheduler Transformer(调度转换器)应该怎样实现呢?因为,它根本不需要关心类型,所以就无法定义一个泛型实例:

1
2
// Doesn't compile; where would T come from?(译者注:编译无法通过;因为根本不知道 T 从何而来。)
Transformer myTransformer;

可能有人会这样定义Transformer,然而这并没有什么卵用,并且造成的后果就是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());
   }
};
 
   Observable.Transformer applySchedulers() {
  return  (Observable.Transformer) schedulersTransformer;
}

现在我们终于把他做成一个“单例”了(译者注:此单例非彼单例)。

警告:如果不做类型转换检查,可能陷入麻烦。确保Transformer真正与类型无关。否则,即使代码通过了编译,在运行时仍然存在抛出ClassCastException异常的隐患。在当前场景中,我们知道它是安全的,因为schedulers(译者注:调度)并不会与发送出的事件产生任何的互动操作。

flatMap()操作符怎么样?

现在你可能会好奇,compose()操作符和flatMap()操作符有何区别。他们最终都会发送出Observable,这就意味着,两者都能够用于操作符的重用?

不同点在于compose()操作符拥有更高层次的抽象概念:它操作于整个数据流中,不仅仅是某一个被发送的事件。具体如下:

  1. compose()是唯一一个能够从数据流中得到原始Observable的操作符,所以,那些需要对整个数据流产生作用的操作(比如,subscribeOn()和observeOn())需要使用compose()来实现。相较而言,如果在flatMap()中使用subscribeOn()或者observeOn(),那么它仅仅对在flatMap()中创建的Observable起作用,而不会对剩下的流产生影响(译者注:深坑,会在后面的系列着重讲解,欢迎关注)。

  2. 当创建Observable流的时候,compose()会立即执行,犹如已经提前写好了一个操作符一样,而flatMap()则是在onNext()被调用后执行,onNext()的每一次调用都会触发flatMap(),也就是说,flatMap()转换每一个事件,而compose()转换的是整个数据流。

  3. 因为每一次调用onNext()后,都不得不新建一个Observable,所以flatMap()的效率较低。事实上,compose()操作符只在主干数据流上执行操作。

如果想重用一些操作符,还是使用compose()吧,虽然flatMap()的用处很多,但作为重用代码这一点来讲,并不适用。

你可能感兴趣的:(Android开发)