Tweener停止开发

这两天发现最大的新闻就是Tweener的作者宣布停止对Tweener进行开发，并在其blog上发表了一篇长达数千字的回顾。

这篇回顾对了解Tweener的发展很有帮助，并且包含了作者4年来的经验和心得。所以我勉强翻译如下：

Tweener，历经4年之回顾

这篇回顾花了相当长的时间。

一切从头说起。几年之前，当我在Flash开发中需要做一些动画时，用的都是自己开发的叫MC Tween的库。这个库完全以我个人的喜好来创建，同一时期也存在其它不错的库，但我不是很喜欢，就因为我觉得它们中大多数的API都太抽象了，而我宁愿采用基于原型（prototype-based）的方式直接给对象——比如MovieClip——灌入新的功能。很多人赞成我的作法，所以它瞬间就流行了起来。

但进入2005年后，我对MC Tween的不满愈见增加。虽然它能很好的完成工作，但由于ActionScript在语法和规范上的变化（AS2的出现），加上我对OOP良好的认知，让我认识到目前的开发流程将不再合适。而且，MC Tween的开发已经进入稳定期，由于它的流行，导致任何功能上的变化都会有混乱的危险。这是很郁闷的。

所以在当年的6月，我开始开发了一项全新的、基于类的tween库。最初，它是基于实例的（需要创建tween的实例），但后来就改成静态类了，所有行为只要通过调用一个叫addTween的方法即可，并附有额外的功能，像stopTween、getTweens等等。

这个类经历了一系列变化，就比如它的名字（最初叫Twina，后来改成Tweener，再又改成ZTweener，最终又改回Tweener），类包也一直在改（从generic.*到zeh.easing.*再到caurina.transitions.*）API也改了很多，除了说过的实例化改静态化以外，还有很多重大的内部修改。这里谈一个重点——我认为也是本篇回顾的重点——那就是，当创建一个仅供自己使用的东西时，没人会对这个东西抱以关注或作出评判，更不用说把它用于重大项目中了，这样一来风险只有自己在承受，所以错误百出也是必然。但在这个过程中，你会发现更好的方法。

在我开始这个项目的时候，Fuse Kit早已名声在外。我并没有想要于其竞争，只是对这块领域很感兴趣，对我来说，只要把它改到适合我的需求即可。这也是为什么Tweener长期没有公开（只有我自己在用），即使已经投入到Gringo（当时）等项目的使用中。

Tweener的公开是在2007年1月，时隔近两年终于诞生了第一个版本。Nate Chatellier此时加入开发队伍——创建了AS3版本的Tweener——我也认为不能一直藏着掖着。那时，API也么有很大变化，所以用起来还挺爽。

Tweener并不是什么新鲜的东西，API也并非让人耳目一新，但由于它宽松的使用方式，却为已经存在的众多tween库给予了重新的定义——包括AS1方式的库，而这也一下子成为了主流，甚至得到多种语言的支持。话虽如此，它也只是在合适的时间采用了合适的语法，

4年转瞬即逝（从日志来看，Tweener启动于2005年6月15日）。时至今日，已经有很多其它tween库——比较流行的有Go，TweenLite/TweenMax，GTween以及新秀BetweenAS3——这其中的道理你懂了么？又到了某个时期了。即使拥有AS3版本，但Tweener采用的大多模式已经过时了。我的不满又日益渐增，并到了该采取行动的时候。

我已准备就绪，但仍想回顾一下得失。这篇Tweener回顾我4年来的心得，以及如何去运用Tweener。

当从AS2向AS3迁移时，一项重大改变是我们必须要考虑的：错误。它在AS2中是静默式的。你可以操作一个null对象的属性，FlashPlayer也不会见怪。当然，由于对象不存在也就不会发生任何事情，但你得不到任何错误信息。

这就造成一个问题，当你希望工作严谨时，就需要多层校验来确保数据的正确性后，才能警告用户。对于AS2版本的Tweener，我试图让用户尽可能的安全使用。所以每次我都会检测对象是否存在，属性是否有一个有效的值。

在转向AS3后，这些工作已经不再必要，如果你试图访问一个不存在的对象或属性，代码将会被终止执行。这很好，它能帮助用户了解自己造成的很多很多错误，促使其改正它们。

在转向AS3时，Tweener保留了很多AS2的模式，包括一大堆的校验。在试图对一个不存在的属性执行tween时，得到的会是一个Tweener自定义的错误，而不是FlashPlayer自带的错误。

if (rScopes[0][istr] == undefined) {
    printError("The property '" + istr + "' doesn't seem to be a normal object property of " + String(rScopes[0]) + " or a registered special property.");
}

