つい数日前に「Tweener、がんばれ！」とか言った側から、Tweenerの開発終了について、開発者のZeh氏のブログで公式なアナウンスが出てしまいました（汗）。

Zeh Fernando » Blog Archive » Tweener, 4 years later – A post mortem

上記記事の内容を意訳してみました。間違ってる部分も結構あるはずですが、大意はつかめてると思います。

執筆するのにとても時間がかかってしまったもう一つの記事です。

まずは始まりから話そう。僕は数年前まで、Flashムービーの開発時に何かしらのアニメーションが必要になったときには、自分で開発したMC TweenというFlashのActionScriptトゥイーン拡張機能を使っていた。この拡張機能は全くもって自分好みに作ったものだ。当時、他にも優れたトゥイーン拡張機能が存在していたんだけど、どれもどうも好きになることができなかった。それらのAPIのほとんどがあまりにも抽象的すぎて、僕の求めているものと違ったから。MC Tweenではprototypeベースのアプローチを採用し、MovieClipのような既存のオブジェクト型に新たな機能を追加するという手法をとった。プログラム的なトゥイーンに対して僕がとったこの構文アプローチに賛同してくれる人も何人かいて、最終的にはそれなりの人気を得ることができた。

しかし、2005年になると、MC Tweenに対してかなりイライラするようになった。MC Tween自体は意図したとおりに動いてる一方で、ActionScriptの文法やパラダイムが（特にAS2が登場したことから）変化し、僕自身がオブジェクト指向プログラミングへの理解を深めたこともあって、MC Tweenが既に僕の開発ワークフローに合わなくなってきていると言うことを悟った。加えて、MC Tweenの開発がかなり停滞するようになっていた。人気が出てきたことで、実験的な新機能を実装することを、考えるだけでも危険だと思うようになっていた。どん詰まりのような状態だった。

だから、その年の6月から、僕は新たにクラスベースのトゥイーン拡張機能を実験的に開発することにした。開発当初はインスタンスベース（tweenインスタンスを生成するような）だったんだけど、後にaddTween()という一つのメソッドによってすべてのトゥイーンを生成するという、静的なクラス構造に変更した。そして、stopTween()やgetTweens()といった付属メソッドを使って、様々な機能を操作するようにした。

このクラスにはとても多くの変更が加えられた。クラス名自身が変わったり（初期にはTwinaだったのがTweenerになり、ZTweenerになって、またTweenerに戻った）、パッケージの位置が動いたり（generic.*から zeh.easing.*、そしてcaurina.transitions.*）、APIが変更になったり。インスタンスベースから静的クラスへの変更は言うまでもないし、その他にも内部構造の変更などがたくさんあった。この過程で学んだこと、そしてそれこそがこの記事の趣旨なのだけど、それは自分のために何かを作る場合、その作ったものの結果を誰かが見て評価したり、ましてそれを誰かがとても大事な仕事に使ったりすることなど無いだろうと思って作っていると、リスクを負わなければならないのは自分一人だという単純な理由から、結果的に非常に多くのミスを許容することになってしまうということ、しかし、その過程でよりよい方法を見つけることになるということだ。

僕がこのプロジェクトの開発を始めた頃、トゥイーン拡張機能として一番有名だったのはFuse Kitだった。別にそれと競うつもりもなかったし、僕は自分自身のために何かを作り出し、自分のニーズに合うよう変更していくことの自由を楽しんでいた。 Tweenerが長いこと非公開（使っていたのは僕自身だけ）だったのはそのためだ。もっとも、Gringo（当時）のためのプロジェクトをビルドするために使っていたんだけど。

Tweenerが「公開」されたのは2007年1月のこと。最初のバージョンを開発してからおよそ2年後のことだった。Nate Chatellierがちょうどチームに参加してくれて、AS3バージョンのTweenerを作ってくれたんだけど、その時、これをこのまま非公開にしておくのはフェアじゃないなと思ったんだ。それにその時点でAPIにはあまり大きな変更が加わることもなさそうだったから、他の人からのインプットが欲しかったというのもあった。

Tweenerは別に斬新なものであったわけでもないし、APIだってそれほど目新しいものではなかった。 Tweenerの採用した、新規トゥイーン生成に関するlooseなアプローチにしても、他のトゥイーン拡張でも採用されていた。AS1ベースの拡張にさえも採用されていた。とはいえ、それはその時期においては正しい構文だった。実際、一時期はそれなりに有名にもなったし、他の言語版のものまで出てくるようになった。

これがまさに4年前のお話（ログを見ると、Tweenerは2005年6月15日に開発を開始したことになってる）。今日では他にも多くのトゥイーン拡張が登場していて、特に有名なのはGo, TweenLite / TweenMax, GTween, 新しいところではBetweenAS3などがある。ってことは？そう、またその時が訪れたと言うことだ。今日的なAS3バージョンがあるとは言っても、 Tweenerの持つパラダイムの大半は、今となってはかなり時代遅れになってしまった。僕はだんだん不満を感じるようになってきた。僕は多くのことを学んだ。もう動き出す時なんだ。

