App分页探讨

作为一名App开发者，数据分页是很常见的需求，但在实现过程中多多少少都会存在一些问题，遇到次数多了，我就想，别人是怎么做的？有没有完美的分页方式？在研究了一些资料后，对分页有了更全面的认识。基于不同的场景，做法各不相同，各有优点和缺点，不存在完美的分页。

先从交互设计的角度来看，在实现时首先要确定采取哪种方式，主要是Web分页和流式分页的区别：

在实际生产中往往采用折中的方式，比如自动加载几次后让用户手动点击“更多”继续加载，或者在信息流中间增加用于定位的页码；

再从开发的角度来看，可以分为前端分页与后端分页，这个确定主要工作由哪边来做。

前端分页不多谈，因为实现比较直接，一次性拉取所有数据，然后前端控制数据的展现量。这里着重探讨后端分页。上文已经探讨了交互分类的区别，第一种传统的Web式分页，是Web开发中常用的分页方式，实现上是Web分页接口，通过页码进行分页，一般来说，就是根据pageIndex和pageSize来进行分页。第二种流式分页，相对于Web来说，是因为App的交互方式，下拉刷新，向上滚动加载，一般并没有Web上显式的页码，在Web上清晰的页码，在App上往往是不可见的。这种方式为流式分页。流式是UI交互的分类，实现起来可以多种多样，可以采用Web式分页接口来实现。

如果流式分页上采用Web分页接口会有什么问题呢？

那么，如何解决Web分页的这些问题？

以上为研究网络上一些资料后的总结，那么，看起来可行的解决方法就是游标式分页，当分页数据需要增删改时该如何处理？

到目前为止，看起来都不错，暂不考虑多个客户端同一个账号做不同修改的同步。让我们更深一步，增删改会对原有其它数据产生影响时该如何处理？当然，全部重新拉取不少不可用，只是十分粗暴。

再更进一步，增删改会对原有数据的排序产生影响，这种情况出现在数据为多层时，例如数据按某个属性分组，增删改某个数据会对整个分组的排序产生影响，这时该如何处理？貌似到这里开发会有强烈的冲动全部重新拉取，不过如果多做一点，也可以避免。

web开发中常用的分页方式，根据页码进行分页。暂且称为 Web式分页

根据页码 pageIndex 和分页大小 pageSize 进行分页。

这种分页方式，在web中使用没有什么太大问题，但是在App分页中能否套用这种分页方式呢？

App上的分页方式从表现上看，基本都是上拉加载更多形式的流式分页。如果后台接口仍然按照Web式分页方式进行设计，会有如下问题：

a、数据重复

b、数据缺失

c、offset过大时查询效率低

MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。

由此可见，传统Web式分页接口并不适合App分页。

3、App流式分页服务端设计

a、cursor游标式分页

优点：

1)、能够避免数据重复/遗漏

2)、limit性能不会cursor数值大小影响，性能稳定

缺点：

1)、适用于只是按照时间追加的方式的简单排序

b、按照时间分片缓存

非全量数据，只是部分热门数据，因为数据变化太快，可以基于时间段生成多个缓存。对于数据可以按时间段（5分钟）生成一个缓存分片。

具体流程如下：

此处的timestamp值，请求第1页数据时，timestamp传0，服务端检查timestamp<=0，就将当前系统时间赋值给timestamp返回，请求第2，3，...n页数据时，将系统返回的timestamp传入。

缓存的key是根据timestamp进行计算的，比如5分钟一个分片，key=list_201605231700。

应用场景

比如首页热门，只是一些热门文章，排序有一定的复杂性，且相对容易变动。

目前专题中列表排序是按照点赞数排序的，分页请求

出现了重复的数据，是因为该排序是实时数据，且没有游标，无法感知前面加载的数据。

c、id列表一次性下发给App

1、请求第一页数据之前先缓存所有id列表

2、请求每页数据时，只需带入相关的id列表参数

这种方式适用于id列表不会很大（数百条数据）的业务场景，例如腾讯新闻。

首先第一个、不建议把一个频繁更新的字段作为查询条件

然后解决可以用JS在页面获取一个时间戳，因为下拉分页、页面是不刷新的，所以时间戳的值是不变的，然后传递到后台，where条件增加update_time<页面传递过来的时间戳就可以排除掉最新修改的数据

---