RxJava 沉思录（二）：空间维度，深入浅出

new TypeToken<List>(){}.getType()
);
// 刷新照片列表
adapter.setData(photos);
adapter.notifyDataSetChanged();
}
NetworkApi networkApi = …
networkApi.getAllPhotos()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(photos -> {
adapter.setData(photos);
adapter.notifyDataSetChanged();

// 更新缓存
DiskLruCache.Editor editor = cache.edit(“getAllPhotos”);
editor.set(VALUE_INDEX, new Gson().toJson(photos)).commit();
});

上面的代码就是最直观的可以解决需求的代码，我们进一步思考一下，读取文件缓存也属于耗时操作，我们最好把它封装为异步任务，既然网络请求已经被封装成 Observable 了，我们尝试把读取文件缓存也封装为 Observable :

Observable<List> cachedObservable = Observable.create(emitter -> {
DiskLruCache.Snapshot snapshot = cache.get(“getAllPhotos”);
if (snapshot != null) {
List cachedPhotos = new Gson().fromJson(
snapshot.getString(VALUE_INDEX),
new TypeToken<List>(){}.getType()
);
emitter.onNext(cachedPhotos);
}
emitter.onComplete();
});

到目前为止，发起网络请求和读取缓存这两个异步操作都被我们封装成了 Observable 的形式，前面做了这么多铺垫，接下来进入正题：把原先的面向 Callback 的异步操作统一改写为 Observable 的形式以后，首先带来的好处就是可以对 Observable 在空间维度上进行重新组织。

networkApi.getAllPhotos()
.doOnNext(photos ->
// 更新缓存
cache.edit(“getAllPhotos”)
.set(VALUE_INDEX, new Gson().toJson(photos))
.commit()
)
// 读取现有缓存
.startWith(cachedObservable)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(photos -> {
adapter.setData(photos);
adapter.notifyDataSetChanged();
});

调用 startWith 操作符后，会生成一个新的 Observable，新的 Observable 会首先发射传入的 Observable 包含的元素，而后才会发射原来的 Observable 包含的元素。例如 Observable A 包含 a1, a2 两个元素， Observable B 包含 b1, b2 两个元素，那么 b.startWith(a) 返回的新 Observable 发射序列顺序为： a1, a2, b1, b2。—— 参考资料：StartWith

在上面的例子中，我们连接了网络请求和读取缓存这两个 Observable，原先需要分别处理结果的两个异步任务，我们现在把它们结合成了一个，指定了一个观察者就满足了需求。这个观察者会被回调 2 次，第一次是来自缓存的结果，第二次是来自网络的结果，体现在界面上就是列表刷新了两次。

这里引发了我们的思考，原先 Callback 的写法，如果我们有 n 个异步任务，我们就需要指定 n 个回调；而如果在 n 个异步任务都已经被封装成 Observable 的情况下，我们就可以对 Observable 进行分类、组合、变换，经过这样的处理以后，我们的观察者的数量就会减少，而且职责会变的简单而直接，只需要对它所关心的数据类型做出响应，而不需要关心数据从何而来，经历过怎样的变化。

我们再进一步，上面的例子再加一个需求：如果从网络请求回来的数据和缓存中提前响应的数据一致，就不需要再刷新一次了。也就是说，如果缓存数据和网络数据一致，那缓存数据刷新一次列表以后，网络数据不需要再去刷新一次列表了。

我们考虑一下，如果我们使用传统 Callback 的形式，指定了两个 Callback 去处理这个需求，为了保证第二次网络请求回来的相同数据不刷新，我们势必需要在两个 Callback 之外，定义一个变量来保存缓存数据，然后在网络请求的回调内，比较两个值，来决定是否需要刷新界面。

但如果我们用 RxJava 如何来实现这个需求，该如何写呢：

networkApi.getAllPhotos()
.doOnNext(photos ->
cache.edit(“getAllPhotos”)
.set(VALUE_INDEX, new Gson().toJson(photos))
.commit()
)
.startWith(cachedObservable)
// 保证不会出现相同数据
.distinctUntilChanged()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(photos -> {
adapter.setData(photos);
adapter.notifyDataSetChanged();
});

