December 2008

removeChildとvisibile=falseが、
他に与える実行速度の影響をテストする小さなサンプル結果で、
それほど差がないとの記事を読んだ事がある。

じゃぁ、コンストラクタで、
必要になるすべてのDisplayObjectをaddChildし、
visible=falseで消してしまえとなんて安易に考えたりしてしまう。

ガーベージコレクションの対象にさせたい場合は、
当然、removeChildしか考えないから問題ない。

単純な例として、
10000個のDisplayObjectインスタンスを常に保持していて、
10個のみのDisplayObjectを画面上に表示し、
containsプロパティを調べ、
各深度を更新するようなプログラムの場合についてはどうか？

for(var i=0 ; i<target.contains.length;i++){
 setChildIndex(target.contains[i] , something);
}

この場合、visible=falseは、良くない。
removeChildしておいた方が、当然軽い。

DisplayObjectのvisibleプロパティは、
ただ単にそれ自身のプロパティを変更するだけに対し、
DisplayObejctContainerのremoveChildメソッドは、
そのDisplayObjectContainerが保持するプロパティも、
変更するという点を、意識して使い分ける必要があり、
これが、プロバティとメソッドの違いの特徴とも言える。

以前再帰による幅優先探索を紹介したが、
迷路が巨大になると、
スタックオーバーフローの問題に突き当たる。

再帰が駄目なんじゃなく、お前の再帰関数が駄目なんだよ、
とか言うけど、無視して、
この場合、再帰を使用して幅優先探索を実装することは、
向いていないと言わせてください。

解決策として、再帰では無く、
do whileのループを使用する方法が考えられる。

ただ、ループの上限を設定しない場合、
その他のプログラムの実行速度や描画に影響を及ぼす。

下記のようにループに対して、
最大ループ回数を設定し、
タイマーを使うことで、解決できる。

private var currentCount:uint;

private var searchRetryTimer:Timer=new Timer(100,1);

public function search(maxLoopCount:uint=1000){
     do{
       currentCount++;
       if(currentCount>maxLoopCount){
        searchRetryTimer.start();
        return;
       }
       checkGoal();
     }while(!founded);
    
     callBack.apply(scope , [goalInfo]);
}

private function onSearchRetryTimer(evt:Timer):void{
      search();   
}