好？例如，令我震惊的是，许多开发人员（新手或老手）仍然使用CSStop和left而不是transform来创建翻译动画，即使你在8核MacBookPro以外的任何设备上测试它的区别帧率非常明显。看到这句话的时候我也惊呆了，正如作者所说，我是那种从不关心两者区别，用top和left来制作平移动画的人。那么两者为什么会有区别，让我们一探究竟。测试用例其实很丢人。早在2012年，就有不少人在博文中阐述了这一事实。因此，我很容易找到一个非常好的demo（源码见参考资料），如下：top和leftareimplementedbasedonTranslatinganimationofkeyframetranslateImplementthetranslationanimationbasedonkeyframe.相信读者在将MacbookPro增加到一定数量后，就能发现两者的区别。幕后现在让我们探讨原因。打开Chromedevtools，切换到Performance选项，录制一段时间后，选择一帧，可以查看每个进程所用的时间。第一个是左上角的时间轴：在此帧中，我们看到多个步骤占用了CPU时间。切换到翻译变成完全不同的外观：根本没有CPU时间。我看了很多帧，除了少数几帧脚本执行时间在0.1ms左右，大部分帧的CPU时间都是0。答案已经很明显了，使用translate做平移运动，大部分时候是不需要CPU参与的。这个结果和五年前的文章不一样，但是五年过去了，浏览器优化到现在也不足为奇。接下来我们打开Render，打开PaintFlashing和LayerBorders。对于top和left，我们会看到如下情况：绿框是浏览器重新绘制的区域，为了position的使用，浏览器会在动画执行过程中不断绘制绿框内的区域。对于transform来说，则是另外一种场景：我们可以看到在transform后的版本中，我们的MacBook图片周围会多出一个frame，因为transform会生成一个新的layer，对这个layer进行transforming，对于浏览器来说，那就不用说了重绘。包括我点击“add10moremacbook”后，只有插入元素才会导致重绘。同样，新插入的“MacBook”也有自己的图层，不会造成重绘。那么，Chrome创建图层的标准是什么？在AcceleratedRenderinginChrome中，有如下语句：Whatelsegetsownlayer?Chrome的启发式算法随着时间的推移不断发展，但目前以下任何触发层创建：3D或透视变换CSS属性
