リリースノート

・モニタリングする対象 SWF をリストから選択出来るように機能を追加しました。
・不要なデータが混ざるのを防ぐため、サーバー <-> クライアント間のデータのやり取りをリモーティングからメッセージングを使ったものに変更しました。
・上記に伴い、サーバーを Jetty から自前サーバーに変更しました。
・サンプリングがおかしかった所を修正しました。

ダウンロード

SWFProfiler.zip (Ver. 0.0.3)
SWFProfiler.zip (Ver. 0.0.4)

使い方

・SWFProfiler.jar を実行します。
・監視したい対象 SWF をブラウザ上でもローカル上でもいいので開きます。
・リストから対象 SWF のファイル名を選択します。

以上の手順でプロファイリングが可能です。

使用に関して

・実行には JRE 1.6+ が必要です。
・FlashPlayer はデバックバージョンを使用する必要があります。
・SWF はデバッグリリースされている必要があります。

ソースコード

http://bitbucket.org/muta244/swfprofiler/ で bitbucket にて管理しています。

今回のアップデートでだいぶ使えるものになったんじゃないかと思います。ただ、バグやおかしな点もまだまだあるかと思いますので、これからもマイペースに更新していきます。ご意見・ご要望はコメント欄、もしくは bitbucket にチケット登録をお願いします。

先日リリースした SWFProfiler ですが、みなさん動いてなかったかと思います（ですよね？）。なので、修正版をリリースしました。ついでにモニター結果のフィルタリング機能と、定期的にガベージコレクションを自動で行う機能を追加しています。

ダウンロード

SWFProfiler.zip (Ver. 0.0.2)
＊ リンク先を間違えていたので修正しました。（’09.08.16）
SWFProfiler.zip (Ver. 0.0.4)
＊ バグ修正版。（’09.11.18）

あと、ブラウザ版にしろ、ローカル版にしろ、Flash Player はデバッグ版がインストールされている必要があります。それと、SWF 自体もデバッグモードで書き出されている必要がありますので、この点だけご注意下さい。

不明な点やバグ報告などありましたら、ぜひコメント欄へお願いします！

SWFProfiler のキャプチャ画像（nium さんの kujaku を勝手にプロファイリングw）

Flex Builder が無くてもデバッグ環境が必要だと思うので作りました。今の機能は Flex Builder プロファイラのライブオブジェクト相当のみです。Windows, Mac, Linux 全てで使用出来ますが、Swing で開発してるので JRE 1.6+ が必要です。

ダウンロード

SWFProfiler.zip (Ver. 0.0.1)

※ このバージョンは正しく動作しませんので、新しいバージョンをリリースしました。そちらをお使い下さい。

使い方

SWFProfiler.jar を起動した後、監視対象の SWF を開く（ブラウザ上でも可）と監視が始まります。現状では、複数の SWF を同時に開いているとおかしな事になるので、SWF は監視対象一つのみを開くようにして下さい。FlaProfiler とほぼ同じです。

今後の予定

・複数の SWF 対応
・モニター結果のフィルタリング機能
・コンソール機能
・メモリ使用状況のグラフ表示
・国際化

あとは Mac で文字列なカラムでソートすると、何故かちらつくんですよね。Win だと大丈夫。Swing の問題だとは思うんだけど、対処法がないか模索中。

さて、どこまで出来るかな。

Swing を使ったアプリでは SingleFrameApplication#shutdown() をオーバーライドして終了処理を記述する。この時、Windows ではクローズボタンで終わろうが、Alt+F4 で終わろうが、強制終了で終わろうが、ちゃんと shutdown() が最後に呼び出される。しかし、Mac だと正しく shutdown() が呼び出されない時がある。File -> Exit で終了した時など GUI 上で終了させた時は問題ないが、Cmd+Q や強制終了で JVM ごと終わらせた時には shutdown() が呼び出されず、終了処理が行えない。

そんな時の対処法が以下。

@Override
protected void startup()
{
    Runtime.getRuntime().addShutdownHook(new Thread()
    {
        public void run()
        {
            if (!shutdowned) {
                shutdown();
            }
        }

        // 通常の起動処理
        ...
    });
}

