|
[tr][td] 1) 动画绘制的利器：RequestAnimationFrame
RequestAnimationFrame，绝对的大名鼎鼎。相信做HTML5的同学们，都听到过这个函数。再重复一下它的好处： 游戏页面在不被显示的时候，RequestAnimationFrame暂停执行，不会占用CPU时间 RequestAnimaitonFrame会将JS产生的动画以及CSS产生的动画，放到同一个Repait和Reflow的循环中。 对于第二点，很少有人提及，但是非常重要，如果没有RequestAnimationFrame，而用setTimeout，很有可能在每次绘制的时候，JS产生的动画和CSS产生的动画，没有同时发生，相信这个肯定不是你想要的结果。对于第二点，有点晦涩，不太容易懂，让我们更进一步解释一下，这就要从浏览器的渲染流程说起。大体上，浏览器的渲染流程有以下四步： 更新Dom的结构：每次你执行JS改变Dom结构，或者修改CSS相关属性，都会对Dom结构进行改变。现在HTML5中，多了Canvas元素，对于Canvas对象，执行某个操作，比如画一条线，也属于对Dom结构的改变。但是Canvas有个比较特殊的操作，比如对Canvas对象执行getImageData操作，会强制浏览器立即跳到第四步，将渲染好的浏览器窗口，绘制到屏幕。 渲染每个元素：在所有JS和CSS执行完毕之后，浏览器按照要求，开始对每个元素进行渲染。 [*]将所有元素渲染到窗口：按照窗口大小的要求，将所有的元素，绘制到一个平面上。 [*]通过操作系统窗口管理器，将渲染好的窗口，输出到屏幕。 通常，执行完第四步，称为一帧。目前，大部分的显示器，都会将显示控制在每秒六十帧，浏览器处于优化的目的，通常的显示频率也不会超过六十帧。 讲到这里，大约可以清楚一点，如果不用RequestAnimationFrame，而是用传统的SetTimeout，很难要求浏览器将同一次SetTimeout里面执行的Dom或者CSS操作放到同一帧中，也就会随机的出现，某个JS操作的动画和CSS或者Canvas的动画，不能同步。因为随机的，每次行为不一致，相信这是所有开发者都不愿意碰到的情况。没有开发人员怕Bug，但是害怕的是Bug不可以重现。 2) 计算游戏的帧率（FPS） 衡量游戏性能的重要指标就是帧率（FPS），因为浏览器的实现不一，有些浏览器出于优化的目的，没有严格的按照第一部分介绍的四步，有些时候，在某一帧没有完成的时候，就开始执行下一帧，所以理论上，很难严格的记录浏览器显示的帧率。如果你可以有个高速的摄像机，对着屏幕拍摄，是可以严格的记录屏幕显示的帧率，但是相信这个方法，很难被大规模使用。 目前也有一些第三方类库，可以帮助你衡量游戏的帧率，比如比较著名的https://github.com/mrdoob/stats.js，但是这个是非常不严格的，以StatsJS为代表的类库，是利用很衡量setTimeout或者setInterval每秒钟被执行的次数或者时间，来衡量帧率的。但是seTimeout函数被执行的次数和时间，和RequestAnimationFrame没有特别严格的对应关系，只可以作为参考。或者，简单一点说，每一帧被渲染的过程中，setTimetout函数很有可能被执行一次或者两次，甚至更多次。 理论上，为了监控RequestAnimationFrame帧率，需要开发者hook RequestAnimaitonFrame这个函数，在函数每次执行完毕的时候，执行Canvas的getImageData操作，强制浏览器渲染本次RequestAnimationFrame的所有操作，计算两次渲染操作的时间差，从而得出帧率。 幸运的是，Firefox浏览器已经开发了得到帧率的接口，可以省去很多周折。比如window.mozPaintCount这个接口，可以直接告诉开发者，浏览器渲染的帧率。 （未完待续） 接上文：HTML5 游戏开发 之 资源加载篇(2) HTML5 游戏开发 之 资源加载篇(1) [/td][/tr] |
|
