非常に稀な状況でのことで申し訳ないですが、タイトルの通り、ローカルで再生する場合はリンケージしたシンボルの使い方によっては処理が遅く、重くなることがわかりました。ポイントは「最初のフレームに書き出しするか」です。

そもそもなぜこのような状況になったかと言うと、Flashでスクリーンセーバーを制作していた際にCPUとメモリを食い尽くされるという現象が現れ、リンケージシンボルのコンパイル方法をいろいろ変えてみたところ劇的に改善したといういきさつがあります。

容量が巨大なFlashではユーザを楽しく待たせるために必要になるローディング機構ですが、この機構を実装したFlashをローカルで再生した場合に処理がかなり重くなってしまいました。いろいろ原因を探った結果、リンケージ設定の仕方によって差が出る(らしい)ことがわかりました。

  1. 「最初のフレームに書き出し」のチェックを外すタイプ
    弊社kijimaの記事
    のタイプで、リンケージ設定したシンボルのインスタンスを2フレーム目以降に置き、1フレーム目にはLoadingのアニメをするMovieClip等を置くタイプ。
  2. 「最初のフレームに書き出し」のチェックを入れるタイプ
    単純にリンケージし、最初のフレームでコンパイルしてしまうタイプ。

この2つをローカルで再生した場合、処理が重かったのが1です。例えば1280*960pixレベルの画像を10枚、BitmapDataをスーパークラスとしてリンケージします。1の場合は2フレーム目に10枚置いといて1フレーム目にはLoading_mc。2の場合は自動でコンパイルされるのでステージには何も無し。

この2つを再生したところ・・・なんと5秒ほどの差が初動で現れました。PCのパワーによって違うとは思いますが、かなりの過負荷ではないでしょうか。

ブラウザ上での再生がメインストリームなFlashですが、最近はAIRのようにローカルでの起動も少なくありません。どうも起動時の処理が重すぎるなぁ・・・とお悩みの方はリンケージ設定とローディング処理を見直してみてはいかがでしょう。

(文字ばかりでごめんなさい><;)

HTML5飯