Android官方架构组件Paging-Ex_列表状态的响应式管理

列表的状态问题

和市面上其它热门的分页库相比，Paging最大的亮点在于其 将列表分页加载的逻辑作为回调函数封装入 DataSource 中，开发者在配置完成后，无需通过代码手动控制分页的加载，列表会 自动加载 下一页数据并展示。

这种便利意味着开发者不需要自己持有 数据源 ，大多数时候这使得开发流程更加便利，但总有偶然，比如这样一个界面：

这种需求屡见不鲜，其本质是，列表本身展示服务端返回的列表数据之外，还需要 本地控制额外的状态。

什么叫 额外的状态 ? 我们先用简单的一张图展示没有额外状态的情形，这时，列表的所有UI元素都从服务端获取：

现在我们将上文Gif中的点赞效果也通过一张图表示：

读者可能还未认识到两种业务场景之间的差异性：对于列表的初始化来讲，所有UI元素都被服务端返回的数据渲染，每条评论是否已经被点赞，服务端都通过Comment进行了描述。

需要注意的是，在某一刻，用户发现某个评论非常有趣，因此他选择对该评论进行了点赞的操作。

在业务代码中，我们需要向服务端POST一个点赞的请求，服务端返回了一个200的成功码，但问题来了，接下来我们 如何让列表中的那条评论状态发生变化（即点赞的icon由灰色变成绿色高亮，已告知用户点赞成功）？

这就引发了文章最开始的那个问题，当列表的状态发生了变更，如何管理并更新列表？

方案1：再次刷新请求接口

最简单的方案是再次请求API，每当列表状态发生了变更，重新拉取评论列表，服务端返回的最新数据中，该评论自然已经被点赞了（即列表正确进行了更新）。

读者应该清楚，该方案实际并不可行，原因有二：

• 成本太高：某些操作对于用户来说，应该是非常 轻量级 的（比如点赞），他们甚至希望这些操作能够 立即被响应 在UI上 ，而请求API并刷新列表这一个过程太重了，即使不考虑服务器的负担，对于用户来说，UI的刷新需要数秒的等待也是非常糟糕的体验。
• 不符合逻辑：我们更需要注意的是，Paging是一个分页列表，而刷新请求行为对于分页列表来说，是一个不符合产品预期的行为（比如，我的点赞操作是针对第5页的某个评论执行的，产品的设计不可能允许每次点赞都重置为列表的第一页数据，这意味着极度糟糕的用户体验）。

现在我们理解了 每当列表状态发生了变更就刷新接口 并非良策，因为这种通过 远程重新拉取数据源 更新UI的方式成本太高了。

方案2：额外维护一个状态的列表

大概思路是在内存中为RecyclerView维护一个额外的List，用于一一映射对应position的Item状态：

class CommentPagedAdapter(
private val likedList: ArrayList
)

通过在内存中维护这样一个List，的确可以实现需求，但读者需要认识到的是，Paging分页库本身最大的优点便是 随着列表的滚动自动加载分页数据，每次分页的行为开发者并不需要手动配置，并通过调用类似notifyItemRangeInserted()的方法更新UI。

很显然，每当分页数据获取后，开发者依然需要手动维护这个额外状态的List——方案2和选择使用Paging的初衷背道而驰，因此它并非最优先考虑的方案。

库本身设计的问题？

现在问题是，既不能通过 服务端 作为数据源，也不能在 内存中 额外维护一个状态的列表， 读者难免会质疑Paging库本身设计的问题。

我该如何控制列表额外的状态（包括修改、增加或者删除）？

事实上该问题已经在Github的这个 issue 中进行了讨论，Google的工程师的回复是：

从技术的角度而言 ,我们可以创建一个允许部分更改数据源的API，但之后我们需要记录这些改动并在主线程上重新传递给列表。这种方法的问题在于，如果你有一个已停止的RecyclerView（也就是后堆栈），它将不会（也不应该）接收任何更新，因此PagedList将保留这个可能很长的数据列表并重新应用于主线程上的每个观察者。

这使问题变得非常复杂，这就是我们使用单个列表的原因。

显然，Paging考虑到了更多，和市面上 什么都能做 的框架相比，它 敢于收紧开发者API的调用权限，在开发者们发挥更多奇思妙想之前，将其紧紧束缚到了可控制的范围之内，这也是笔者非常推崇Paging的原因之一。

那么我们该如何处理我们的业务？此时引入一个新的角色似乎是一个不错的选择，那就是 持久层（即缓存）。

通过架构解决业务问题

综上所述，对于分页列表的状态管理问题，需要做到的是：

• 1.将一个单独的List交给Paging去进行分页加载并渲染（不应在内存中手动维护一个额外状态的列表）;
• 2.不应该每次都通过重的操作刷新数据源（比如网络请求刷新接口）。

