一、概述
在很久很久以前,加载并展示大量数据就已成为各家应用中必不可少的业务场景,分页加载也就成了必不可少的方案。在现有的Android API中也已存在支持分页加载内容的方案, 比如:
-
CursorAdapter
:它简化了数据库中数据到ListView
中Item的映射, 仅查询需要展示的数据,但是查询的过程是在UI线程中执行。 - SupportV7包中的
AsyncListUtil
支持基于position的数据集分页加载到RecyclerView
中,但不支持不基于position的数据集,而且它强制一个有限数据集中的null项必须展示Placeholder.
针对现有方案所存在的一些问题,Google推出了Android架构组件中的Paging Library, 不过目前还是alpha版本。Paging Library主要由3个部分组成:DataSource
、PagedList
、PagedListAdapter
。
二、Paging Libray介绍
DataSource
, PagedList
, PagedAdapter
三者之间的关系以及加载数据到展示数据的流程如下图所示:
2.1 Datasource
顾名思义,Datasource
是数据源相关的类,其中Key
对应加载数据的条件信息,Value
对应返回结果, 针对不同场景,Paging提供了三种Datasource:
-
PageKeyedDataSource
:适用于目标数据根据页信息请求数据的场景,即Key
字段是页相关的信息。比如请求的数据的参数中包含类似next/previous
的信息。 -
ItemKeyedDataSource
:适用于目标数据的加载依赖特定item的信息, 即Key字段包含的是Item中的信息,比如需要根据第N项的信息加载第N+1项的数据,传参中需要传入第N项的ID时,该场景多出现于论坛类应用评论信息的请求。 -
PositionalDataSource
:适用于目标数据总数固定,通过特定的位置加载数据,这里Key
是Integer类型的位置信息,T
即Value
。 比如从数据库中的1200条开始加在20条数据。
以上三种Datasource都是抽象类, 使用时需实现请求数据的方法。三种Datasource都需要实现loadInitial()
方法, 各自都封装了请求初始化数据的参数类型LoadInitialParams
。 不同的是分页加载数据的方法,PageKeyedDataSource
和ItemKeyedDataSource
比较相似, 需要实现loadBefore()
和loadAfter()
方法,同样对请求参数做了封装,即LoadParams
。PositionalDataSource
需要实现loadRange()
,参数的封装类为LoadRangeParams
。
如果项目中使用Android架构组件中的Room, Room可以创建一个产出PositionalDataSource
的DataSource.Factory
:
@Query("select * from users WHERE age > :age order by name DESC, id ASC")
DataSource.Factory usersOlderThan(int age);
总的来说,Datasource就像是一个抽水泵,而不是真正的水源,它负责从数据源加载数据,可以看成是Paging Library与数据源之间的接口。
2.2 PagedList
如果将Datasource比作抽水泵,那PagedList就像是一个蓄水池,但不仅仅如此。PagedList是List的子类,支持所有List的操作, 除此之外它主要有五个成员:
mMainThreadExecutor
: 一个主线程的Excutor, 用于将结果post到主线程。mBackgroundThreadExecutor
: 后台线程的Excutor.BoundaryCallback
:加载Datasource中的数据加载到边界时的回调.-
Config
: 配置PagedList从Datasource加载数据的方式, 其中包含以下属性:-
pageSize
:设置每页加载的数量 -
prefetchDistance
:预加载的数量 -
initialLoadSizeHint
:初始化数据时加载的数量 -
enablePlaceholders
:当item为null是否使用PlaceHolder展示
-
PagedStorage
: 用于存储加载到的数据,它是真正的蓄水池所在,它包含一个ArrayList
对象- >
mPages
,按页存储数据。
PagedList会从Datasource中加载数据,更准确的说是通过Datasource加载数据, 通过Config的配置,可以设置一次加载的数量以及预加载的数量。 除此之外,PagedList还可以向RecyclerView.Adapter发送更新的信号,驱动UI的刷新。
2.3 PagedListAdapter
PagedListAdapte是RecyclerView.Adapter的实现,用于展示PagedList的数据。它本身实现的更多是Adapter的功能,但是它有一个小伙伴PagedListAdapterHelper
, PagedListAdapterHelper会负责监听PagedList的更新, Item数量的统计等功能。这样当PagedList中新一页的数据加载完成时, PagedAdapte就会发出加载完成的信号,通知RecyclerView刷新,这样就省略了每次loading后手动调一次notifyDataChanged()
.
除此之外,当数据源变动产生新的PagedList,PagedAdapter会在后台线程中比较前后两个PagedList的差异,然后调用notifyItem...()方法更新RecyclerView.这一过程依赖它的另一个小伙伴ListAdapterConfig
, ListAdapterConfig负责主线程和后台线程的调度以及DiffCallback
的管理,DiffCallback
的接口实现中定义比较的规则,比较的工作则是由PagedStorageDiffHelper
来完成。
三、加载数据
使用Paging Library加载数据主要有两种方式,一种是单一数据源的加载(本地数据或网络数据), 另一种是多个数据源的加载(本地数据+网络数据)。
3.1 加载单一数据源的数据
首先我们可以通过LivePagedListBuilder
来创建LiveData
为UI层提供数据。整个流程如下图所示:
如果数据源是DB,当数据发生变化,DB会推送(push)一个新的PagedList(这里会依赖LiveData
的机制). 如果是网络数据,即客户端无法知道数据源的变化,可以通过诸如滑动刷新的方式将调用Datasource的invalidate()
方法来拉去(pull)新的数据。
3.2 加载多个数据源的数据
这种场景一般是先加载本地数据,加载完成后再加载网络数据,比较适合需要本地做缓存的业务。比如IM中的聊天消息,当打开聊天界面时先加载本地数据库中的聊天消息,加载完了再加载网络的离线消息。这中场景的流程如下图所示:
这种场景需要为PagedList设置BoundaryCallback
来监听加载完本地数据的事件,触发加载网络数据,然后入库,此时LiveData
具体使用案例可以参考Google Sample的PagingWithNetworkSample项目。
四、小结
Paging Library作为Android架构组件库的一员,其特点主要还是在其架构思想上。Paging将分页的业务封装为一条完整的流水线,一个Pattern。其中各个组件之间存在联动的关系:
当PagedList创建时会立即从
Datasource
加载数据(触发loadInitial()
),DataSource
加载到数据后会更新PagedList
,PagedList
更新会通知到PagedAdapter
并刷新UI;UI上的展示会触发
PagedAdapter
的getItem()
随即触发PagedList的loadAround()
方法从DataSource
加载周围的数据...
整个过程Paging内部实现了线程的切换,数据的预加载,所有联动的关系都内聚到Paging中,这样使用时只需要关心加载数据的具体实现,并且在用户体验上,将会大大减少等待数据加载的时间和次数。