RxJava 沉思录（二），移动智能终端开发技术第三次作业

最新推荐文章于 2022-09-22 12:31:39 发布

m0_67598458

最新推荐文章于 2022-09-22 12:31:39 发布

阅读量2.3k

点赞数

分类专栏：程序员文章标签： rxjava 缓存 android

本文链接：https://blog.csdn.net/m0_67598458/article/details/123564094

版权

程序员专栏收录该内容

12 篇文章 0 订阅

订阅专栏

本文详细介绍了如何使用RxJava在Android应用中实现网络请求与缓存的无缝结合。通过实例展示了如何将网络请求和读取缓存转化为Observable，利用doOnNext、startWith和distinctUntilChanged等操作符，实现缓存优先加载和避免重复刷新。文章还讨论了如何在需求变化时，保持观察者逻辑的稳定性和代码的可维护性。

摘要由CSDN通过智能技术生成

.subscribe(photos -> {
adapter.setData(photos);
adapter.notifyDataSetChanged();
});

现在新加一个需求，请求当前用户照片列表这个网络请求，需要加入缓存功能（缓存的是网络响应中的图片的URL，图片的 Bitmap 缓存交给专门的图片加载框架，例如 Glide），也就是说，当用户希望展示图片列表时，先去缓存读取用户的照片列表进行加载（如果缓存里有这个接口的上次访问的数据），同时发起网络请求，待网络请求返回之后，更新缓存，同时使用使用最新的返回数据刷新照片列表。如果我们选择使用 JakeWharton 的 DiskLruCache 作为我们的缓存介质，那么上面的代码将变为：

DiskLruCache cache = …
DiskLruCache.Snapshot snapshot = cache.get(“getAllPhotos”);
if (snapshot != null) {
// 读取缓存数据并反序列化
List cachedPhotos = new Gson().fromJson(
snapshot.getString(VALUE_INDEX),
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，如图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ccOnJ5gY-1647533083893)(https://user-gold-cdn.xitu.io/2018/9/5/165a7e27adc8b361?imageView2/0/w/1280/h/960/ignore-error/1)]

假设列表中有 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 种。我们定义与之对应的接口：

新加的 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 展平，导致一些中间变量被暴露到了外层空间。

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

refresh 方法发起第一次请求，得到需要被展示的 n 种数据的类型以及顺序。
根据第一次请求的结果，发起 n 次请求，分别得到每种数据的结果。
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);
}