すぐに動き出すこともできたんだけど、その前に振り返って、うまくいったことやいかなかったことを見つめてみようと思った。この記事はいわばTweenerの死亡記事。この4年間で僕が何を学び、Tweenerのようなライブラリにとって ActionScriptがどのように変化してきたかという点に対する、僕なりの分析なのだ。

さてと。AS2からAS3に移行するにあたって考慮しなければならない重要なポイントが一つある。「エラー」だ。AS2ではエラーはすごくサイレントなもので、nullオブジェクトのプロパティを変更するスクリプトを実行しても、FlashPlayerは喜んでそれに従ってしまう。もちろん、オブジェクトが存在しないのだから、スクリプト自体は機能しないんだけど、そのことを示すエラーメッセージは何も出てこない。

このことは、厳密な動作が期待されるような場合に問題となる。取得したデータが意図したものであるかどうかを知るためには、いくつかのレベルの検証が必要であり、そうして他の方法によってユーザーに警告を出すことができる。TweenerのAS2版では、僕はユーザーにとってより安全に動作するよう努めた。具体的には、トゥイーンの間中、対象となるオブジェクトが存在するかどうかをチェックして、トゥイーンされているプロパティにデフォルトの値が設定されているかどうかをチェックしていた。

AS3になって、その機能は必要なくなった。存在しないオブジェクトやプロパティにアクセスしようとすれば、コードの実行はあらゆる方法で中断されるようになった。これは良いことだ。ユーザーが、自分が何かとても、すごく間違いを犯していて、それを修正しなくちゃいけないということを理解する助けになるから。

その一方で、AS3版にインポートするにあたり、TweenerはこうしたAS2のパラダイムを引き継いできてしまった。だから、さっき書いたようなチェック機能なんかもたくさん残ってる。また、存在しないプロパティの値をトゥイーンしようとすれば、FlashPlayerのエラーじゃなくて、 Tweenerの方でカスタムのエラーを表示するようになってる。

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はやりすぎなんだ。このやり方のせいで、パフォーマンスが低下し、ファイルサイズが増えるという副作用も出てしまった。

APIユーザー（？）を信頼しないというこの AS2式のやり方に関連した妥協点は他にもある。内部的に、Tweenerはできるだけ安全に処理を行うようにできてるので、ユーザーが他のことをする（？）ための余地がすごく少ないんだ。そのことを示す一番わかりやすい例がある。新規にトゥイーンを作成する時、Tweenerは似たようなトゥイーン（同じオブジェクトの同じプロパティで、実行時間のかぶるようなトゥイーン）がないかどうかを探し、それらを削除しようとする。別にそれはそれで機能するし、それがアニメーションに求められる挙動であることも事実なんだけど、これによって2つの問題が発生する。まず、トゥイーンの上書きが強制的に行われ、オプションではないということ。そして、新規のトゥイーンを生成するときにパフォーマンスを大きく低下させるということ。既に大量のトゥイーンが同じ場所で存在する場合なんかはなおさらだ。なにせ、すべてのトゥイーンとオブジェクトが、かぶってないかどうか最初にチェックされるのだから。

僕は長いことこの安全なアプローチを好んでた。だけど、ActionScriptがより複雑になり、最新の方法を使うことでより良いパフォーマンスが得られるようになったことで、この手法は過剰な譲歩となってしまった。結局、程よく安全に、でもユーザーに対してはデフォルトの用法を回避するための方法を残しておく、というのが、ベターなやり方なんだ。

だから、今日では僕はトゥイーンの上書きはデフォルトではオフになっていて、付随機能として提供されるべきだと確信している。（別に驚くようなことじゃない。TweenMaxのようなクラスで採用されている手法だ）

最近のトゥイーンエンジンのパフォーマンスを比較すると、この問題はより明らかになる。実際のトゥイーンの更新に要する時間やメモリの消費量などは悪くないとはいえ、生成するトゥイーンの量が増えれば増えるほど、Tweenerの処理はキツくなってしまう。新しいトウィーンが生成される度に既存の全トゥイーンとの競合をチェックするので、トゥイーン生成に要する時間が飛躍的に高くなってしまうんだ。トゥイーンの数が1000を超えると、新規にトゥイーンを生成しようとするだけで、アニメーション自体の所要時間をオーバーし、FlashPlayerがしばらく固まってしまうこともしばしばだ。

Tweener はトゥイーンのリストをたった一つの配列で管理しているので、より有能なAS3ネイティブな手法を採ることで上記の点は解決できるかもしれない。 Dictionaryを使うとかね。でも、当座しのぎにはなるかもしれないけど、他にも問題は残ってる。Tweenerはとにかく安全に動作しようとしすぎるんだ。ユーザーの手を引いて導き、ユーザーがパフォーマンスを向上させたいと思って処理の内容を知ろうと思っても、その余地を与えない。