distinctUntilChanged 操作符用来确保 Observable 发射的元素里，相邻的两个元素必须是不相等的。 参考资料：Distinct

与原先的写法相比，只多了一行 .distinctUntilChanged() ( 我们假设用于比较两个对象是否相等的 equals 方法已经实现 )，就可以满足，在网络数据和缓存数据一致的情况下，观察者只回调一次。

我们比较一下使用 Callback 的写法和使用 Observable 进行组装的写法，可以发现，使用 Callback 的写法，经常会由于需求的变化，导致 Callback 内部的逻辑发生变动，而使用 Observable 的写法，观察者的核心逻辑则较为稳定，很少发生变化（本例中为刷新列表）。Observable 通过内置的操作符对自身发射的元素在空间维度上重新组织，或者与其他的 Observable 一起在空间维度上进行重新组织，使得观察者的逻辑简单而直接，不需要关心数据从何而来，从而使观察者的逻辑较为稳定。

一个复杂的例子

情景：实现一个具有多种类型的 RecyclerView，如图所示：

假设列表中有 3 种类型的数据，这 3 种类型共同填充了一个 RecyclerView，简单起见，我们定义 Retrofit 接口如下：

public interface NetworkApi {
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeA();
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeB();
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeC();
}

到目前为止，情况还是简单的, 我只要维护 3 个 RecyclerView 并分别各自更新即可。但是我们现在接到新加需求，这 3 种类型的数据在列表中出现的顺序是可配置的，而且 3 种类型数据不一定全部需要展示，也就是说可能展示 3 种，也可能只展示其中 2 种。我们定义与之对应的接口：

public interface NetworkApi {
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeA();
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeB();
@GET(“/path/to/api”)
Observable<List> getItemListOfTypeC();
// 需要展示的数据顺序
@GET(“/path/to/api”)
Observable<List> getColumns();
}

新加的 getColumns 接口，返回的数据形如：

• ["a", "b", "c"]
• ["b", "a"]
• ["b", "c"]

首先考虑使用普通的 Callback 形式如何来实现这个需求。由于 3 种数据现在顺序可变，数量也无法确定，如果还是考虑由多个 RecyclerView 来维护的话需要在布局中调用 addView, removeView 来添加移除 RecyclerView，这样的话性能上不够好，我们考虑把所有数据填充到一个 RecyclerView 中，不同类型的数据通过不同 ItemType 进行区分。下面的代码中我依然使用了 Observable ，只是我仅仅把它当成普通的 Callback 功能使用：

private NetworkApi networkApi = …
// 不同类型数据出现的顺序
private List resultTypes;
// 这些类型对应的数据的集合
private LinkedList<List<? extends Item>> responseList;

public void refresh() {
networkApi.getColumns().subscribe(columns -> {
// 保存配置的栏目顺序
resultTypes = columns;
responseList = new LinkedList<>(Collections.nCopies(columns.size(), new ArrayList<>()));
for (String type : columns) {
switch (type) {
case “a”:
networkApi.getItemListOfTypeA().subscribe(data -> onOk(“a”, data));
break;
case “b”:
networkApi.getItemListOfTypeB().subscribe(data -> onOk(“b”, data));
break;
case “c”:
networkApi.getItemListOfTypeC().subscribe(data -> onOk(“c”, data));
break;
}
}
});
}

private void onOk(String type, List<? extends Item> response) {
// 按配置的顺序，更新对应位置上的数据
responseList.set(resultTypes.indexOf(type), response);
// 把当前已返回的数据填充到一个 List 中
List data = new ArrayList<>();
for (List<? extends Item> itemList: responseList) {
data.addAll(itemList);
}
// 更新列表
adapter.setData(data);
adapter.notifyDataSetChanged();
}

上面的代码，为了避免 Callback Hell 出现，我已经提前把 onOk 提到了外部层次，使代码便于从上往下阅读。但是不知道你有没有和我相同的感觉，就是类似这样的代码总给人一种不是很 “内聚” 的感觉，就是为了把 Callback 展平，导致一些中间变量被暴露到了外层空间。

带着这个问题，我们先分析一下数据流动：