@Override
protected void shutdown()
{
    if (shutdowned) {
        return;
    }

    super.shutdown();

    shutdowned = true;
}

このやり方が正しいのかは分からないけど、Runtime#addShutdownHook() なら Mac でも shutdown() を呼び出せるので終了処理がきちんと行える。Swing はシステム関係無くアプリ開発出来ることを謳ってるので、結構この問題はクリティカルだと思う。Sun さんの修正を期待。

こんなエントリー、ActionScript と関係無さそうだけど、Flash 開発のために必要なことをやっているのです…。

Jar Bundler で .jar を .app にパッケージングする際の注意点。

この画面で “Use Macintosh Menu Bar” にチェック入れてても、Swing を使ったアプリケーションだとウインドウ上部にメニューが表示されず、フレーム内部に表示されてしまう。対処法は以下。

この画面の一番下でしているように、プロパティに “apple.laf.useScreenMenuBar” を true に設定して書き出せばスクリーン上部にメニューが表示されるようになる。

前回のデモは、衝突の可能性があるオブジェクト同士の関係を確認出来るものでしたが、今回は実際に接触しているかをチェックしています。こっちの方がイメージが湧き易いかな。

四分木のデモ（※ 要 FlashPlayer 9）

通常は灰色なオブジェクトが、他のオブジェクトに接触するとオレンジ色になります。

使い方はまたまた、今度・・・。

オブジェクト同士の衝突判定を行う際、みなさんはどうしていますか？

一番最初に思い付く方法は衝突対象のオブジェクトを配列にでも入れて、総当たりで Sprite#hitTestObject() なんかで判定してしまおうという方法だと思います。この方法でも、対象のオブジェクト数が少なければ特に問題にはなりません。しかし対象のオブジェクト数が多かった場合、総当たりで計算を行うという方法では計算量が膨大になってしまい、とても現実的とは言えません。

Sprite#hitTestObject() などの衝突判定を行う前に、どうにか衝突の可能性があるオブジェクトを限定出来ないか？

そんな時には四分木を使えば計算量が減らせます。
概念的には miscellaneous さんの「四分木」エントリーが参考になります。

四分木を構築する方法で一般的（？）なものは、空間全体をルートとし、2 x 2 の空間に分割しながらノードを構築するというもの。しかしながらこの方法、必ずしも計算量が減るわけではありません。なぜなら、衝突対象のオブジェクトを探すためにルートから該当部までノードをたどる必要があり、検索にもまた、計算コストが掛かってしまうからです。

じゃあ、どうすればいいのか？

その計算量を減らすため、四分木の構築方法は色々な方法が考え出されているようで、その中の一つに線形四分木というものがあります。概念的なものは、マルペケつくろードットコムさんの「その８ 4分木空間分割を最適化する！（理屈編）」がとても参考になります。このエントリーで書いてあることもほぼ受け売りです。

で、本題。今回自作ライブラリに線形四分木用のクラスを追加しました。これを使えば、四分木がどうこう考えなくても計算対象のオブジェクトを限定することが出来ます。その限定したオブジェクトに対して Sprite#hitTestObject() なんかを行えば、計算量も下がります。

四分木のデモ（※ 要 FlashPlayer 9）

※ 描画部分は四分木とはまた別の部分なので最適化していません。あんまり円を増やしすぎると、総当たりに切り替えた時にかなり重くなりますので注意してください。

デモはキーボードで各種操作を行え、四分木 <-> 総当たりの計算量比較が出来ます。オブジェクト同士を繋ぐ線は、衝突判定が必要なことを表しています。計算量がどれだけ減ったかを確認してみて下さい。

ソースは Bitbucket に一式上げてますので、興味の有る方はどうぞ。
使い方は後日、時間がある時にでも…。

テキストエリアのデモ（※ 要 FlashPlayer 9）

前回の UITextField クラスのラッパークラスで、スクロールが可能な UI を作成できます。

