你必须确保它能够非常容易地尝试不同的速度或时间节点。举个例子，如果一个动画效果在 1/10 的速度下还表现地结结巴巴，那么可能会有一些非常基础的错误。如果在放慢 50 倍的速率下表现流畅，假以时日定能找到运行流畅的最大速度。或许正常速度下 5 毫秒的差池很难被注意到，但是放慢速度，它就变得非常明显了。

　　尤其是做非常复杂的动画分析，或者解决非常棘手的性能瓶颈，慢动作查看元素会非常的有用。

　　重要的一点就是，在慢动作下你会将非常多的细节优化地完美，当动画加速之后它将会给人完美无瑕的感觉。尽管这些都显得微不足道，但是用户会注意到动画效果的流畅和细节的。

　　只有 OS X 才有的功能—如果你 shift + 点击最小化按钮或者一个应用图标，你将会看见它在缓慢移动。基于这一点，我们甚至在陀螺仪上实现了这个功能，当你按下 shift 键的时候将会激活慢动作模式。

　　6、给你的用户界面录个像，并且在重复播放中得到一个有价值的第三人视角的看法。

　　有时候不同的视角能够帮助你对事物有更加清楚的认识，而录像则是一种很好的方法。

　　有的人会用 AE 做视频然后放到网站上，而我恰恰相反，我总是尝试将网站界面录制成很棒的视频。

　　发布视频其实门槛很高的。有一天我对做出来的东西感到非常激动，想记录下来和朋友们分享。

　　然而，当看第二遍的时候，我发现了一些瑕疵，时间节点设置得不那么恰当，并且出现了一个延迟尖峰。这让我有点打退堂鼓了，我发现还有很多的内容需要优化，所以我不能就这么把视频发送给朋友。

　　在使用过程中这些瑕疵都很容易被掩盖，但是在视频中一次次地观看慢动作的动画能够让一切问题都暴露地非常明显。

　　有人会说拍摄出来和看起来的效果并不完全相同，但也许它变更加精确了呢。

　　这已经成为我工作中很重要的一部分，我会观看慢动作的视频并且修改任何我觉得不妥的地方。其实也可以很容易地将这类问题归咎于浏览器性能差，但是再多优化一点多测试一点，这些问题就能够得到解决。

　　等到你在视频中不会发现非常尴尬的延迟尖峰，并且感觉视频挺好的可以晒出来了，这个时候你的页面就可以发布了。

　　7、网络活动可能会造成延迟。你应该预加载或者延迟处理非常大的 HTTP 请求

　　图片便是其中一个元凶，无论是几个大图片(大的背景图)或者非常多的小图(五十个头像)，或者非常多的内容(一个从头到尾有很多图片的长页面)。

　　页面首次加载的时候，许多的东西会被初始化并下载。其中内容解析、广告和其他第三方脚本会使性能变得更糟糕。有时候，将动画效果在页面加载后延迟零点几秒将会对性能有很大的提升。

　　如果没有必要的话，不要过度优化动画延迟，一个复杂的页面要求非常精确的延迟和时间节点才能运行流畅。通常你会想要在开始的时候加载尽可能少的数据，当主要内容和介绍动画完成之后再继续加载其他的内容。

　　一个有很多数据的页面，需要深思熟虑地加载所有内容。一个在静态页面中表现良好的动画效果也许就会在实时数据的加载中变得缓慢。如果有些内容仿佛应该生效但却没有，或者不能一如既往地流畅表现，我建议检查一下网络活动，确认一下你是否也在同时处理其他的内容。

　　8、不要直接绑定滚动事件。貌似是个好主意，其实不然

　　基于滚动的动画在前些年一段时间非常火爆，尤其是涉及视差或者其他特效的内容里。它们的设计模式是好是坏仍有待考证，但是在技术上有着良莠不齐的实现方法。

　　基于滚动的动画中有一种非常流行的处理方式，即将滚动一定距离作为事件处理同时触发动画内容。除非你对自己的行为了如指掌，否则我会建议不要使用这种方式，因为它真的很容易出错并且很难维护。

　　更糟糕的情况是自定义滚动条功能，而不用默认的功能—又名 scrolljacking 。请不要这么想不开。

　　在这十项准则中，这项尤其适用于移动开发，另外可能也是理想用户体验的好的实践。