client (flash) performance tuning
TRANSCRIPT
クライアント（Flash) の
パフォーマンスチューニング
第2回 CAグループ合同勉強会
Shinji Hiramatsu
GCREST, Inc.
自己紹介
l 平松 慎司 （[email protected]）
l 所属
株式会社ジークレスト ポータル事業部システムクリエイティブグループ
l 普段やっていること @gamesのセルフィテーマエリア クライアント全般の技術支援
l 過去の開発実績 InDesign, Photoshop Elements, PageMaker,
Flash Text Layout Framework, AozoraBookself etc.
アジェンダ
l パフォーマンスチューニングの必要性
l パフォーマンスの問題箇所の特定
l チューニングの実作業
l 最後に
パフォーマンスチューニングの必要性
ユーザーが快適に使えるサービスを提供すること。
l なぜ必要？
l その為には？
l もし行なわなければ？
ユーザーが不満を抱え、離れていきます。
１msecでも処理時間を減らす努力の積み重ねです。まさに真剣勝負の戦いです。
l 徐々に処理が重くなる
パフォーマンス問題の症状
メモリリークの可能性大
l 何かのタイミングで処理が重くなる
通信処理、ファイルI/O
l 常に重い
EnterFrame/Timerで重い処理（描画or通信?）
l 起動が遅い
GraphicsDataが重いor 読込みファイルが多い？
l Flash Builder プロファイラ（Premium版のみ）
メモリの使用状況／関数の処理時間の確認
メモリリークの検出
チェックツール
l Webブラウザの開発ツール
ファイルロード時間の確認、アクセスエラー確認
l コード埋め込みプロファイラ
独自に必要とする情報取得に有効
l Telemetry/Monocle（2012年リリース予定?）
Flash Playerの内部に搭載されるコンテンツ再生中の詳細を報告してくれる機能
チェックツール
→ 今まで公開されていなかったFlashの内部の動きが分かるようになるかも...
l 通信処理の最適化
l ファイルI/Oの最適化
l メモリ使用の最適化
l EnterFrame/Timerの処理の効率化
l 再描画処理の最適化
チューニング対象
内部構造変更なしのチューニング
l グラフィックデータのサイズダウン
l グラフィック内のalpha値の使用を制限する
チューニング作業 第１段階
見た目で分からないレベルで品質を落としてサイズダウン。
PNG32->PNG8の場合、約1/3程度となる。
Flashのレンダリング処理を少しでも軽くする為。
内部構造変更なしのコードチューニング
l デバッグ用のtrace文をコンパイルオプションで囲む
× trace(“Show message!”);
○ CONFIG::DEBUG // デバッグ用コンパイラオプション { trace(“Show message!”); }
→trace文は、リリースビルドの場合、コンソール出力をカットするだけで、
文字列を生成する処理は除外されない為、コンパイルオプションで認識さ
れないようにする。 （５～15%のパフォーマンスが向上する可能性あり）
チューニング作業 第２段階
基本的なコードのチューニング
チューニング作業 第３段階
l Object型／*型を使用しない。型宣言したクラスを必ず使用する。
l 配列クラスはVectorクラスを使用する。ArrayクラスよりVectorクラスの方が速い。
l 使い終わったインスタンスの変数は必ずnullを設定する。メモリリーク回避の為。
基本的なコードのチューニング
ビット演算を使用する
l ２の累乗の掛け算は左ビットシフトを使う
l ２の累乗を割り算は右ビットシフトを使う
value = 4 << 1; // = 4 * 2
Value = 4 << 2; // = 4 * 4
value = 4 >> 1; // = 4 / 2
Value = 4 >> 2; // = 4 / 4
チューニング作業 第３段階
基本的なコードのチューニング
l ループ処理内で他クラスの定数参照を行なう場合はローカル変数に値を代入してから参照する。
チューニング作業 第３段階
△ var value:int; for (var i:int = 0; I < 10000; i++) { value = UserClass.DEF_CONSTANT; // ß }
○ var value:int;
var myConst:int = UserClass.DEF_CONSTANT; // ß （ループの外） for (var i:int = 0; I < 10000; i++)
{ value = myConst:int ; // <- }
描画コードのチューニング
l 複数の元画像データが同じBitmapデータを作る時は、１つのBitmapDataインスタンスを共有する。
チューニング作業 第３段階
var bmImage:BitmapData = new BitmapData( 20, 20, false, 0xFFCC00); myContainer:Bitmap; for (var i:int = 0; i < 500; i++) {
myContainer = new Bitmap( bmImage ); addChild( myContainer );
}
上記の例は、BitmapDataを個別に500個作る場合に比べて約1000KBの削減となる。
描画コードのチューニング
l 複数の同一MovieClip(SWF)を使う場合は、loadBytesによるバイナリデータのロードを利用する
チューニング作業 第３段階
Private var _binaryData:ByteArray; // バイナリデータの確保場所を宣言 // URLのリクエスト var loader:URLLoader = new URLLoader(); loader.dataFormat = URLLoaderDataFormat.BINARY; // バイナリ読み込み指定 loader.addEventListener(Event.COMPLETE, completeLoadHandler);
loader.load(new URLRequest(url);
Private function completeLoadHandler(e:Event):void // 読み込み完了時 {
var loader:URLLoader = e.target as URLLoader; _binaryData = loader.data as ByteArray; // バイナリデータのセット
｝
var loader:Loader = new Loader; loader.loadBytes( _binaryData ); // バイナリデータからMovieClipの読み込み
描画コードのチューニング
l 複雑な表示データオブジェクトのマウスイベントの反応が遅い場合は、マウスクリック識別用のSpriteオブジェクトを利用する
チューニング作業 第３段階
内部構造の変更を伴うチューニング
l 同じ処理のコードを共有化
コード量のサイズダウン
l 非同期処理の最適化
オブジェクト単位で並列処理可能な構造にする
チューニング作業 第４段階
内部構造を伴うチューニング
チューニング作業 第４段階
l 複数の画像データファイルを１つのSWFにまとめる。
bridge.png
chair.png board.png
tree.png bridge.png
chair.png board.png
tree.png
mapItems.swf
内部構造を伴うチューニング
チューニング作業 第４段階
l SWFを複数に分割することで読み込みから起動までを高速化できる。起動時にすぐに使用されない機能を分割する。
->重複した機能がダウンロードされないようにRSL(Runtime Shared Library)を使って共有部分を先にロードするような構造とする。
ユーザーが体感上速く感じる見せ方
チューニング作業 おまけ
l 画面の切替でフェードアウト/インを使う
l 重い画像の場合には、同じ画像で画質を落とした軽い画像の２枚を用意して、先に軽い画像を表示して、裏でフル画像をロードし、完了したら差し替える方法もある。
実質的にはフェードの処理に時間が多少かかるが、画面上の変化により、体感的には早く感じる。
l パフォーマンス改善は、地道な努力の積み重ねであり、改善方法はまだ様々あります。
l 興味がある方は、是非独自のパフォーマンス改善の方法を見つけて、共有して頂けると幸いです。
よろしくお願いします。
最後に
ご清聴ありがとう ございました！！
Q & A