这是我参与11月更文挑战的第6天，活动详情查看：2021最后一次更文挑战
由于是本人闲暇时间写出来的一些见解，篇幅较长，所以分为几个部分发布出来，可以看我主页拿PDF版本的
线程控制 —— Scheduler (一)
在不指定线程的情况下， RxJava 遵循的是线程不变的原则，即：在哪个线程调用 subscribe() ，就在
哪个线程生产事件；在哪个线程生产事件，就在哪个线程消费事件。如果需要切换线程，就需要用到
Scheduler （调度器）。
1) Scheduler 的 API (一)
在RxJava 中， Scheduler ——调度器，相当于线程控制器，RxJava 通过它来指定每一段代码应该运行
在什么样的线程。RxJava 已经内置了几个 Scheduler ，它们已经适合大多数的使用场景：
Schedulers.immediate() : 直接在当前线程运行，相当于不指定线程。这是默认的
Scheduler 。
Schedulers.newThread() : 总是启用新线程，并在新线程执行操作。
Schedulers.io() : I/O 操作（读写文件、读写数据库、网络信息交互等）所使用的
Scheduler 。行为模式和 newThread() 差不多，区别在于 io() 的内部实现是是用一个无数量
上限的线程池，可以重用空闲的线程，因此多数情况下 io() 比 newThread() 更有效率。不要把
计算工作放在 io() 中，可以避免创建不必要的线程。
Schedulers.computation() : 计算所使用的 Scheduler 。这个计算指的是 CPU 密集型计算，即
不会被 I/O 等操作限制性能的操作，例如图形的计算。这个 Scheduler 使用的固定的线程池，大
小为 CPU 核数。不要把 I/O 操作放在 computation() 中，否则 I/O 操作的等待时间会浪费
CPU。
另外， Android 还有一个专用的 AndroidSchedulers.mainThread() ，它指定的操作将在
Android 主线程运行。
有了这几个 Scheduler ，就可以使用 subscribeOn() 和 observeOn() 两个方法来对线程进行控制
了。 * subscribeOn() : 指定 subscribe() 所发生的线程，即 Observable.OnSubscribe 被激活时
所处的线程。或者叫做事件产生的线程。 * observeOn() : 指定 Subscriber 所运行在的线程。或者叫
做事件消费的线程。
文字叙述总归难理解，上代码：
Observable.just(1, 2, 3, 4)
.subscribeOn(Schedulers.io()) // 指定 subscribe() 发生在 IO 线程
.observeOn(AndroidSchedulers.mainThread()) // 指定 Subscriber 的回调发生在主线程
.subscribe(new Action1<Integer>() {
@Override
public void call(Integer number) {
Log.d(tag, "number:" + number);
}
});
上面这段代码中，由于 subscribeOn(Schedulers.io()) 的指定，被创建的事件的内容 1 、 2 、
3 、 4 将会在 IO 线程发出；而由于 observeOn(AndroidScheculers.mainThread() ) 的指定，因此
subscriber 数字的打印将发生在主线程 。事实上，这种在 subscribe() 之前写上两句
subscribeOn(Scheduler.io()) 和 observeOn(AndroidSchedulers.mainThread()) 的使用方式非
常常见，它适用于多数的 『后台线程取数据，主线程显示』的程序策略。
而前面提到的由图片 id 取得图片并显示的例子，如果也加上这两句
int drawableRes = ...;
ImageView imageView = ...;
Observable.create(new OnSubscribe<Drawable>() {
@Override
public void call(Subscriber<? super Drawable> subscriber) {
Drawable drawable = getTheme().getDrawable(drawableRes));
subscriber.onNext(drawable);
subscriber.onCompleted();
}
})
.subscribeOn(Schedulers.io()) // 指定 subscribe() 发生在 IO 线程
.observeOn(AndroidSchedulers.mainThread()) // 指定 Subscriber 的回调发生在主线程
.subscribe(new Observer<Drawable>() {
@Override
public void onNext(Drawable drawable) {
imageView.setImageDrawable(drawable);
}
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
Toast.makeText(activity, "Error!", Toast.LENGTH_SHORT).show();
}
});
那么，加载图片将会发生在 IO 线程，而设置图片则被设定在了主线程。这就意味着，即使加载图片耗费
了几十甚至几百毫秒的时间，也不会造成丝毫界面的卡顿。
- Scheduler 的原理 (一)
RxJava 的 Scheduler API 很方便，也很神奇（加了一句话就把线程切换了，怎么做到的？而且
subscribe() 不是最外层直接调用的方法吗，它竟然也能被指定线程？）。然而 Scheduler 的原理需
要放在后面讲，因为它的原理是以下一节《变换》的原理作为基础的。
Observable.just(1, 2, 3, 4)
.subscribeOn(Schedulers.io()) // 指定 subscribe() 发生在 IO 线程
.observeOn(AndroidSchedulers.mainThread()) // 指定 Subscriber 的回调发生在主线程
.subscribe(new Action1<Integer>() {
@Override
public void call(Integer number) {
Log.d(tag, "number:" + number);
}
});
int drawableRes = ...;
ImageView imageView = ...;
Observable.create(new OnSubscribe<Drawable>() {
@Override
public void call(Subscriber<? super Drawable> subscriber) {
Drawable drawable = getTheme().getDrawable(drawableRes));
subscriber.onNext(drawable);
subscriber.onCompleted();
}
})
.subscribeOn(Schedulers.io()) // 指定 subscribe() 发生在 IO 线程
.observeOn(AndroidSchedulers.mainThread()) // 指定 Subscriber 的回调发生在主线程
.subscribe(new Observer<Drawable>() {
@Override
public void onNext(Drawable drawable) {
imageView.setImageDrawable(drawable);
}
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
Toast.makeText(activity, "Error!", Toast.LENGTH_SHORT).show();
}
});
好吧这一节其实我屁也没说，只是为了让你安心，让你知道我不是忘了讲原理，而是把它放在了更合适
的地方。
2. 变换
终于要到牛逼的地方了，不管你激动不激动，反正我是激动了。
RxJava 提供了对事件序列进行变换的支持，这是它的核心功能之一，也是大多数人说『RxJava 真是太好
用了』的最大原因。所谓变换，就是将事件序列中的对象或整个序列进行加工处理，转换成不同的事件
或事件序列。概念说着总是模糊难懂的，来看 API。
1) API
首先看一个 map() 的例子：
Observable.just("images/logo.png") // 输入类型 String
.map(new Func1<String, Bitmap>() {
@Override
public Bitmap call(String filePath) { // 参数类型 String
return getBitmapFromPath(filePath); // 返回类型 Bitmap
}
})
.subscribe(new Action1<Bitmap>() {
@Override
public void call(Bitmap bitmap) { // 参数类型 Bitmap
showBitmap(bitmap);
}
});
这里出现了一个叫做 Func1 的类。它和 Action1 非常相似，也是 RxJava 的一个接口，用于包装含有
一个参数的方法。 Func1 和 Action 的区别在于， Func1 包装的是有返回值的方法。另外，和
ActionX 一样， FuncX 也有多个，用于不同参数个数的方法。 FuncX 和 ActionX 的区别在 FuncX
包装的是有返回值的方法。
可以看到， map() 方法将参数中的 String 对象转换成一个 Bitmap 对象后返回，而在经过 map() 方
法后，事件的参数类型也由 String 转为了 Bitmap 。这种直接变换对象并返回的，是最常见的也最容
易理解的变换。不过 RxJava 的变换远不止这样，它不仅可以针对事件对象，还可以针对整个事件队列，
这使得 RxJava 变得非常灵活。我列举几个常用的变换：
map() : 事件对象的直接变换，具体功能上面已经介绍过。它是 RxJava 最常用的变换。 map() 的
示意图：
flatMap() : 这是一个很有用但非常难理解的变换，因此我决定花多些篇幅来介绍它。 首先假设这
么一种需求：假设有一个数据结构『学生』，现在需要打印出一组学生的名字。实现方式很简单：
Student[] students = ...;
Subscriber<String> subscriber = new Subscriber<String>() {
@Override
public void onNext(String name) {
Log.d(tag, name);
}
...
};
Observable.from(students)
.map(new Func1<Student, String>() {
@Override
public String call(Student student) {
return student.getName();
}
})
.subscribe(subscriber);
很简单。那么再假设：如果要打印出每个学生所需要修的所有课程的名称呢？（需求的区别在于，每个
学生只有一个名字，但却有多个课程。）首先可以这样实现：
Student[] students = ...;
Subscriber<Student> subscriber = new Subscriber<Student>() {
@Override
public void onNext(Student student) {
List<Course> courses = student.getCourses();
for (int i = 0; i < courses.size(); i++) {
Course course = courses.get(i);
Log.d(tag, course.getName());}
}
...
};
Observable.from(students)
.subscribe(subscriber);
依然很简单。那么如果我不想在 Subscriber 中使用 for 循环，而是希望 Subscriber 中直接传入单
个的 Course 对象呢（这对于代码复用很重要）？用 map() 显然是不行的，因为 map() 是一对一的
转化，而我现在的要求是一对多的转化。那怎么才能把一个 Student 转化成多个 Course 呢？
这个时候，就需要用 flatMap() 了：
Student[] students = ...;
Subscriber<Course> subscriber = new Subscriber<Course>() {
@Override
public void onNext(Course course) {
Log.d(tag, course.getName());
}
...
};
Observable.from(students)
.flatMap(new Func1<Student, Observable<Course>>() {
@Override
public Observable<Course> call(Student student) {
return Observable.from(student.getCourses());
}
})
.subscribe(subscriber);
从上面的代码可以看出， flatMap() 和 map() 有一个相同点：它也是把传入的参数转化之后返回另
一个对象。但需要注意，和 map() 不同的是， flatMap() 中返回的是个 Observable 对象，并且这
个 Observable 对象并不是被直接发送到了 Subscriber 的回调方法中。 flatMap() 的原理是这样
的：
-
使用传入的事件对象创建一个 Observable 对象；
-
并不发送这个 Observable , 而是将它激活，于是它开始发送事件；
-
每一个创建出来的 Observable 发送的事件，都被汇入同一个Observable ，而这个 Observable 负责将这些事件统一交给 Subscriber 的回调方法。
这三个步骤，把事件拆成了两级，通过一组新创建的 Observable 将初始的对象『铺平』之后通过统一路径分发
了下去。而这个『铺平』就是 flatMap() 所谓的 flat。
flatMap() 示意图：
扩展：由于可以在嵌套的 Observable 中添加异步代码， flatMap() 也常用于嵌套的异步操作，例如
嵌套的网络请求。示例代码（Retrofit + RxJava）：
networkClient.token() // 返回 Observable<String>，在订阅时请求 token，并在响应后发送
token
.flatMap(new Func1<String, Observable<Messages>>() {
@Override
public Observable<Messages> call(String token) {
// 返回 Observable<Messages>，在订阅时请求消息列表，并在响应后发送请求到的消息
列表
return networkClient.messages();
}
})
.subscribe(new Action1<Messages>() {
@Override
public void call(Messages messages) {
// 处理显示消息列表
showMessages(messages);
}
});
传统的嵌套请求需要使用嵌套的 Callback 来实现。而通过 flatMap() ，可以把嵌套的请求写在一条链
中，从而保持程序逻辑的清晰。
- throttleFirst() : 在每次事件触发后的一定时间间隔内丢弃新的事件。常用作去抖动过滤，例如按钮的点击监听器： RxView.clickEvents(button) // RxBinding 代码，后面的文章有解释.throttleFirst(500, TimeUnit.MILLISECONDS) // 设置防抖间隔为 500ms.subscribe(subscriber); 妈妈再也不怕我的用户手抖点开两个重复的界面啦。
此外， RxJava 还提供很多便捷的方法来实现事件序列的变换，这里就不一一举例了。
2) 变换的原理：lift()
这些变换虽然功能各有不同，但实质上都是针对事件序列的处理和再发送。而在 RxJava 的内部，它们是
基于同一个基础的变换方法： lift(Operator) 。首先看一下 lift() 的内部实现（仅核心代码）：
// 注意：这不是 lift() 的源码，而是将源码中与性能、兼容性、扩展性有关的代码剔除后的核心代码。
// 如果需要看源码，可以去 RxJava 的 GitHub 仓库下载。
public <R> Observable<R> lift(Operator<? extends R, ? super T> operator) {
return Observable.create(new OnSubscribe<R>() {
@Override
public void call(Subscriber subscriber) {
Subscriber newSubscriber = operator.call(subscriber);
newSubscriber.onStart();
onSubscribe.call(newSubscriber);
}
});
}
这段代码很有意思：它生成了一个新的 Observable 并返回，而且创建新 Observable 所用的参数
OnSubscribe 的回调方法 call() 中的实现竟然看起来和前面讲过的 Observable.subscribe() 一
样！然而它们并不一样哟~不一样的地方关键就在于第二行 onSubscribe.call(subscriber) 中的
onSubscribe 所指代的对象不同（高能预警：接下来的几句话可能会导致身体的严重不适）——
subscribe() 中这句话的 onSubscribe 指的是 Observable 中的 onSubscribe 对象，这个没
有问题，但是 lift() 之后的情况就复杂了点。
当含有 lift() 时：
- lift() 创建了一个 Observable 后，加上之前的原始 Observable ，已经有两个
Observable 了；
2.而同样地，新 Observable 里的新 OnSubscribe 加上之前的原始 Observable 中的原始
OnSubscribe ，也就有了两个 OnSubscribe ；
3.当用户调用经过 lift() 后的 Observable 的 subscribe() 的时候，使用的是 lift() 所返
回的新的 Observable ，于是它所触发的 onSubscribe.call(subscriber) ，也是用的新
Observable 中的新 OnSubscribe ，即在 lift() 中生成的那个 OnSubscribe ；
4.而这个新 OnSubscribe 的 call() 方法中的 onSubscribe ，就是指的原始 Observable 中
的原始 OnSubscribe ，在这个 call() 方法里，新 OnSubscribe 利用
operator.call(subscriber) 生成了一个新的 Subscriber （ Operator 就是在这里，通过自
己的 call() 方法将新 Subscriber 和原始 Subscriber 进行关联，并插入自己的『变换』代码
以实现变换），然后利用这个新 Subscriber 向原始 Observable 进行订阅。
这样就实现了 lift() 过程，有点像一种代理机制，通过事件拦截和处理实现事件序列的变换。
精简掉细节的话，也可以这么说：在 Observable 执行了 lift(Operator) 方法之后，会返回一个新
的 Observable ，这个新的 Observable 会像一个代理一样，负责接收原始的 Observable 发出的事
件，并在处理后发送给 Subscriber 。
如果你更喜欢具象思维，可以看图：
两次和多次的 lift() 同理，如下图：
举一个具体的 Operator 的实现。下面这是一个将事件中的 Integer 对象转换成 String 的例子，仅
供参考：
observable.lift(new Observable.Operator<String, Integer>() {
@Override
public Subscriber<? super Integer> call(final Subscriber<? super String>
subscriber) {
// 将事件序列中的 Integer 对象转换为 String 对象
return new Subscriber<Integer>() {
@Override
public void onNext(Integer integer) {
subscriber.onNext("" + integer);
}
@Override
public void onCompleted() {
subscriber.onCompleted();
}
@Override
public void onError(Throwable e) {
subscriber.onError(e);
}
};
}
});
讲述 lift() 的原理只是为了让你更好地了解 RxJava ，从而可以更好地使用它。然而不管你是否
理解了 lift() 的原理，RxJava 都不建议开发者自定义 Operator 来直接使用 lift() ，而是建
议尽量使用已有的 lift() 包装方法（如 map() flatMap() 等）进行组合来实现需求，因为直
接使用 lift() 非常容易发生一些难以发现的错误。
3) compose: 对 Observable 整体的变换
除了 lift() 之外， Observable 还有一个变换方法叫做 compose(Transformer) 。它和 lift() 的
区别在于， lift() 是针对事件项和事件序列的，而 compose() 是针对 Observable 自身进行变
换。举个例子，假设在程序中有多个 Observable ，并且他们都需要应用一组相同的 lift() 变换。
你可以这么写：
observable1
.lift1()
.lift2()
.lift3()
.lift4()
.subscribe(subscriber1);
observable2
.lift1()
.lift2()
.lift3()
.lift4()
.subscribe(subscriber2);
observable3
.lift1()
.lift2()
.lift3()
.lift4()
.subscribe(subscriber3);
observable4
.lift1()
.lift2()
.lift3()
.lift4()
.subscribe(subscriber1);
你觉得这样太不软件工程了，于是你改成了这样：
private Observable liftAll(Observable observable) {
return observable
.lift1()
.lift2()
.lift3()
.lift4();
}
liftAll(observable1).subscribe(subscriber1);
liftAll(observable2).subscribe(subscriber2);
liftAll(observable3).subscribe(subscriber3);
liftAll(observable4).subscribe(subscriber4);
可读性、可维护性都提高了。可是 Observable 被一个方法包起来，这种方式对于 Observale 的灵活
性似乎还是增添了那么点限制。怎么办？这个时候，就应该用 compose() 来解决了：
public class LiftAllTransformer implements Observable.Transformer<Integer,
String> {
@Override
public Observable<String> call(Observable<Integer> observable) {
return observable
.lift1()
.lift2()
.lift3()
.lift4();
}
}
...
Transformer liftAll = new LiftAllTransformer();
observable1.compose(liftAll).subscribe(subscriber1);
observable2.compose(liftAll).subscribe(subscriber2);
observable3.compose(liftAll).subscribe(subscriber3);
observable4.compose(liftAll).subscribe(subscriber4);
像上面这样，使用 compose() 方法， Observable 可以利用传入的 Transformer 对象的 call 方法
直接对自身进行处理，也就不必被包在方法的里面了。
compose() 的原理比较简单，不附图喽。
