List 分页加载数据控制机制-白红宇

分页加载是一种应用很广泛的数据展示控制机制，相信绝大多数开发者对于这一套机制都非常熟悉。这篇文章的主要目的结合实际的使用场景，对以往在开发中遇到一些概念进行梳理，归纳的同时加深理解，也希望能帮助更多刚刚接触到开发的同学。

本篇文章不聊怎么具体实现分页加载，因为现在太多成熟的方案，直接借助第三方的开源库可以减少很多细节的考虑，重复的造轮子是没有意义的。我们只需要从基本概念上切入，考虑实际场景的需求，针对一些主要问题进行分化，思考基本的解决方案是如何构建的即可，下面我们来一同进行思考。

适合分页加载的场景

要实现分页加载这套机制，在不同终端上的实现可以说是：基本原理相同，只是展示时处理起来有所差异而已。

在前端网页界面中，通常都是点击跳转后到下一页查看内容，一般都是直接提供了可点击的页码进行跳转，属于基本的分页式。而在移动设备 App 上，交互上主要靠手势的滑动控制，所以基本都是上滑时分页加载更多内容，可以说属于段页式。

对于移动终端上采用了列表形式（ ListView 等等）展示内容时，在数据量较大的情况下，分页加载具有下面几个特点：

减少初始加载的耗时（网络加载、数据解析、数据填充等）

减小缓存数据时的内存消耗

提升数据的实时性（一次请求缓存的数据，可能会存在实效性问题）

降低单次网络请求失败的概率（弱网环境下，数据量越大越容易失败）

减少一些不必要流量消耗（用户通常不会一次浏览特别多的数据）

可以提升用户在交互上的体验（上滑加载更多）

在实际场景，如果需要对上述情况需求的，可以考虑一下进行分页加载。下面以在 Android 端实现 List 分页加载为例来梳理一些概念

分页加载的数据请求行为

这里需要先明确两个概念：界面上每页实际展示的数量和控制请求时每页加载的数量。一般来说考虑到多设备适配，请求时每页加载的数量要大于每页实际展示的数量。

通常对于分页加载的数据请求行为主要有下面三个：

初始化加载数据（首次启动界面时加载数据）

下拉刷新数据（刷新当前页面的数据）

初始化的时候数据作为在创建界面时展示的内容，所以需要在保证在基础数据完备的情况下，考虑如何更快完成 loading 过程。这里有一个理念就是先保证可用性再考虑锦上添花的事情

通常对于实时性要求不高的应用，可以考虑读取预先缓存的历史数据作为初始化时的填充内容，界面加载完成后再主动请求进行刷新操作去更新界面内容。

在这种情况下，为了能够快速的滑动浏览内容，同时为了避免反复的网络请求，简单的实现可以设置一个 DataSet 作为网络数据请求成功后的内存缓存仓库，当然如果对应用有更高要求的，可以再考虑做数据持久化。这样就可以引出下面两种方案来设计。

方案一：缓存容器控制

原则就是：每次都是先读取当前已经缓存在容器中的数据，而从网络获取的数据是为了更新容器的数据，在更新到显示界面。

该方案基于前面提到的使用一个 DataSet 作为数据请求成功后的内存缓存仓库，在此基础上，界面获取的数据可以从这个 DataSet 中读取，只需要一次请求缓存较多的数据，不需要每次从网络读取数据。

只有当数据需要刷新或者 DataSet 数据展示量到达一个设定的阀值时，才开始从网络请求获取数据对 DataSet 容器进行更新，而关于数据排重可以根据每条 item 的唯一 ID 完成。

类似图片缓存控制一样，所以考虑做三级缓存也是可以的。

方案二：实时分页加载

这个方案的原则是：每次请求按需加载，加载更多时进行实时数据获取。

实际处理起来还是会有一些问题，比如刷新时如何控制新增数据的填充，加载更多时如何控制数据变化导致的数据重复添加。为解决这些问题需要考虑下面几个因素：

每次请求的数据量（每页的数据量）；

当前数据展示总量（list 中已经加载的量）；

服务端数据总量；

服务端总页数（按照当前每次请求数计算）；

初始化加载数据时 初始化时，每次像服务器请求最新的第一页数据展示到 list，请求失败展示 No Content 页面（可手动刷新），并记录上面描述的几个数值。

下拉刷新数据 对比当前请求回来获取到的服务端数据总量和上次请求成功时保存服务端数据总量，两者的差值是否大于当前请求一页的数据量，如果是则直接替换原来的所有数据，不是的话只要把新增的数据 add 到 list 的 header 即可，注意数据排重。

上拉加载更多

获取上次请求时保存的页码数的下一页的数据添加到 list 的 footer 即可。

解决下拉加载更多时，服务端数据变化导致数据重复的解决方法有三种：

1、使用缓存：

可以定时的把n页缓存到数据库中，这样获取前面n页的时候就不会有重复的问题了，但是后面的分页内容还是无法保证不重复。

2、使用id作为限定进行分页：

客户端记录当前分页的最后一条记录的id，然后在请求下一页的时候，从这个id开始算起进行获取一页大小的内容，比如分页大小为20，按照id倒序获取列表内容：　　select * from tablename where id 　　优点：这种方式可以确保不会获取到重复的数据；　　缺点：需要调整服务器端和客户端的分页方法，通过当前记录id和pageSize去请求服务器端。并且如果按照其他字段而不是id进行的话要确保该字段不会被修改，并且不会有重复，考虑到性能，最好加上索引，推荐使用整型字段：　　select * from tablename where 排序字段<:排序字段当前记录值 order="" by="" desc="" limit="" 0="" 20="" span=""> 　　另外，如果需要加列表缓存，只能按照当前页的最后一条记录的ID作为key的标示，这样缓存需要的存储空间需要很多，如果列表添加数据很快，用户访问第一页的时候，总是会获取到新的数据，这样会不断的读数据库，然后写缓存，缓存利用率不高。（而类似于Hibernate的列表缓存，都是在数据表有增删改操作的时候，让列表缓存失效的，我猜也是出于数据库数据有改动的情况下缓存命中率不高，所以让列表缓存失效的，以便节省内存空间。）

3、客户端排除：

通过在客户端中保存已加载记录的id，进行数据去重，如果被去重的数据比较多，则可以考虑在请求下一页的数据。　　优点：客户端记录已经加载的数据，再次加载的时候过滤掉已有的数据。这种方法能确保不会出现重复的数据，并且不改动服务器端的原有逻辑；　　缺点：当列表数据增加很快的情况下，比如日志记录表，获取下一页的数据会有很多的重复记录，不适合这种情况，适用于列表数据添加不是很频繁的情况。　　即使是用到了缓存，当缓存时间比较长，或者新增数据比较快时，在缓存失效以后，重新获取分页数据的时候也会有大量的重复内容。