概念请点这里

现状描述

天猫几乎所有的频道都有 下拉刷新 的逻辑。其中，品牌特卖和焕新在做下拉刷新的时候均使用了一个叫做 bottomloader 的组件。该组件中采用了 throttle 方法对于连续的scroll事件所触发业务逻辑（包含数据加载）的次数进行了稀释，从原生的像素级别的滑动触发，稀释到了间隔几百毫秒触发一次，从而极大的降低了scroll事件对业务逻辑的高频触发，提高了滑动流畅度以及页面性能。

代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var detect = throttle(function(){
  //添加业务逻辑
}, 200);
window.addEventListener('scroll', detect, false);
function throttle(action, delay){
  var self = this;
  var curr = +new Date();
  if (curr - self.last > delay){
    action.apply(this, arguments);
    self.last = curr ;
  }
}

问题发现

这两个频道的测试同学做回归的时候均曾提出，当屏幕被快速滑动到底部时候，下一个Page的资源会经常加载不出来。特别是在 Chrome 模拟器中，通过鼠标拖动可以达到极快的滑动速度时，资源加载不出的情况更是发生频率很高。经排查，原因也很简单，就是由于代码中采用 throttle 方法做了节流。当使用者滑动超快，一次滑动事件的时间低于设定的节流阈值（ 比如 500 毫秒），滑动事件就无法触发具体的业务逻辑，无法加载新数据。

调整方式

目前的修改办法是简单的将阈值改小，降至 100 毫秒，将数据加载不出的可能性降低。但是并不能根本的解决这个问题。因为极端情况下，100 毫秒以内的scroll事件也可以产生。同时，页面性能也会因为阈值小、scroll事件触发业务逻辑频率升高造成页面性能下降。

根本解决

个人倾向于采用 debounce 的方式，为每一个scroll事件触发的业务逻辑设定一个执行的 timeout，并将所有与前一个scroll事件间隔小于该阈值（即 timeout）的scroll事件触发的业务逻辑都进行丢弃，直到上一个事件完成后经过的时间已经超过该阈值。

代码如下：

1
2
3
4
5
6
7
8
9
var timer = null;
window.addEventListener('scroll', function () {
  if (typeof timer === 'number') {
    clearTimeout(timer);
  }
  timer = setTimeout(function () {
    //添加业务逻辑
  },200);
}, false);

如此则有：

  1. 无论用户/测试人员以多快速度滑动页面，一旦到页面底部，滑动事件均会由于页面无新内容而被迫停止。此时，采用了debounce 方式，scroll事件触发的业务逻辑确保能被执行；
  2. 丢弃与前一个scroll事件间隔小于特定阈值的后一个事件的业务逻辑，即就是对scroll事件触发业务逻辑次数进行了稀释，也同样提高了页面效率。

At last,

一个简易的、同时支持 debounce 和 throttle 的 bottomloader 组件: 请戳这里

1
2
3
4
5
6
7
var bl = new BottomLoader(1);
bl.addCallback(function(true){ // debouce
	// your code here...
},{
	diff:300, // 触发距离（距离底部）
	immediately:true
});