今日のTweenerについて言及するとき、これはもう最適化の問題ではないと僕が思うのは、そういう理由なんだ。一時しのぎならできる。いくつかのチェック処理を外すとか、代わりにDictionaryのようなAS3の新機能を追加してリストを管理するとか、ベクター機能を追加するとかさ。でも、正直なところ、Tweenerはもうその全盛期を終えてしまったと僕は確信している。だから、そういう変更を加えたとしても、まさに、ただの一時しのぎでしかないんだ。

だから、もうこれ以上Tweenerの更新をするのは無意味だ。もちろん、（特に同時に千を超えるようなトゥイーンを実行する必要が無いならば）現在も機能するし、これからも機能し続けるだろう。でも進歩という点においてはもう行き詰まってしまった。今やより良い方法がいくつも存在している。Tweenerだってまだがんばれてる（と思う）、でも、戦略を講ずるだけの十分な余地が残されていない。このプロジェクトは、あるがままの姿で残し、何か新しいことにとりかかるのが、ベストな選択なんだ。

ただ、ちょっと見て欲しいことがある。

隠れていた新たなバグが出てきたりでもしない限り、Tweenerをアップデートするつもりはないんだけど、最近ちょっとした更新をしたんだ。新バージョンの 1.33.74が、Google Codeのプロジェクトページとsubversionサーバーの両方で公開されている。この更新では、デフォルトのトゥイーンの上書きについては残しつつ、overwriteという新たなパラメーターを追加し（この値をtrueにすると、これまでの挙動と同じになる）、autoOverwriteという新たな静的プロパティ（上書きに関するデフォルトの挙動を変更する）を追加した。それが何で良いことかって？処理が早くなるんだ。

上の図で、青いグラフはトゥイーンのない状態を、オレンジのグラフはTweener 1.31.74を、黄色のグラフはTweener 1.33.74でoverwritingをfalseにした状態を示している。

大したことではないかもしれないけど、これはこのプロジェクトに携わった数年間で僕が受けたサポート、助言、レッスン、そしてすばらしい経験に対しての、僕からの感謝の印ととらえて欲しい。プロジェクトを直接サポートしてくれたメンバーに対してだけではなく、このプロジェクトを様々な面から支えてくれたすべての人たちへの、僕からの最高の感謝の気持ちです。

あと、まあこれで終わりということになるので、記事の内容には大して関係ないかもしれないけど、僕がTweenerの開発をGoogle Codeのサイトに移してからずっと集計してきた興味深い画像を見せようと思う。これは、バージョン別の、安定版のTweenerのダウンロード率を比較したものだ（ダウンロード数の完全版はこちら）。徐々にではあるけど、AS3の占める割合が増えていることがわかる。ちなみに、今日リリースしたバージョンは含んでいない。

こちらは同じ図を正規化せずに表したもの。

あとがきとして、皆さんに伝えておきたいことがある。僕はトゥイーンに対して、個人的に、Tweenerによってもたらされたのとは別のアプローチを使っている。Tweener はまだ機能してるし、これからも機能し続けるだろうけど、僕自身のワークフローは少し変わったんだ。僕はもう色のトゥイーンやその他に使う特殊なショートカットは使っていない。その代わり、独立したクラスやgetter/setterやdecoratorなどを経由した特定の機能を使うようになった。他の人たちもそうするべきかって？そんなことは僕にはわかるはずもない。ただ、僕がTweenerのようなことに取り組んだそもそもの理由というのは、自分の開発フローにフィットするような何かに取り組むこと、そして需要があれば後に他の人たちが使えるようにするのが楽しかったからだ。そりゃあんまりにも単純なんじゃないの、と思うかもしれない。僕がTweenerを公開するまでに長い時間を要したのはそのためだ。ただ、僕はすべての人のニーズに応えるために作られたものを使うより、誰かのため（僕と同じ意見の人ならば）に作られたものを使う方が好きだ。巷にある他のライブラリーに同じことがあてはまるとは言わない。というか、僕にはそんなことわからない。ただ、こうしたライブラリーのたぐいに対する僕なりのアプローチについて、そして、ベストなアプローチを持たないと判断した何かに固執するより、新たに動き出すことを僕が望んだその理由について、説明しておきたかったんだ。

最近の僕はトゥイーンを行うときに複数の方法を併用している。いくつかのものにはTweenerを使い、他のものには僕のワークフローにとてもよくフィットし、最高のパフォーマンスを求めるときに乱用できる（僕が求めること以外のことはしようとしないからね）ような、自作の実験的トゥイーンエンジンを使う。そして、（たぶん来週から）僕がつとめることになるFirstbornの人たちが作り、やがて僕自身もそれについて語ることになるであろうトゥイーンエンジンも使っている。

はっきりさせておくけど、「Tweener2」とか、そういうのは出てこないからね。

改めて、ありがとうございました！