Paging 3：从口诛笔伐到真香定律

2024-02-02 14:29:29

在 Android 11 问世之际，Jetpack 家族也迎来了新成员的加入。我曾郑重承诺，将针对 App Startup、Hilt、Paging 3 这三大新人，逐一撰写深度解析文章。而今天，我们就把目光聚焦在备受争议的 Paging 3 上。

Paging 3 初入江湖，便引来阵阵吐槽。然而，随着深入探索，我发现这款新秀并非浪得虚名，反而蕴含着令人惊艳的真香定律。

Paging 3 的前世今生

Paging 的前世可以追溯到 RecyclerView 的 AdapterDataObserver。这个古老的观察者模式，负责监听数据集的改变，并及时通知 RecyclerView 进行更新。随着 Android 生态的蓬勃发展，这一监听机制暴露出了越来越多的弊端：

监听过程过于繁琐，导致性能开销巨大。
缺乏对并行加载的支持，难以满足日益增长的数据需求。
难以处理多类型数据，给代码的可维护性带来挑战。

针对这些痛点，Paging 1 横空出世，它引入了一种全新的分页加载机制，极大地优化了 RecyclerView 的数据加载体验。然而，Paging 1 也有着自身的局限性：

数据源必须是分页形式，这给数据获取带来了限制。
难以处理多类型数据，需要开发者手动进行适配。
缺乏对并行加载的支持，制约了大数据量的加载效率。

而 Paging 3，正是为了解决 Paging 1 的这些不足而诞生的。它在保留 Paging 1 优点的基础上，进行了全面的革新：

引入了新的数据源抽象，支持多种数据源类型，包括分页和非分页数据源。
增强了对多类型数据的支持，简化了代码实现。
引入了并行加载机制，大幅提升了大数据量的加载效率。

Paging 3 的核心思想

Paging 3 的核心思想在于，将数据加载过程拆分为两个独立的阶段：

数据获取阶段： 负责从数据源获取数据，并将其封装成一个个 Page 对象。
数据展示阶段： 负责将 Page 对象中的数据加载到 RecyclerView 中。

这种分离的设计，带来了以下优势：

解耦了数据获取和数据展示过程，提高了代码的可维护性。
支持多种数据源类型，增强了系统的灵活性。
并行加载机制，极大地提升了数据加载效率。

Paging 3 的实战应用

接下来，我们通过一个实战案例，来深入了解 Paging 3 的使用方式。

首先，我们需要创建一个 PagingSource，它负责从数据源获取数据：

class MyPagingSource : PagingSource<Int, Item>() {
    override suspend fun load(params: LoadParams<Int, Item>): LoadResult<Int, Item> {
        // 从数据源获取数据
        val data = ...
        // 创建 Page 对象
        return LoadResult.Page(data, prevKey, nextKey)
    }
}

然后，我们创建一个 PagingDataAdapter，它负责将 Page 对象中的数据加载到 RecyclerView 中：

class MyPagingDataAdapter : PagingDataAdapter<Item, MyViewHolder>(DIFF_CALLBACK) {
    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        // 将数据绑定到 ViewHolder
        val item = getItem(position)
        ...
    }
}

最后，我们在 Activity 中使用 PagingDataAdapter 创建 RecyclerView：

val pagingDataAdapter = MyPagingDataAdapter()
recyclerView.adapter = pagingDataAdapter

// 创建 PagingSource
val pagingSource = MyPagingSource()

// 创建 PagingData
val pagingData = Pager(config, pagingSource).liveData

// 观察 PagingData，更新 RecyclerView
pagingData.observe(this, Observer {
    pagingDataAdapter.submitData(lifecycle, it)
})