阅读 2226
Jetpack Paging 思想在起点读书的最佳实践

Jetpack Paging 思想在起点读书的最佳实践

前言

在经过前两篇关于 Paging 文章的铺垫以后,现在要和大家分享一下起点读书是如何去应用 Paging 思想的。

为什么是思想?

因为现阶段的 Paging 2是稳定版,但是它难用,而Paging 3虽然比较好用,但我还是不敢将 Alpha 状态的它用于我们的生产环境,并且它和具体的业务结合起来仍有一些障碍。

一、背景

从我进入阅文以后,一直进行起点读书社区业务的迭代,在浏览社区业务标杆 -- 微博的时候,我发现在浏览微博列表的时候,很少会出现滑到数据底部,然后出现 Loading 状态的情况,这应该是对数据进行了预加载。

我们的App滑动到数据底部会出现 Loading 状态:

加载等待

如果使用预加载方案,用户对滑动数据底部去发起网络请求所带来的等待无感知,整个浏览过程也更加流畅,所以,我打算将这项技术应用到我们的社区业务。

二、方案选择

Android Jetpack 中的 Paging 是具有对数据进行预加载功能的,不过前面也提到了,无论是 Paging 2 还是 Paging 3 都有一定的痛点,我们具体分析一下。

Paging 2 的问题还是十分明显的:

  1. API 是真的难用:需要根据不同的场景,采用不同的数据源。
  2. 没有状态管理:意味着数据加载的时候,难以监听请求的状态,更新对应的UI。

Paging 3 解决了上述的问题,但是它仍然处于 Alpha 状态,这使得我不得不放弃它,并且,即使接入了,也会有下面的问题:

  1. RecyclerViewAdapter 冲突:相信大家的业务都封装了自己的 Adapter,无论是采用继承还是直接使用 Paing 3 中的 PagingDataAdapter 都比较困难。
  2. 数据接口问题:定义接口的时候,基本上很少出现只返回数据列表的情况,它还回返回一些其他信息,以我们业务为例,返回帖子列表的时候,还会返回圈子的信息,圈子的信息如何带回来?

基于以上的问题,我们造一了个轮子 QDPaging

三、框架结构

1. 基本功能

在造轮子之前,需要先理清业务的基本诉求,我们的出发点比较简单,就是数据的预加载状态管理

1.1 状态管理

状态管理是用来和UI打交道的,QDPaing 直接借鉴了 Paging 3 的状态结构。

Paging状态管理

分别对应着:

  • Refresh:刷新场景
  • Append:加载更多
  • Prepend:向前加载数据

需要指出的,我使用了两种基础的 Adapter,一种是可对数量容量限制的Adapter,另外一种无需限制,无需限制的场景下是没有 Prepend(向前加载) 的。

1.2 数据预加载

Paging 3 不同的是,因为项目以及一些其他原因,QDPaging 数据加载没有使用协程和 Flow,而是改用 Paging 2 中的线程池 + LiveData

什么时候会触发预加载呢?

  1. 绑定数据的时候:因为在 Adapter中,每次我们需要绑定数据,会调用它的 getItem 方法,满足一定的条件后,就会启动。
  2. loadMore:我们的 RecyclerVIew 都是封装过的, 所以每次滑动到底部时,都会触发一个 loadMore 的方法,这个时候也会触发预加载。
  3. refresh:刷新数据的场景。

整个加载流程是这样的:

加载流程

2. 其他功能

在基本的需求得到满足之后,我又加了一些其他的功能。

2.1 传输列表之外的数据

在列表页定义接口的时候,通常会夹带一些额外的数据,这时,大家可能都会面临这样的抉择,定一个接口还是两个接口:

  • 一个接口:将数据整合在一个接口。
  • 两个接口:列表数据走一个接口,其他信息走一个接口,不过,这加大了工作量,有可能会带来两次刷新,这是视觉同学所不能忍受的。

最后往往都会选择一个接口,不过这种方式对于之前谈到的 Paging 库来说,可能不太友好,不过也有解决方式。

QDPaging 是如何解决这个问题的呢?简单来说,就是做一层数据封装,将数据包括起来,再存放一个类型为 Any 的成员变量,相当于 Java 中的 Object,当你实现自己的数据源的时候,就可以把其他的数据存在这个 Any 的成员变量中,借助 LiveData 传回来。

2.2 数据容量限制

数据容量限制的目的是为了方便控制内存。

为了控制数据容量,QDPaging 使用了双向链表,一页数据就是一个节点,一个节点中记录了当前的数据、页码、前一个节点和后一个节点。

当数据容量超出阈值时,向后加载就抛出前面的节点,向前加载则抛出后面的节点,最终实现数量上的控制。

2.3 减少代码

在结合起点读书固有Ui组件的基础上 ,又增加了一些事件的自动处理:

  • 刷新、加载更多等请求的自动发起。
  • 列表控件对于加载状态(弱网、无网才会显示)、刷新状态和正常数据状态的自动切换。
  • 错误处理。

所以,在一些分页的场景下,我们现在只要实现一个数据源的类,并告诉系统,下一页和上一页的页码分别是什么,最后再绑定一下UI组件,可能的话,还需要处理一下出列表数据外的场景。

总的来说,还是可以减少一些平时必须要写的代码的。

四、结果收益

我们称滑动到数据尾造成的请求加载为有效的加载等待场景,看一下优化前后的效果(因为是gif,所以看着会比较卡):

优化前优化后
改版前改版后

QDPaging 确实可以减少有效的等待加载场景,结果也符合我的预期:

版本人均有效的等待次数(次)
7.9.764.485
7.9.780.015

下降了 99% 的有效等待加载场景,当然,在弱网或者无网的情况下,预加载也无济于事。

除此以外,我们这个预加载库还能够:

  • 有效的减少逻辑代码。
  • 结合 Android Jetpack 中的 LiveDataLifecycle,降低因组件生命周期带来的crash。
  • 限制数据容量达到限制内存的目的。

总结

虽然取得了我们想要的结果,但是接下来仍有很多工作要做:

  1. 分页库虽与起点 UI 组件的耦合性有点高,需要抽离出来。
  2. 目前预加载功能只在起点读书的发现页的关注列表页落地,后续有更多页面推广。

Android Jetpack 作为谷歌推出的最新的 Android 快速开发工具集,有许多值得我们学习的地方。比如我们的预加载库,一大半的功能都是借鉴于 Android Jetpack 中的 Paging 库,并且使用了 Android Jetpack 中的 LiveDataLiftcycle

如果只使用 Android Jetpack 中的某一个库可能会和其他相同作用的库体验没什么不同,但是其中的几个库组合使用的话却是大型真香现场,起点在去年上半年进入敏捷开发的工作模式,如果想要跑得更快,我们未来会引入更多的 Android Jetpack 组件。

广告

如果觉得本文不错,三连 是对我创作最大的鼓励~

我是九心,欢迎关注我的公众号 九心说 接收我的最新文章。
或者添加我的微信 JiuXinDev,拉你进群,与我在 Android 之路上一同进阶~

文章分类
Android