盒子端 CSS 动画性能提升研究
不同于传统的 PC Web 或者是移动 WEB，在客厅盒子端，接大屏显示器下，许多能流畅运行于 PC 端、移动端的 Web 动画，受限于硬件水平，在盒子端的表现的往往不尽如人意。
基于此，对于 Web 动画的性能问题，仅仅停留在感觉已经优化的OK之上，是不够的，想要在盒子端跑出高性能接近 60 FPS 的流畅动画，就必须要刨根问底，深挖每一处可以提升的方法。
流畅动画的标准 理论上说，FPS 越高，动画会越流畅，目前大多数设备的屏幕刷新率为 60 次/秒，所以通常来讲 FPS 为 60frame/s 时动画效果最好，也就是每帧的消耗时间为 16.67ms。
直观感受，不同帧率的体验 帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适； 帧率在 30 ～ 50 FPS 之间的动画，因各人敏感程度不同，舒适度因人而异； 帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感； 帧率波动很大的动画，亦会使人感觉到卡顿。 盒子端动画优化 在客厅盒子端，Web 动画未进行优化之前，一些复杂动画的帧率仅有 10 ~ 30 FPS，卡顿感非常明显，带来很不好的用户体验。
而进行优化之后，能将 10 ~ 30 FPS的动画优化至 30 ~ 60 FPS，虽然不算优化到最完美，但是当前盒子硬件的条件下，已经算是非常大的进步。
盒子端 Web 动画性能比较 首先先给出在盒子端不同类型的Web 动画的性能比较。经过对比，在盒子端 CSS 动画的性能要优于 Javascript 动画，而在 CSS 动画里，使用 GPU 硬件加速的动画性能要优于不使用硬件加速的性能。
所以在盒子端，实现一个 Web 动画，优先级是：
GPU 硬件加速 CSS 动画 > 非硬件加速 CSS 动画 > Javascript 动画
动画性能上报分析 要有优化，就必须得有数据做为支撑。对比优化前后是否有提升。而对于动画而言，衡量一个动画的标准也就是 FPS 值。
所以现在的关键是如何计算出每个动画运行时的帧率，这里我使用的是 requestAnimationFrame 这个函数近似的得到动画运行时的帧率。
原理是，正常而言 requestAnimationFrame 这个方法在一秒内会执行 60 次，也就是不掉帧的情况下。假设动画在时间 A 开始执行，在时间 B 结束，耗时 x ms。而中间 requestAnimationFrame 一共执行了 n 次，则此段动画的帧率大致为：n / (B - A)。
核心代码如下，能近似计算每秒页面帧率，以及我们额外记录一个 allFrameCount，用于记录 rAF 的执行次数，用于计算每次动画的帧率 ：
var rAF = function () {
return (
window.requestAnimationFrame ||
window.webkitRequestAnimationFrame ||
function (callback) {
window.setTimeout(callback, 1000 / 60);
}
);
}();
var frame = 0;
var allFrameCount = 0;
var lastTime = Date.now();
var lastFameTime = Date.now();
var loop = function () {
var now = Date.now();
var fs = (now - lastFameTime);
var fps = Math.round(1000 / fs);
lastFameTime = now;
// 不置 0，在动画的开头及结尾记录此值的差值算出 FPS
allFrameCount++;
frame++;
if (now > 1000 + lastTime) {
var fps = Math.round((frame * 1000) / (now - lastTime));
// console.log('fps', fps); 每秒 FPS
frame = 0;
lastTime = now;
};
rAF(loop);
}研究结论 所以，我们的目标就是在使用 GPU 硬件加速的基础之上，更深入的去优化 CSS 动画，先给出最后的一个优化步骤方案：
精简 DOM ，合理布局 使用 transform 代替 left、top，减少使用耗性能样式 控制频繁动画的层级关系 考虑使用 will-change 使用 dev-tool 时间线 timeline 观察，找出导致高耗时、掉帧的关键操作 下文会有每一步骤的具体分析解释。