因此，我们需要一个 中间件 进行业务的调度——在需要刷新整个数据源的时候（比如用户的下拉刷新操作），从服务端拉取数据；在不需要繁重的操作时（比如用户针对某个评论进行点赞），仅仅需要针对单个数据源进行简单的修改。

这已经不单单是业务业务的问题，并且涉及到了项目本身的架构，接下来， 持久层 （即本地缓存）闪亮登场。

1.用持久层作为唯一的数据源

Android平台的数据库框架有很多种，本文以官方的架构组件Room为例。

为什么要为项目的架构额外添加一个持久层？事实上，随着项目体系的日益庞大，数据库是终究需要添加进入项目中的，因此，在设计项目的架构之前，提前将数据库的框架配置进来是一个不错的选择——未雨绸缪总不是坏事。

以列表的渲染为例，让我们来看看项目之前的结构：

回到本文，对于Paging来讲，我们并无法直接获取数据源，因此对于列表状态的管理，我们需要额外的角色帮助，那就是本地的持久化缓存。

让我们看看添加了持久层之后的结构：

添加了缓存之后，每当我们尝试初始化一个分页列表，框架会从服务器拉取数据，之后数据被存储到了Room中。

请注意！Paging原生提供了对Room数据库框架的支持，因此它总是可以第一时间响应到数据库中数据的变化，并自动渲染在UI上。

现在，我们将 请求服务器API 和 数据的渲染 两者通过持久层进行了隔离，对于RecyclerView来说，持久层是唯一的数据源，即：

列表只反应了数据库的变更。

现在列表的显示和服务端的请求已经 完全无关 了，读者也许会有这样的疑问——这样做的好处是什么？

2.列表状态的管理

现在我们回到文中最初的问题，如何管理列表的状态？

对于一个拥有复杂状态的分页列表，无论是 服务端 作为数据源，还是在 内存中 额外维护一个状态列表，都不是很好的选择；而现在我们加入了Room，并作为列表唯一的数据源，局势发生了怎样微妙的变化呢？

让我们来看看加入了持久层之后，下拉刷新的逻辑发生了怎样的变化：

• 1.下拉刷新意味着我们需要重置数据，因此我们手动清除了数据库内对应表中的数据；
• 2.当表中数据被清空时，Paging会自动响应到数据的变化，因为没有了数据，所以Paging会自动向服务器请求数据；
• 3.数据返回后，会再次将数据存储到数据库中；
• 4.这时Paging会再次响应到数据库的变化，并将最新的数据渲染到UI上。

看起来逻辑复杂了很多，实际上读者需要明确的是，步骤2、3、4都是我们作为开发者在初始化Paging时就配置好的，因此如果用户需要刷新页面，只需要进行第一步的操作即可，即类似这样的一行代码：

// 刷新操作，仅需清除表内的列表数据
fun swipeRefresh() {
// 运行一个事务
db.runInTransaction {
// 清除列表数据
db.getDao().clearDataList()
}
}

现在我们将整个流程中，Paging自动执行的步骤用紫色标记出来：

瞧，除了我们手动执行的逻辑，所有流程都交给了Paging去 响应式 地执行。

我们总是下意识认为复杂的业务逻辑用过程式的编码更容易实现，Paging用事实证明了并非如此——如果说项目中的某个页面追加了下拉刷新的需求，过程式的编码也许会花费更多的时间，并且代码也许会更分散、啰嗦且易出错。

3.更灵活、且可高度扩展

接下来分析的是，对分页列表点赞这种相对 轻量级的行为 又该如何处理?

答案呼之欲出, 我们依然用熟悉的流程图表示代码的执行步骤：

即使是复杂的状态，在这种模式下也不再是难题：首先，我们将数据库对应表中对应评论的isLike（是否被点赞）设置为true：

// 1.对本地的评论数据点赞
fun likeCommentLocal(comment: Comment) {
// 更新评论
comment.isLike = true
// 将评论更新到数据库中
db.runInTransaction {
db.getDao().updateLikeComment(o)
}
}

与此同时，我们也向服务器请求接口，告知评论被用户点赞：

// 2.对评论点赞
fun likeCommentRemote(commentId: String) {
service.likeComment(commentId)
// …
}

当数据库中数据发生了变更，Paging仍然会响应到数据的更新，并第一时间更新了UI，同时我们也向服务器发起了请求，一个完整的 点赞 操作相关的业务代码实现完毕。

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

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

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

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

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

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

最后笔者收集整理了一份Flutter高级入门进阶资料PDF

以下是资料目录和内容部分截图

里面包括详细的知识点讲解分析，带你一个星期入门Flutter。还有130个进阶学习项目实战视频教程，让你秒变大前端。

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

你一个星期入门Flutter。还有130个进阶学习项目实战视频教程，让你秒变大前端。

[外链图片转存中…(img-e7eiin6B-1713803407021)]

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