前端优化之使用-setTimeout代替setInterval

setInterval原理

1. 延时一段时间后，将任务push到任务队列中排队执行；
2. 在每次把任务 push 到任务队列前，都要进行一下判断(看上次的任务是否仍在队列中，如果有则不添加，没有则添加)。

多个setInterval进行ajax请求的页面长时间打开会出现页面卡死问题

浏览器的渲染(UI)线程和js线程是互斥的，在执行js耗时操作时，页面渲染会被阻塞掉。当我们执行异步ajax的时候没有问题，但当设置为同步请求时，其他的动作（ajax函数后面的代码，还有渲染线程）都会停止下来。即使DOM操作语句是在发起请求的前一句，这个同步请求也会“迅速”将UI线程阻塞，不给它执行的时间。这就是代码失效的原因。

JS使用setInterval定时器导致前端页面卡死

原因

setinterval不会清除定时器队列，每重复执行1次都会导致定时器叠加，最终卡死你的网页。
其原因与JS引擎线程有关（需深入研究JS引擎线程） ，但是setTimeout是自带清除定时器的。 不断刷新数据重载部分页面，长时间使用会导致线程占用和内存泄漏，导致页面卡顿、卡死的现象.(存疑)

setInterval 缺点

1.setInterval对自己调用的代码是否报错漠不关心。即使调用的代码报错了，它依然会持续的调用下去 。

2.间隔不准。假如定时器里面的代码需要进行大量的计算(耗费时间较长)，或者是 DOM 操作。这样一来，花的时间就比较长，有可能前一次代码还没有执行完，后一次代码就被添加到队列了。也会到时定时器变得不准确

2.setInterval不能确保每次调用都能执行。可能会丢失一些任务。setInterval并不定时。如果它调用的代码执行的时间小于定时的时间，它会跳过调用，这就导致无法按照你需要的执行次数或无法得到你想要的结果。

3.setInterval无视网络延迟。在使用ajax轮询服务器是否有新数据时，必定会有一些人会使用setInterval，然而无论网络状况如何，它都会去一遍又一遍的发送请求，如果网络状况不良，一个请求发出，还没有返回结果，它会坚持不懈的继续发送请求，最后导致的结果就是请求堆积。 

解决方案

1.使用setTimeout + 递归

function fn () {
  setTimeout(() => {
    // 程序主逻辑代码
    // 循环递归调用
    fn();
  }, 1000);
}
fn();

  function fn() {
            console.log(111)
        }   
  let num = 0
  function ceshiTime() {
         let time = setTimeout(() => {
             num++
             window.fn()
             console.log(num)
             clearTimeout(time)
             return ceshiTime()
         }, 1000)
   }
  ceshiTime()

var timer;
function func(args){
  //函数本身的逻辑
  ...
  //函数执行完后，重置定时器
  timer = setTimeout(func, 100, args);
}
timer = setTimeout(func, 100, args);

// 异步请求接口情况
function poll() {
    setTimeout(function() {
        $.get("/path/to/server", function(data, status) {
            console.log(data);
            // 前端接收到后端返回的数据时发起下一次请求
            poll();
        });
    }, 10000);
}复制代码

!!!!最简便
setTimeout(()=>{
  //处理中
    setTimeout(arguments.callee,interval)
},interval)

*扩展

1.arguments 的主要用途是保存函数参数， 但这个对象还有一个名叫 callee 的属性，返回正被执行的 Function 对象，也就是所指定的 Function 对象的正文，这有利于匿名函数的递归或者保证函数的封装性。主要当你的函数名改变时，只用改外面的，不用动里面的名字。。。