Pex Textbook 1.1.0 documentation

フロントエンド合成で高画質化と起動高速化を実現する

«  Talk シーンの SWF 仕様   ::   Contents   ::   制作のコツなど  »

フロントエンド合成で高画質化と起動高速化を実現する

Pex の機能を活かし SWF と画像、パラメータをそれぞれ別個に配信し、 クライアント側で組み立てを行うことで従来のサーバ合成に比べ、大幅に起動速度が高速化され、 また画質を高めることも同時に可能となります。

これをフロントエンド合成と、ここでは呼んでいます。

今までサクサク感を妨げていた原因は何であったのか解説を行い、 Pex を用いてそれらのボトルネックを回避する方法を以下に説明します。

従来方法との比較

フロントエンド合成を用いて作られているコンテンツも既に存在し、Android 2.2 から iOS に至るまで広く実績があります。 以下は「怪盗ロワイヤル SECRET POKER」のバトル部分に iPhone4 + iOS6 3G network でアクセスした際のタイムラインです。

_images/frontendcomposed_cached_timeline.png

バトルやミッション、あるいはガチャのように繰り返し SWF 再生を行う箇所では上記のように SWF、画像ともブラウザキャッシュの利用を期待でき、タイムラインが示すようにキャッシュヒット時は瞬時に SWF 再生がスタートします。

_images/frontendcomposed_timeline.png

キャッシュヒットが無い場合でも従来と比べ大幅に起動の速度を体感できます。 (Transferred に 1.39MB が記録されていますが gzip 圧縮がかかっている為、実際の転送量は 158KB に収まります)

同じコンテンツを、サーバ側で動的に合成した場合を考え あらかじめ SWF に画像を埋め込んだ方式で再生すると、下記のようなタイムラインを示します。

_images/mingswf_timeline.png

このように、サーバ側で SWF を動的に合成する手法はブラウザ側での実行負荷を高めることになり、 コンテンツのサクサク感を大幅に減じています。

また、コンテンツの高画質化を行う為に同梱されている画像の解像度を上げると更に再生までの待ち時間が伸びるといった サクサク感とコンテンツ品質のトレードオフを生み出す原因にもなっています。

待ち時間の発生要因と解決策

サーバ合成コンテンツの待ち時間

前述のサーバ側で SWF 合成を行った際のタイムラインを眺めてみると SWF のデータサイズ 348KB に対して Duration 32.73sec と、ダウンロードに要する時間以上の何らかのコストが発生していることが分かります。

これは - SWF のパース処理 - SWF に同梱される画像の処理 両方によるもので、特に後者、画像処理のコストが大きな遅延要因となります。

黄色のバーの下部に示される紫のバーが画像処理時間の経過を示しており、バーの表示はひとつですが、実際は複数点数の画像処理がここでは行われています。

画像処理に要するコストは SWF に同梱される画像の点数とデータ量に比例します。 また JPEG より PNG, GIF のようなビットマップで顕著に表れ、画像データを多く埋め込んだ SWF であるほど起動までの所要時間が大きくなる傾向があります。

Pex ではこの二つのボトルネックを回避する術をそれぞれ用意しており、大幅に起動時間を短縮出来ます。

SWF パース処理遅延の解決

parse_swf を用いて SWF に換えてプリコンパイルした JSON を用いることで、SWF の処理にかかる時間を割愛することが出来ます。 メリットとしては起動速度の高速化があり、体感で感じる程度の(100-200ms)差異をもたらします。

後述の画像処理遅延の解決をまず優先して行い、サクサクの体感を作りたい時に本対応を試して頂くと効果を感じて頂けると思います。

尚、SWF をテキストデータに展開するため、ファイルサイズが 5 倍程度に膨らむことがありますが、HTTP の圧縮転送を利用することで転送時のファイルサイズを元 SWF に近づけることが出来ます。

詳しくは別途配布しております API ドキュメントの parse_swf の項目をご覧ください。

画像処理遅延の解決

SWF に画像が含まれているとその画像をデコードし、ブラウザに適した形にエンコードし直す処理が発生します。 この画像処理コストが起動時間に於いて大きな割合を占めていました。

Pex ではこれを、API により外部から画像を SWF に差し込める機能を提供することで解決しています。 画像を別個に渡すことで上記のようなデコード・エンコード処理が不要となり、かつブラウザキャッシュの利用や、遅延ロードのようなテクニックも利用可能になります。

例えば強化合成等の表現で準備画面 → Flash 演出画面として遷移する場合など、準備画面にてキャラクタ画像を読み込ませ、次の Flash 演出画面で同じ画像を利用することで高画質画像を利用しながら起動体感を損なわないアニメーション設計が可能になります。

詳しくは 画像の差し込み/置換を行う の解説を御覧ください。

«  Talk シーンの SWF 仕様   ::   Contents   ::   制作のコツなど  »