Ajax无刷新分页，已经是一个大家比较熟悉的事物了，大概就是web前端页面上有一个js的方法，通过Ajax去请求服务器端的分页数据接口，拿到数据后再在页面上创建html结构，展现给用户，类似于下面这样：

<script type=”text/javascript”>
function getPage(pageIndex){
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
function callback(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}
</script>

其中，RemoteInterface.cgi是一个服务器端的接口。我们这里限于篇幅，涉及的实例代码可能都不是完整的，只为了把意思表达明白。

UI上，可能会有各种款式的分页控件，大家也都比较熟悉，比如：

但无非都是用户点击控件触发这里的getPage(pageIndex)方法，这个getPage方法可能不是那么简单。

如果按照代码片段1的写法，我们可以想象，用户每次点击翻页的时候，都会请求一次RemoteInterface.cgi，在忽略数据可能有更新的情况下，除了第一次，后面每次getPage(1) 、getPage(2)、getPage(3)等等所触发的远程接口请求以及在网络上往返的数据流量，其实都是重复的、不必要的。每页第一次请求的时候都可以把这些数据以某种形式缓存在页面上，用户如果有兴趣回头来看之前翻过的页，getPage方法应该先检查本地缓存当中是否包含该页数据，如果有，则直接重新展现给用户，而不是去调用远程接口。按照这个想法，我们可以把代码片段1修改一下，如下：

<script type=”text/javascript”>
var pageDatalist={};
function getPage(pageIndex){
if(pageDatalist[pageIndex]){ //如果本地的数据列表中包含当前请求页码的数据
showPage(pageDatalist[pageIndex])//直接展现当前数据
}
else
{
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
}
function callback(pageIndex,datalist){
pageDatalist[pageIndex]= datalist; //缓存数据
showPage(datalist);//展现数据
}
function showPage(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}

</script>

这样做一来节约网络请求往返的时间，更重要的是节约宝贵的网络流量和减轻接口服务器的负担。在低网速环境下或者接口服务器运行压力已经比较大的情况下，这种必要的改进更能显现明显的优化效果。大名鼎鼎的yahoo 34条，第一条就是尽量减少HTTP请求次数。Ajax的异步请求，毫无疑问也是在http请求的范畴内。访问量小的web应用或许感觉没有必要，但是想象一下，如果有一个这样的页面：每天访问量1000万次，用户平均翻5页，其中有一页为重复查看。那么这样一个页面，按照代码片段1的写法，平均每天将触发5000万次的数据请求，而按照代码片段2的写法，则平均每天至少可减少1000万次请求。如果每次请求的数据量是20kb，则可以节约1000万*20kb=200,000,000kb 约合190G的网络流量。这样看节约的资源是相当可观的。

如果要继续深究的话，代码片段2当中数据缓存方法还值得讨论一下。我们前面假定可以忽略分页数据的时效性，但实际应用里面时效性却是个不能回避的问题。缓存毫无疑问会导致时效性的降低，真正的缓存方案应该还要依赖对应用时效性要求的分析和取舍。

对于一般不是特别强调时效性的内容，页面上的缓存应该还是可以接受的，一来用户不会一直停留在一个页面上，页面之间有跳转造成重新加载时，可以获得更新后的数据。另外如果用户有刷新页面的习惯的话，当他特别想看列表是否有数据更新的时候，可以选择刷新页面。如果追求完美的话，还可以考虑设定一个时间范围，比如5分钟。如果用户一直停留在当前页面超过5分钟，那么5分钟内他的翻页都是先读取页面上的缓存，5分钟以后的翻页才再次请求服务器的数据。

有些情况，如果我们可以预知数据的更新频率，比如多少天才可能会有一次数据更新，甚至可以考虑使用本地存储，隔一定时间才触发一次对服务器数据的请求，这样对请求数和流量的节约就更加彻底了。当然最终什么样的缓存方法适用，归根结底还取决于产品对时效性的要求，但原则还是能节约的请求和流量，尽量节约，对于访问量超大的页面尤其如此。

对于时效性要求高的一类数据，缓存就完全不适用么?当然不是的，只不过整体的思路还得再变一变。一般所谓变化，可能主要是列表当中的数据有增、减或者改动，但是绝大多数的数据还是保持不变的。大多数情况下，前面讲的设定在一段时间范围内做缓存还是适用的。

如果有接近于要求实时更新数据的需求，大家可能很容易想到使用定时器的方法，比如每20秒执行一次getPage(pageIndex)方法并重绘列表。但大家只要联想到前面1000万次页面访问的假设，就会发现这无疑是一件超级恐怖的事情，按照这种访问量和重试的频率，服务器压力山大呀。关于这种情况怎么处理，我想请大家去看一看Gmail、163邮箱和新浪邮箱等对邮件列表页的处理方式。它们几乎同时满足了我们之前的假设：超级大的日访问量，对数据要求实时更新等。用网络抓包工具分析一下不难发现，它们在用户重复请求同一个页码的数据时，都不会向服务器发出请求。为了保证有消息更新时能够及时通知用户并且更新邮件列表，可以使用一个定时、重复进行的异步请求，但是这个请求只是做一个状态查询，而不是刷新列表。只有获取到有消息更新的状态时才会发起请求去获取更新的数据，或者状态查询的接口在发现有更新时会直接把更新的数据返回。事实上，163邮箱这个定时的状态查询，间隔时间都是设的比较长的，大概两分钟一次，新浪邮箱这个时间间隔更长一些，大概5分钟一次，可以了解它们都在尽力减少请求数量。但是这种处理方式，可能就不是仅前端单方面就能做的，实现方案需要和后台接口整体考虑才行。

现在我们再回过头来看一下代码片段2当中的数据缓存方法。现在不再讨论请求数量和流量的节约，我们来看一下前端的实现上还有没有什么值得深究一下的。按照代码片段2示意的处理方式，原始数据被储存起来，当再次被调用时，showPage(datalist)需要再次根据数据去重建html结构展现给用户，但是之前这个创建结构的过程我们是有做过的，是不是可以考虑在第一次创建结构的时候，直接把这个结构存起来呢?这样可以减少js重复的计算，特别当结构比较复杂时更值得考虑。再想一下，这个结构之前在页面上创建过了，翻页的时候销毁并再次创建新的结构，也是耗费资源的，能不能第一次创建好了之后，翻页的时候不销毁，只是通过控制CSS样式给它隐藏起来，重复翻页的时候也只是在这些创建好的结构之间控制彼此显示或者隐藏?

最后，这里讨论的方法，不一定适用所有情景，但或者会有些许启发，可以在适当的时候尝试其中一二。同时思想如果发散开来，或者还不仅仅可以运用在无刷新分页。这里抛砖引玉，大家一起探讨。