1. refresh 方法发起第一次请求，得到需要被展示的 n 种数据的类型以及顺序。
2. 根据第一次请求的结果，发起 n 次请求，分别得到每种数据的结果。
3. onOk 方法作为观察者, 会被回调 n 次，按照第一个接口里返回的顺序正确的汇总 2 中每个数据接口返回的结果，并且通知界面更新。

有点像写作文一样，这是一种 总——分——总 的结构。

Observable 在空间维度重新组织事件

接下来我们使用 RxJava 来实现这个需求，我们会用到 RxJava 的一些操作符，来对 Observable 进行重新组织：

NetworkApi networkApi = …

networkApi.getColumns()
.map(types -> {
List<Observable<? extends List<? extends Item>>> requestObservableList = new ArrayList<>();
for (String type : types) {
switch (type) {
case “a”:
requestObservableList.add(
networkApi.getItemListOfTypeA().startWith(new ArrayList())
);
break;
case “b”:
requestObservableList.add(
networkApi.getItemListOfTypeB().startWith(new ArrayList())
);
break;
case “c”:
requestObservableList.add(
networkApi.getItemListOfTypeC().startWith(new ArrayList())
);
break;
}
}
return requestObservableList;
})
.flatMap(requestObservables -> Observable.combineLatest(requestObservables, objects -> {
List items = new ArrayList<>();
for (Object response : objects) {
items.addAll((List<? extends Item>) response);
}
return items;
}))
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(data -> {
adapter.setData(data);
adapter.notifyDataSetChanged();
});

我们一步一步分析 RxJava 处理的具体步骤。首先是第一步，获取需要展示的栏目列表，这是最简单的，networkApi.getColumns() 这个方法返回是一个只发射一个元素的 Observable，这个元素即为展示的栏目列表，为了方便后续讨论，假设栏目的顺序为 ["a", "b", "c"], 如下图所示：

接下来的操作符是 map 操作符，原来的 Observable 进行了变换，变成了一个新的 Observable，新的 Observable 还是只发射一个元素，这个元素的类型还是 List ，只不过 List 内部的数据类型从原先的字符串（代表数据类型）变成了 Observable。Observable 发射的元素还可以是 “Observable 的 List ” 吗？是的，没有什么不可以 : )

map 操作符负责把一个 Observable 里发射的元素全部进行转换，生成一个发射新的元素的 Observable，元素的种类会发生改变，但是发射的元素的数量不会发生改变。 参考资料：Map

这个操作，在业务上的含义是，根据上一步取回的栏目列表，即 ["a", "b", "c"]，根据不同的数据类型，分别发起请求去获取对应栏目的数据列表，例如栏目类型是 a 的话，就对应发起 networkApi.getItemListOfTypeA() 请求。这里有一点值得注意，就是每一个具体的请求后面都跟了一个 .startWith(new ArrayList<>())，也就是说每个具体请求栏目内容的 Observable 在返回真正的数据 List 之前都会返回一个空的 List ，这里这么处理的原因我们会在下一步中解释。

接下来这一步可能是最难理解的一步了，map 操作之后，紧接着是 flatMap 操作符，而 flatMap 操作符传入的 lambda 表达式内部，又调用了 Observable.combineLatest 操作符，我们先从里面的 combineLatest 操作符开始讲起，请看下图：

combineLatest 操作符的第一个参数 requestObservables，它的类型是 Observable 的 List，它就是上一步中 map 操作符进行变换之后，新的 Observable 发射的数据，即由

• networkApi.getItemListOfTypeA().startWith(...)
• networkApi.getItemListOfTypeB().startWith(...)
• networkApi.getItemListOfTypeC().startWith(...)

3 个 Observable 组成的 List。

combineLatest 操作符的第二个参数是个 lambda 表达式，这个 lambda 表达式的参数类型是 Object[]，这个数组的长度等于 requestObservables 的长度，Object[] 数组中每个元素即为 requestObservables 中每个 Observable 发射的元素，即：

• Object[0] 对应 requestObservables[0] 发射的元素
  自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

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

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

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

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

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后，面试前该准备哪些资源复习？

其实客户端开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

这里再分享一下我面试期间的复习路线：（以下体系的复习资料是我从各路大佬收集整理好的）

《Android开发七大模块核心知识笔记》

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

历时半年，我们整理了这份市面上最全面的安卓面试题解析大全
包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！