在不断的循环迭代中，这样的东西随处可见——它检测对象、属性是否存在，等等。该说什么呢，Tweener太勤奋了。这严重影响了效率，却增加了文件大小。

另一个让人妥协的事情，是Tweener在内部要尽量安全的执行，而给用户很小的破坏空间。最大的问题是，当创建一个新的tween时，Tweener会查询类似的tween（同时应用于相同对象的相同属性），这些应被删除。删除重复的内容，乍一看很有道理，但却带来两个问题：第一，这并非可选的，覆盖成了强制行为。第二，创建新tween时，效率的极大损失。在大量运用tween时会特别明显，因为所有的tween都要被检测一遍。

这就是我要说的所有内容，时至今日我相信覆盖已经不再是默认行为，而是可供选择（不用惊讶，TweenMax就是如此）

比较各大tween引擎之间的效率能将该问题显著化。Tweener在实际运行和内存消耗上不温不火的表现，对于大量的动画难以应付，由于反复的检测造成创建耗时的成倍增长，当数量达致上千时，创建所花的时间往往比动画本身还要长。

现在的Tweener使用一个数组作为列表，而这方面使用AS3自带的Dictionary会更好（别惊讶，TweenMax就是如此，实际上Jack Doyle是第一个向我提出该技巧的人）。然而这仅仅是权宜之计，问题仍然存在——Tweener为了安全的执行，而不得不强制引导用户，为了效率，就算他们知道自己要干什么，也没有可以发挥的余地。

这也是造成Tweener今时今日下场的原因所在，我认为这不再仅仅是一个优化的问题。比如去掉一些检测，使用一些像Dictionary抑或Vector这样时髦的AS3特性，都无济于事，我确信Tweener在设计上已经远离初衷，所以上述改变只能是权宜之计。

于是，更新Tweener已经没有意义。确实，它仍能工作（只要不在过量使用的场合下）且仍会工作下去，但它不会再进步了，它已达到了终点。现在有了更好的替代品，为此关闭Tweener亦无遗憾，我只是觉得，它还有其价值，留着它给有用的人吧。

还有些东西要提。

我不会再更新Tweener，除非出现一些新的、严重的bug。最后一次小修改——新的版本1.33.74，在Google Code和subversion上都提供下载。这次更新保留了默认的覆盖行为，只是增加了一个新的参数，overwrite（设置为true时，为旧的行为）和一个新的静态属性，autoOverwrite（改变默认的覆盖行为）。这样有什么意义呢？一个字——快。

上图显示，蓝色条表示没有tween，橘红色条表示使用的1.31.74版本的Tweener，黄色条表示使用1.33.74版本，并将overwriting设置为false的Tweener。

对给予过我支持、建议，教训以及这些年来收到所有关心该项目的人，我无以回报，在这里，我不仅要感谢为项目作出杰出贡献的人，还包括所有对项目提供过细微帮助的人，我衷心的感谢你们。

在即将关闭时刻，即使这篇回顾没有什么太多内容，也请看一下这张有趣的图表，表中融合了这几年来Tweener在Google Code上的情况。比较了几个稳定版的下载趋势（看完整下载量）。过程是缓慢的，这也让我们看出AS3是如何慢慢占据主要地位的。其中不包括本次更新的版本。

这是另一张统计图，只是没有标准化。

作为总结，我还得加些自己的风格，那就是我在使用tweening时的方式和Tweener介绍的方式略有不同。虽然Tweener依旧，但我的工作流程有了变化。我从来没有用过诸如color tweening之类的快捷方式，而是更喜欢为之创建各自的类，通过getter/setter功能来装饰它。是否有人也这么做呢？我知道这很不爽，但这么做的理由，就好像我为什么开发Tweener一样，首先我喜欢以我的开发风格来工作，然后把结果共享给其他有需要的人。这也是为什么Tweener久未公开的原因，你可以说我不成熟，但我更喜欢为有需要的人做调整（只要我同意他的观点）而不是为所有人做调整。这里不去说其它的库是怎么做的——我也不知道——只是解释我如何处理我的库，以及为什么我对觉得不是最好的方法一直不予理睬。

现在，我混合几种方式来使用tweening：有些用Tweener，还有一个我为自己开发的试验型的tween引擎，它被我用在对付效率为首（因为我不想它用于别处）的任务中，还有一个我朋友Firstborn开发，我捐助的tweening引擎（马上就要公布）我希望今后能多谈谈这些事。

注意，这些都不会是什么“Tweener 2”之类的东西。

最后，再次表示衷心的感谢。