哲学上有种说法，「运动是绝对的，静止是相对的」。我们在编写各样的效果时，时常会碰到动画。下面的章，将讨论动画的原理以及实现。

动画，简而言之就是物体在某时间段内，不断的改变自身的属性。这些属性有可能是位置、大小等。为了方便说明，在这里统一认定为位置（position）。

那么，动画就有了两个基本的变量，时间和位置。用直角坐标系来表示，将 x 轴定为时间（time），将 y 轴定为位置（position），就可以得到这样的坐标系

从这个坐标系可以获得更多的信息，比如动画运行的时间段（x 轴的区间）、动画开始试物体的位置（begin）以及结束时的位置（final）。

然后，动画的基本关系可初步抽象出来。时间（duration）和位置（position）存在函数关系

position = f(time)

在这里同时引入 fps （帧率）这个概念。fps 简单的说，就是一秒钟内物体变化了几帧。它抽象成坐标中的元素，就是 x 轴的粒度。

fps 是个常量（比如通常电影的 fps 为 25，即每秒 25 帧），通过 fps 以及时间段（duration），则可以计算出这个时间段内物体位移了几帧（frames），公式如下

frames = (duration/1000)*fps

上述公式中，时间段（duration）以 毫秒 计算，即一毫秒等于一千分之一秒。

综合起来，我们要获得某个时间点的位置时，就可以利用 当前时间点（time）、时间段（duration、x 轴的区间），以及开始的坐标（begin）和结束的坐标（final）等因素来完成，那么可以将第一个的公式细化成

position = f(time, begin, final, duration)

同时，根据 fps 计算出的帧数，则可以得知某动画在这个时间段内运行了几次。而此函数产生的曲线，则可以说明在指定时间段内，物体的运动情况。如曲线比较抖，则说明物体运动比较快，反之则慢。

例如上述函数图的 45 度曲线，如果不考虑区间因素则可以写成

position = time

然后加上函数区间，则用函数表示

postion = final * time / duration + begin

那么就可以说明物体随着时间的改变，位置进行匀速递增的运行。

至此，元素的动画问题，这时就可以抽象成具体的数学问题。仅通过改变函数的公式，就可以改变物体动画的运行效果。

附，相关参考资源：

维基百科： 动画 （ 中文 ）、 FPS/帧率 （ 中文 ）

--未完待续--

佛爷 去了公司的年夜饭，我有点无聊就在公司 Coding 点东西玩玩，于是就有了这玩意。请允许我很猥·琐得将这个游戏称之为 「是男人坚持 100 次」 （坦白讲，我是死活玩不到这个级别了）。

原定两个小时搞定的脚本，结果花了我将近三个小时的时间。完事后 我在 Twitter 上记录下 心得结果被群殴（看来 Twitter 不能当作笔记本），还是记录到 Blog 里比较靠谱

1. 设计模式和算法很重要，在前期打「腹稿」的时候就应该搞定那玩意。
2. 按需加载，特别是在大量的 DOM 操作时，这时候就要体现算法的力量了。
3. 命名很重要，能避免很多问题。比如遇到了不大不小的 Bug，原因是我作孽得将某个变量命名为 「class」 了。
4. 效率优先是没有错，可怜我一开始就考虑这些而忽略了其他更重要的事情，绕了很多的弯路。
5. 结构尽量精炼，能用 CSS 实现的效果尽量用 CSS 实现。
6. 将「杂碎」的处理拉出来或者再细分整理下，不要写「一坨」很长的 function，自己看着都累。

对技术实现有兴趣的朋友可以 看下核心的 Javascript 代码 ，欢迎提任何建议。PS，在内测的时，虽然这小游戏是我写的，但发现谁都比我玩得好，真是没有脸活了。

顺便八卦： Javascript 做游戏并不是不可能 。从目前的情况以及效果和成本看，还是使用 Flash 比较得当。到 HTML5 以及 Canvas 普及以后，这情况可能会有所改变，不过在这之前谁又能等的了呢。

最后，游戏地址：

http://friable.rocks/dazing/ 也 写了个 Javascript 小游戏 ，我称之为「天上地下打不死」，有兴趣也可以看看。

八卦文章，所以标题党下，见笑。期前编写 JavaScript 框架的规则， 玉伯在他的 Blog 已有提到 。而今天看见 Ajaxian 上 收集的目前主流 JavaScript 框架占用的 全局空间变量数目 ，我也忍不住八卦下。

大家或许都知道，使用全局空间要格外的谨慎， 如果滥用全局空间会造成诸多问题 。随着 Javascript 的框架越来越多，不同的设计哲学相互碰撞，形成很有趣的局面：

其实，从上面几个图就能看出 Javascript 框架能分成几个流派，就我使用过的几个典型的框架，谈下我的看法：

YUI 看起来像是少林寺，代码调理清晰谨慎也非常容易阅读和理解，但略显庞大和臃肿。其使用全局空间的方式，也 犹如少林寺规一样 ，不敢「越雷池」半步，如数绑定到了 YAHOO 上。

jQuery 犹如丐帮，使用面广、上手容易，但要学得「降龙十八掌」和「打狗棒」并非易事。对于全局空间的态度也虽谨慎（全部绑定到 jQuery），但大家似乎更习惯使用「$」，而忘记还有个 jQuery 变量。

Mootools/Prototype 很逍遥派，代码优雅高效，但真正理解的掌握需要有高深的内功。全局空间上使用也近乎随意，甚至对浏览器内置的功能也有不同程度的扩展。Mootools 的作者也 讨论过相关的设计哲学 ，在这里就不复述。

另外还有个很有趣的现象，就是似乎大家都很喜欢使用美元符「$」变量。但这意味着如果载入不同的框架，就会造成命名空间的相互污染（ 详细 ）。

避免全局空间的污染，在一定程度上能避免以后自找麻烦，也更有利于代码的模块化。撇开上述框架的八卦，在编写实际代码时更应该注意全局空间的污染问题。