Rxjava原理与场景全面解析篇，值得一看！，安卓手机界面设计规范

Student[] students = …;

Subscriber subscriber = new Subscriber() {

@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 subscriber = new Subscriber() {

@Override

public void onNext(Student student) {

List 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 subscriber = new Subscriber() {

@Override

public void onNext(Course course) {

Log.d(tag, course.getName());

}

…

};

Observable.from(students)

.flatMap(new Func1<Student, Observable>() {

@Override

public Observable call(Student student) {

return Observable.from(student.getCourses());

}

})

.subscribe(subscriber);

从上面的代码可以看出， flatMap() 和 map() 有一个相同点：它也是把传入的参数转化之后返回另一个对象。但需要注意，和 map() 不同的是， flatMap() 中返回的是个 Observable 对象，并且这个 Observable 对象并不是被直接发送到了 Subscriber 的回调方法中。 flatMap() 的原理是这样的：1. 使用传入的事件对象创建一个 Observable 对象；2. 并不发送这个 Observable, 而是将它激活，于是它开始发送事件；3. 每一个创建出来的 Observable 发送的事件，都被汇入同一个 Observable ，而这个 Observable 负责将这些事件统一交给 Subscriber 的回调方法。这三个步骤，把事件拆成了两级，通过一组新创建的 Observable 将初始的对象『铺平』之后通过统一路径分发了下去。而这个『铺平』就是 flatMap() 所谓的 flat。

flatMap() 示意图：

扩展：由于可以在嵌套的 Observable 中添加异步代码， flatMap() 也常用于嵌套的异步操作，例如嵌套的网络请求。示例代码（Retrofit + RxJava）：

networkClient.token() // 返回 Observable，在订阅时请求 token，并在响应后发送 token

.flatMap(new Func1<String, Observable>() {

@Override

public Observable call(String token) {

// 返回 Observable，在订阅时请求消息列表，并在响应后发送请求到的消息列表

return networkClient.messages();

}

})

.subscribe(new Action1() {

@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 Observable lift(Operator<? extends R, ? super T> operator) {

return Observable.create(new OnSubscribe() {

@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() 时：

1.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() {

@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 call(Observable 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() 的原理比较简单，不附图喽。

5. 线程控制：Scheduler (二)

除了灵活的变换，RxJava 另一个牛逼的地方，就是线程的自由控制。

1) Scheduler 的 API (二)

前面讲到了，可以利用 subscribeOn() 结合 observeOn() 来实现线程控制，让事件的产生和消费发生在不同的线程。可是在了解了 map() flatMap() 等变换方法后，有些好事的（其实就是当初刚接触 RxJava 时的我）就问了：能不能多切换几次线程？

答案是：能。因为 observeOn() 指定的是 Subscriber 的线程，而这个 Subscriber 并不是（严格说应该为『不一定是』，但这里不妨理解为『不是』）subscribe() 参数中的 Subscriber ，而是 observeOn() 执行时的当前 Observable 所对应的 Subscriber ，即它的直接下级 Subscriber 。换句话说，observeOn() 指定的是它之后的操作所在的线程。因此如果有多次切换线程的需求，只要在每个想要切换线程的位置调用一次 observeOn() 即可。上代码：

Observable.just(1, 2, 3, 4) // IO 线程，由 subscribeOn() 指定

.subscribeOn(Schedulers.io())

.observeOn(Schedulers.newThread())

.map(mapOperator) // 新线程，由 observeOn() 指定

.observeOn(Schedulers.io())

.map(mapOperator2) // IO 线程，由 observeOn() 指定

.observeOn(AndroidSchedulers.mainThread)

.subscribe(subscriber); // Android 主线程，由 observeOn() 指定

如上，通过 observeOn() 的多次调用，程序实现了线程的多次切换。

不过，不同于 observeOn() ， subscribeOn() 的位置放在哪里都可以，但它是只能调用一次的。

又有好事的（其实还是当初的我）问了：如果我非要调用多次 subscribeOn() 呢？会有什么效果？

这个问题先放着，我们还是从 RxJava 线程控制的原理说起吧。

2) Scheduler 的原理（二）

其实， subscribeOn() 和 observeOn() 的内部实现，也是用的 lift()。具体看图（不同颜色的箭头表示不同的线程）：

subscribeOn() 原理图：

observeOn() 原理图：

从图中可以看出，subscribeOn() 和 observeOn() 都做了线程切换的工作（图中的 “schedule…” 部位）。不同的是， subscribeOn() 的线程切换发生在 OnSubscribe 中，即在它通知上一级 OnSubscribe 时，这时事件还没有开始发送，因此 subscribeOn() 的线程控制可以从事件发出的开端就造成影响；而 observeOn() 的线程切换则发生在它内建的 Subscriber 中，即发生在它即将给下一级 Subscriber 发送事件时，因此 observeOn() 控制的是它后面的线程。

最后，我用一张图来解释当多个 subscribeOn() 和 observeOn() 混合使用时，线程调度是怎么发生的（由于图中对象较多，相对于上面的图对结构做了一些简化调整）：

图中共有 5 处含有对事件的操作。由图中可以看出，①和②两处受第一个 subscribeOn() 影响，运行在红色线程；③和④处受第一个 observeOn() 的影响，运行在绿色线程；⑤处受第二个 onserveOn() 影响，运行在紫色线程；而第二个 subscribeOn() ，由于在通知过程中线程就被第一个 subscribeOn() 截断，因此对整个流程并没有任何影响。这里也就回答了前面的问题：当使用了多个 subscribeOn() 的时候，只有第一个 subscribeOn() 起作用。

3) 延伸：doOnSubscribe()

然而，虽然超过一个的 subscribeOn() 对事件处理的流程没有影响，但在流程之前却是可以利用的。

在前面讲 Subscriber 的时候，提到过 Subscriber 的 onStart() 可以用作流程开始前的初始化。然而 onStart() 由于在 subscribe() 发生时就被调用了，因此不能指定线程，而是只能执行在 subscribe() 被调用时的线程。这就导致如果 onStart() 中含有对线程有要求的代码（例如在界面上显示一个 ProgressBar，这必须在主线程执行），将会有线程非法的风险，因为有时你无法预测 subscribe() 将会在什么线程执行。

而与 Subscriber.onStart() 相对应的，有一个方法 Observable.doOnSubscribe() 。它和 Subscriber.onStart() 同样是在 subscribe()调用后而且在事件发送前执行，但区别在于它可以指定线程。默认情况下， doOnSubscribe() 执行在 subscribe() 发生的线程；而如果在 doOnSubscribe() 之后有 subscribeOn() 的话，它将执行在离它最近的 subscribeOn() 所指定的线程。

示例代码：

Observable.create(onSubscribe)

.subscribeOn(Schedulers.io())

.doOnSubscribe(new Action0() {

@Override

public void call() {

progressBar.setVisibility(View.VISIBLE); // 需要在主线程执行

}

})

.subscribeOn(AndroidSchedulers.mainThread()) // 指定主线程

.observeOn(AndroidSchedulers.mainThread())

.subscribe(subscriber);

如上，在 doOnSubscribe()的后面跟一个 subscribeOn() ，就能指定准备工作的线程了。

RxJava 的适用场景和使用方式

1. 与 Retrofit 的结合

Retrofit 是 Square 的一个著名的网络请求库。没有用过 Retrofit 的可以选择跳过这一小节也没关系，我举的每种场景都只是个例子，而且例子之间并无前后关联，只是个抛砖引玉的作用，所以你跳过这里看别的场景也可以的。

Retrofit 除了提供了传统的 Callback 形式的 API，还有 RxJava 版本的 Observable 形式 API。下面我用对比的方式来介绍 Retrofit 的 RxJava 版 API 和传统版本的区别。

以获取一个 User 对象的接口作为例子。使用Retrofit 的传统 API，你可以用这样的方式来定义请求：

@GET(“/user”)

public void getUser(@Query(“userId”) String userId, Callback callback);

在程序的构建过程中， Retrofit 会把自动把方法实现并生成代码，然后开发者就可以利用下面的方法来获取特定用户并处理响应：

getUser(userId, new Callback() {

@Override

public void success(User user) {

userView.setUser(user);

}

@Override

public void failure(RetrofitError error) {

// Error handling

…

}

};

而使用 RxJava 形式的 API，定义同样的请求是这样的：

@GET(“/user”)

public Observable getUser(@Query(“userId”) String userId);

使用的时候是这样的：

getUser(userId)

.observeOn(AndroidSchedulers.mainThread())

.subscribe(new Observer() {

@Override

public void onNext(User user) {

userView.setUser(user);

}

@Override

public void onCompleted() {

}

@Override

public void onError(Throwable error) {

// Error handling

…

}

});

看到区别了吗？

当 RxJava 形式的时候，Retrofit 把请求封装进 Observable ，在请求结束后调用 onNext() 或在请求失败后调用 onError()。

对比来看， Callback 形式和 Observable 形式长得不太一样，但本质都差不多，而且在细节上 Observable 形式似乎还比 Callback 形式要差点。那 Retrofit 为什么还要提供 RxJava 的支持呢？

因为它好用啊！从这个例子看不出来是因为这只是最简单的情况。而一旦情景复杂起来， Callback 形式马上就会开始让人头疼。比如：

假设这么一种情况：你的程序取到的 User 并不应该直接显示，而是需要先与数据库中的数据进行比对和修正后再显示。使用 Callback方式大概可以这么写：

getUser(userId, new Callback() {

@Override

public void success(User user) {

processUser(user); // 尝试修正 User 数据

userView.setUser(user);

}

@Override

public void failure(RetrofitError error) {

// Error handling

…

}

};

有问题吗？

很简便，但不要这样做。为什么？因为这样做会影响性能。数据库的操作很重，一次读写操作花费 10~20ms 是很常见的，这样的耗时很容易造成界面的卡顿。所以通常情况下，如果可以的话一定要避免在主线程中处理数据库。所以为了提升性能，这段代码可以优化一下：

getUser(userId, new Callback() {

@Override

public void success(User user) {

new Thread() {

@Override

public void run() {

processUser(user); // 尝试修正 User 数据

runOnUiThread(new Runnable() { // 切回 UI 线程

@Override

public void run() {

userView.setUser(user);

}

});

}).start();

}

@Override

public void failure(RetrofitError error) {

// Error handling

…

}

};

性能问题解决，但……这代码实在是太乱了，迷之缩进啊！杂乱的代码往往不仅仅是美观问题，因为代码越乱往往就越难读懂，而如果项目中充斥着杂乱的代码，无疑会降低代码的可读性，造成团队开发效率的降低和出错率的升高。

这时候，如果用 RxJava 的形式，就好办多了。 RxJava 形式的代码是这样的：

getUser(userId)

.doOnNext(new Action1() {

@Override

public void call(User user) {

processUser(user);

})

.observeOn(AndroidSchedulers.mainThread())

.subscribe(new Observer() {

@Override

public void onNext(User user) {

userView.setUser(user);

}

@Override

public void onCompleted() {

}

@Override

public void onError(Throwable error) {

// Error handling

…

}

});

后台代码和前台代码全都写在一条链中，明显清晰了很多。

再举一个例子：假设 /user 接口并不能直接访问，而需要填入一个在线获取的 token ，代码应该怎么写？

Callback 方式，可以使用嵌套的 Callback：

@GET(“/token”)

public void getToken(Callback callback);

@GET(“/user”)

public void getUser(@Query(“token”) String token, @Query(“userId”) String userId, Callback callback);

…

getToken(new Callback() {

@Override

public void success(String token) {

getUser(token, userId, new Callback() {

@Override

public void success(User user) {

userView.setUser(user);

}

@Override

public void failure(RetrofitError error) {

// Error handling

…

}

};

}

@Override

public void failure(RetrofitError error) {

// Error handling

…

}

});

倒是没有什么性能问题，可是迷之缩进毁一生，你懂我也懂，做过大项目的人应该更懂。

而使用 RxJava 的话，代码是这样的：

@GET(“/token”)

public Observable getToken();

@GET(“/user”)

public Observable getUser(@Query(“token”) String token, @Query(“userId”) String userId);

…

getToken()

.flatMap(new Func1<String, Observable>() {

@Override

public Observable onNext(String token) {

return getUser(token, userId);

})

.observeOn(AndroidSchedulers.mainThread())

.subscribe(new Observer() {

@Override

public void onNext(User user) {

userView.setUser(user);

}

@Override

public void onCompleted() {

}

@Override

public void onError(Throwable error) {

// Error handling

…

}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

HYwRoHr-1712760118514)]
[外链图片转存中…(img-eEmE5Us5-1712760118514)]
[外链图片转存中…(img-yJ0vG8SF-1712760118515)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-xvXfzCg3-1712760118515)]

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

[外链图片转存中…(img-F9eXLagi-1712760118515)]

【算法合集】

[外链图片转存中…(img-EEgHF8hs-1712760118516)]

【延伸Android必备知识点】

[外链图片转存中…(img-e980QGaz-1712760118516)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-zTKMu26o-1712760118516)]