扱い方はサンプル [ドキュメントコード | TextArea 実装コード ] や UITextArea の ASDoc をご覧下さい。

テキストフィールドのデモ（※ 要 FlashPlayer 9）

このクラスを使用して、コンポーネントでいうところの TextInput と Label が作成出来ます。標準コンポーネントでは、ダブルクリックやトリプルクリックした際のテキスト選択がおかしいですが、このクラスを使用して作成した UI では、内部で拡張したテキストフィールドを用いる事により、ダブルクリックで単語、トリプルクリックで段落を選択するように拡張されています。その他にもクリックやタブなどで最初にフォーカスが移った際にテキストを全選択する機能や、IME を制御する機能なども備えています。

詳しい扱い方はサンプル [ドキュメントコード | TextInput 実装コード | Label 実装コード ] や UITextField の ASDoc をご覧下さい。また、使ってみて変な所があれば、Issue にぜひ登録してください。

変数名の長さによる処理速度の違い

変数名の長さによる違いはありません。ですので変数名は、他の人が見やすい・自分が後で確認しても分かり易いような名前を付けておいた方が良いです。

変数を参照する際の処理速度の違い

上のコードでは _getPi <<< Math.PI <<< MyMath.PI = Main.PI < PI = _pi = ns::_pi = pi という結果で、ビルトインクラスのプロパティアクセスは若干重いので、ループ内で大量に参照する場合は変数に格納しておく方が良いです。また、getter アクセスの実態は関数ですので結構重いみたいです。MyMath.PI や Main.PI は、他の参照方法に比べると一階層下がるので若干重いですが、100 万回もループしての結果なので、あまり気にする必要はないんじゃないかと思います。ただ、注意事項が一つありますので「色々な整数化手段での処理速度の違い」も目を通しておいて下さい。

if … else と switch での処理速度の違い

if … else 文は比較回数が少ない場合は軽いですが、比較回数が増えると switch 文の方が高速です。ただ、100 万回も処理させて数ミリ秒の違いですので、臨機応変に見やすい方を記述しておけば良いんじゃないかと思います。

色々な整数化手段での処理速度の違い

Math.floor() が重いのは周知の事実。ただ、ローカル変数に格納したもので計算した場合は軽くなりそうなものの、逆に重くなるというのは以外だったと思います。これは先の「変数を参照する際の処理速度の違い」で Math.PI のようなプロパティを変数に格納しておく Tips と反して、ビルトインクラスのメソッドは逆に負担になりますので注意が必要です。そして本題の整数化では、n >> 0 などのビット演算で整数化する方が多いのですが、int(n) の方が高速だし見やすいのでお勧めです。

Array, Vector 走査時のイテレーション方法による処理速度の違い

forEach は関数を実行するコストが掛かるのでやはり重いです。ただ、for each よりも for の方が高速なのは自分的にもビックリでした。倍速近い差が出るので、大量な処理の中で走査処理が必要な場合は for の方が良いかもしれません。もちろん、Array より Vector の方が高速です。

Array, Vector 走査時に加算を行う際の処理速度の違い

これももちろん、Array より Vector の方が高速という結果に。ただ、Vector の長さを固定している方が高速になるかと思いきや、固定していなくても参照速度に差はないようです。

オブジェクト生成による処理速度の違い

new Object() より {}、new Array() より [] が高速というのは周知だと思います。あと、Vector の長さを指定すると最初に要素の初期化処理が入るようで、生成コストが高くなります。あとは Sprite の生成コストは当たり前のように高いです。独自クラスの生成は、処理が少なければ Object を生成するのとあまり変わりません。

サイン・コサインの取得方法による処理速度の違い

予めサインテーブルを生成した後、ラジアンをテーブルのインデックスに変換して近似値を参照するというもの。かなりの高速化が期待できますが、取得できる値は近似値だという点に注意が必要です。3D での頂点処理などで大量のループ処理を行う際などに効果が期待できるかと思います。

今のところ試したコードはこんな感じです。これからも、他の最適化を思い付いたら wonderfl に投稿した後、ブログにエントリーしていきます。