requestAnimation -- 动画?

动画???

动画就是间隔一段进行进行一个操作.

一般常用的动画处理模式有早期的定时器: setTimeout , setInterval
后续 css3 带来了一个新的动画过度属性 transition.

对于 transition 能实现动画很好的过度效果,这没有什么可说的.

但是对于 setTimeout , setInterval 来言. 虽然定时了,但可能执行的时机并不准确.

为什么?

这就要提高 JavaScript 的 EventLoop 了.

在浏览器 JavaScript 的执行环境是单线程的.

只有等待主队列同步代码执行完毕了,才会去执行 EventLoop 事件循环里的回调函数(无一例外).

假设现在有这么一样场景.

使用 setInterval , setTimeout 来定时 200ms 执行一段代码.

此时,同步代码有 1000 万行,执行完毕时间要 半分钟.

那么此时,setInterval 和 setTimeout 虽然你设定了 200ms 后就执行,
但由于同步代码数量庞大,执行的优先级又最高.
于是就导致了即使是同步代码运行效率很快,不到半分钟,25秒就可以执行完的话.
那么你的 EventLoop 至少也需要等待25s后才能执行 setInterval 和 setTimeout.

这显然和之前设置的 200ms 差距太远了.

这也就是为什么说,在某些情况下, setInterval 和 setTimeout 会出现执行时机不准的问题.

requestAnimationFrame

显示器是需要刷新的.
浏览器跑在显示里. 也肯定是需要刷新的.

看一段 MDN 的解释:

window.requestAnimationFrame() 告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行
注意：若你想在浏览器下次重绘之前继续更新下一帧动画，那么回调函数自身必须再次调用window.requestAnimationFrame()

浏览器内部元素如果有动画的存在,浏览器是需要刷新的.

每刷新一次就叫做一帧.

如果能有一个时机,在每次刷新下一帧之前,就把动画元素的变化执行完毕.而不是不管时机胡乱的执行,那么动画效果肯定会更流畅.

于是 requestAnimationFrame 函数就应运而生了.

它就是用来更加流畅的处理动画的.(为什么是动画?如果浏览器仅仅展示一片静态的文件,为了节省系统资源,它就可以不刷新了或者降低刷新频率.)

div#box,
    div#request-animation-box {
      width: 100px;
      height: 40px;
      background-color: salmon;
    }
    <div id="box"></div>
  <div id="request-animation-box"></div>

 // 使用定时器的方式,由于存在eventLoop导致代码优先级的问题.会出现定时并不准确的情况.
  let box = document.querySelector('#box'), rbox = document.querySelector('#request-animation-box')
  normalWay()
  function normalWay() {
    let id = setInterval(() => {
      box.style.width = `${++box.clientWidth}px`
      if (box.clientWidth > 300) clearInterval(id)
      console.log(box.style.width)
      }, 17); // 1000ms / 17 = 每分钟 60 fps
  }
  // rWay
  rWay()
  function rWay() {
    rbox.style.width = `${++rbox.clientWidth}px` // 场景内,有物体的变化,必须刷新浏览器
    if (rbox.clientWidth <= 300)
      requestAnimationFrame(rWay) // 因为必须要刷新浏览器,所以会调用 requestAnimationFrame . 
    // requestAimationFrame 的参数是一个函数.
    // 但是只调用一次,它只会在下一帧渲染之前调用.后续帧刷新时,就不会调用.
    // 所以需要不停的调用这个函数才可以.
  }

一句话解释就是:

浏览器说: 我马上要刷新下一帧了,你有啥事情(动画)需要我在刷新下一帧之前做完的吗? 有的话赶紧给我.

我说: 有啊!我需要你在每下一次帧数渲染之前执行 rWay 方法.

浏览器说: 好的.我会让我的小弟去干这个事情.对了,忘了告诉你了,我小弟的名字叫 requestAnimationFrame

---

没有动画呢?

上面都说 requestAnimaitonFrame , 动画,动画,和动画相关.
那我的页面里没有动画逻辑,只有数据逻辑呢?

仅仅 1000 个数字的循环,基本一瞬间就可以完成.

let counter = 1
  function nothingInScreenChanged() {
    ++counter
    console.log(counter)
    if (counter < 1000) { 
      nothingInScreenChanged()
    }
  }
  nothingInScreenChanged()

但是如果数字的循环和 reqeustAnimationFrame 添加上联系呢? 这里并没有我们可以在肉眼看到的变化,仅仅是程序内部的数值发生了改变.

 function nothingInScreenChanged() {
    ++counter
    console.log(counter)
    if (counter < 1000) { // 受制于屏幕刷新率最大 60fps , 数据自增的速度会明显变慢
      requestAnimationFrame(nothingInScreenChanged)
    }
  }
  nothingInScreenChanged()

---

总结:

1. 浏览器的刷新机制是客观存在的.
2. requestAnimationFrame 仅仅只是在浏览器每一次刷新渲染新帧之前的一个切片或者说一个时机.你用或者不用,这个切片都在那里.
3. 它和你是否执行动画效果,还是单纯的业务逻辑代码并没强求.我们可以将任意代码都丢在这个切片里面执行.
4. 有时候,一些业务代码要求的是执行效率,丢在在这个切片里,受制于浏览器刷新性能,反而会拖慢整个流程的运行.

reqeustAnimation 不要一提到,就是动画动画. 它仅仅是一个浏览器在每一帧渲染之间给予我们的一个切片时机.仅此而已.

码云地址