概述

互联网上有海量的信息，如何展示这些信息？主流的做法是分页展示，如下是一个典型的页面

传统分页界面

值得研究的是页面底部的导航条，这个导航条的信息如下

每页显示 25 条记录当前是第 1 页一共有 10 页一共有 243 条记录可以从第一页直接跳转到 第 2，3，10 页

可以说这是最传统也最流行的分页显示样式，所以当我们需要提供分页显示的后台服务时，自然而然的就模仿起来，例如下面的一个接口规范

youku 节目视频列表接口返回

注意高亮的几行

pz:1：每页显示 1 行数据pg:1：当前第 1 页total:30：共有 30 条记录移动设备分页体验

先看看京东的商品展示页

京东商品展示

再看下网易新闻的评论页

网易新闻评论

移动设备分页与传统分页差异

在移动设备上，交互方式与电脑浏览器完全不同，因此分页展示也有了极大的差异

移动设备通过上滑或下拉来加载数据，传统的电脑浏览器通过分页导航条来切换页面移动设备上滑或下拉一定是加载新数据吗？实际上并非如此，所以上滑或下拉并不对应电脑浏览器的切换页面移动设备上不需要显示总页数，用户只需要反复上滑屏幕，若没有更多数据，一般是显示一个提示，甚至不做任何提示移动设备无论上滑还是下拉，加载的总是相邻页的数据，不像电脑浏览器那样，可以直接跳转到任意一页，例如从第一页直接跳转到最后一页移动设备每次加载的数据量是多少？估计谁也不清楚，而且用户也不 care；而电脑浏览器每一页（不包括最后一页）的数据量是一样滴，如果某一页的数据比上一页要少，通常表示这是最后一页

由此，可以总结出下面的表格

移动设备和电脑分页差异

针对移动设备做分页不查总记录数，直接到数据库获取某一页的数据由于没有总记录数，客户端不知道当前是否最后一页，所以由服务端告诉客户端不保证一页有多少数据，这样可以在返回数据之前做过滤，增加服务端灵活性，极端情况下，某一页没有任何数据，但是下一页依然有数据why不查总记录数，就避免了一个数据库的 count 查询，在数据量较大时，该查询往往比较耗时有利于多数据源的整合，例如，部分数据从本地数据库查询，部分数据从远程接口获取：这种情况下要知道总记录数就必须调用一次接口，问题是分页的情况下，我这一页的数据可能只需要从数据库返回，这尼玛就是白白调用了一次接口，及其影响性能由于没有查询总记录数，可能导致当前页是最后一页但是刚好数据量和页大小相等，这样会导致客户端多查一页：不过这样对用户体验和服务器压力来说均无影响当需要删除数据时，不需要重建所有页面的缓存，只需要对缓存命中的那一页进行过滤某个产品做了个评论功能，由于对评论进行敏感词和广告过滤比较困难，经常需要手工屏蔽某条评论，而该产品的获取评论接口设计，与客户端约定了每页返回30条评论，若不足30条表示已到最后一页，这也导致该产品无法对评论接口返回的数据做缓存：一旦屏蔽某条评论，刷新缓存非常困难对于商品展示，考虑到商品因库存原因也存在上下架需求且实时性要求较高，这种对缓存过滤的方式还是很方便的结论

移动设备分页和传统分页存在一些体验上的差异，要善于利用这些差异来提升性能和灵活性。遇到问题要多思考，切忌机械的照搬以往的经验。

后记

这个文章来源于以前处理过的一个性能问题

同事做的是资讯类应用，他们搞过一个盖楼的活动：就是在文章的评论里发帖子盖楼，特定楼层的用户能得到奖励

活动效果不错，楼越盖越高，但是后面服务器扛不住了，当时我和他一起想办法解决，解决方案主要是缓存，但遇到一个难题

我们发贴是有敏感词、垃圾信息校验的，但还是有一些用户能突破我们的校验，这时就依赖用户举报和运营手工操作来屏蔽这类垃圾信息

客户端是根据服务端返回的帖子数量来判断当前是否最后一页，这样要屏蔽一个帖子，刷新缓存就非常麻烦，不能仅仅刷新那一页的缓存，而要刷新从那一页开始的所有页面的缓存

如果最初设计接口时不按帖子数量来判断是否最后一页，那么屏蔽特定的帖子就非常容易了