android 定时器 坑,聊一聊定时器里踩的坑

刚开始学习 JavaScript 的时候，生搬硬套的知道了定时器是 JavaScript 中最基础的异步操作，由于 JavaScript 是单线程，如果中间某个任务耗时过长，后面的必须要等待，比如我们浏览网页的时候图片会因为网络原因加载的很慢，为了让我们有更好的用户体验，我们可以把页面骨架先渲染出来，一些耗费资源的东西我们就通过异步来加载，可以通过一个图示来感受一下：

image.png

同步和异步任务分别进入不同的执行"场所"，同步的进入主线程，异步的进入Event Table并注册函数;

当指定的事情完成时，Event Table会将这个函数移入Event Queue;

主线程内的任务执行完毕为空，会去Event Queue读取对应的函数，进入主线程执行;

上述过程会不断重复，也就是常说的Event Loop(事件循环);

最开始接触到异步相关的是 setTimeout 和 setInterval，对于一些轮询的操作很方便，随着接触的深入，了解到事件队列的概念，原来引擎还分为 JavaScript 引擎和定时器引擎，二者的执行时机也是有先后的，即便 delay 设置为0，也是必须得主线程执行完后不用等待可以马上执行，而不是高于主线程的优先级，结合代码看一下：

setTimeout(function() {

console.log('setTimeout')

}, 0)

console.log('我先执行')

// 我先执行

// setTimeout

从上述代码中我们有个直观的体会，就是定时器任务优先级低于主线程任务，另外我们从 MDN 上看到定时器可以传入多个参数，分别是

var timeoutID = scope.setTimeout(function[, delay, param1, param2, ...])

这里传入 function 和 delay 都是很常见的， delay 后面的参数是可选的，一旦定时器到期，它们会作为参数传递给 function；另外这里对于定时器的 id 需要了解一下，timeoutID 是一个定时器的 id，这个值可以传递给 clearTimeout 来取消该定时器，并且 setTimeout 和 setInterval 共用一个编号池，所以你在代码中调用 clearTimeout() 和 clearInterval() 效果相同，但是不建议混用。

setTimeout(function(a, b) {

console.log(a+b)

}, 1000, 1, 2)

使用定时器轮询接口

结合实际的业务场景来说吧，当我们需要对于某个接口做轮询的时候，自然就想到了定时器，最开始对于定时器的理解是 setTimeout 执行一次就结束了，setInterval 可以重复执行，所以轮询的时候理所当然的选择了 setInterval，刚开始效果杠杠滴，可是过了一段时间如果网络波动就会导致定时器不是那么 '准时' ，当时很奇怪，后面查找资料发现这是 setInterval 的一个弊端，它指定的时间是每次执行的间隔，并不包含当前请求消耗的时间，所以当某次请求时间大于指定时间，这个定时器就开始 '不准'了，为了保证两次执行有固定的 delay，通过 setTimeout 来达到想要的效果，看下代码：

function interval(func, wait){

var interv = function(){

func.call(null)

setTimeout(interv, wait)

}

setTimeout(interv, wait)

}

interval(function() {

console.log(123)

// 执行相关操作

}, 1000)

通过上面的方式我们可以平滑的实现接口轮询，以及类似的业务，比如轮播图等。

还有就是了解一下 setTimeout 会出现 this 指向全局的问题，不过现在使用箭头函数就可以很方便避免这种问题了，不然你还得手动将 this 绑定回来，比较麻烦