前言：好久没翻阅我的gmail邮箱了，午休时就打开看了一下，看到InfoQ推荐的一篇名为“Javascript高性能动画与页面渲染”文章，粗略的看了一下，很赞！讲的很详细，对好些细节讲的都很好，很通俗易懂。so……笔记诞生
1、fps -frame per second 帧
页面是每一帧变化都是系统绘制出来的(GPU或者CPU)。但这种绘制又和PC游戏的绘制不同，它的最高绘制频率受限于显示器的刷新频率(而非显卡)，所以大多数情况下最高的绘制频率只能是每秒60帧(frame per second，以下用fps简称)，对应于显示器的60Hz。
2、60Hz和60fps有什么关系？
没有任何关系。fps代表GPU渲染画面的频率，Hz代表显示器刷新屏幕的频率。一幅静态图片，你可以说这副图片的fps是0帧/秒，但绝对不能说此时屏幕的刷新率是0Hz，也就是说刷新率不随图像内容的变化而变化。游戏也好浏览器也好，我们谈到掉帧，是指GPU渲染画面频率降低。比如跌落到30fps甚至20fps，但因为视觉暂留原理，我们看到的画面仍然是运动和连贯的。
3、为什么setTimeout或者setInterval来控制绘制页面存在问题？
首先，Timer计算延时的精确度不够。延时的计算依靠的是浏览器的内置时钟，而时钟的精确度又取决于时钟更新的频率(Timer resolution)。
IE8及其之前的IE版本更新间隔为15.6毫秒。假设你设定的setTimeout延迟为16.7ms，那么它要更新两个15.6毫秒才会该触发延时。这也意味着无故延迟了 15.6 x 2 - 16.7 = 14.5毫秒。
16.7ms
DELAY: |------------|
CLOCK: |----------|----------|
15.6ms 15.6ms
所以即使你给setTimeout设定的延时为0ms，它也不会立即触发。目前Chrome与IE9+浏览器的更新频率都为4ms(如果你使用的是笔记本电脑，并且在使用电池而非电源的模式下，为了节省资源，浏览器会将更新频率切换至于系统时间相同，也就意味着更新频率更低)。
退一步说，假使timer resolution能够达到16.7ms，它还要面临一个异步队列的问题。因为异步的关系setTimeout中的回调函数并非立即执行，而是需要加入等待队列中。但问题是，如果在等待延迟触发的过程中，有新的同步脚本需要执行，那么同步脚本不会排在timer的回调之后，而是立即执行。
再退一步说，假设timer resolution能够达到16.7ms，并且假设异步函数不会被延后，使用timer控制的动画还是有不尽如人意的地方。-->垂直同步问题