こんにちは

カヤックモバイル＄のアラガです

先日「デコメ８０取放」に「デコメ絵文字作〜る」という開発者もユーザーもモーレツにガンバルFlashLiteで作ったコンテンツをオープンさせました。

「デコメ絵文字作〜る」って何？というのを説明しますと、携帯電話でピコピコして20x20dotで最大10フレームのアニメーション絵文字を作ることが出来るコンテンツです。

今までもアプリでは沢山絵文字作成ツールはありましたが、アプリだと３キャリア分開発しなければならないので、思い切ってFlashで制作してみました。

さて、ユーザーがガンバル携帯Flashでは、一般的なPC向けのFlashや待ち受けFlashの制作では想像もしないような落とし穴が沢山あります。

今回は沢山ハマった中から、厳選した７つの落とし穴を紹介いたします。

１．誰も教えてくれないPOST出来るデータ量の制限

な、なんと！携帯各社のドキュメントにはどこにも出てこないのですが、携帯からPOSTする際のデータ量には限界がありました。

この事実に気づいたときには愕然としました。サーバー側のAPIもFlashの実装も半分くらい終わっていたため、大幅な仕様変更を余儀なくされたのです。

さて、ケータイでPOSTする際のデータ量ですが、だいたい 1.5〜2K以内で押さえればほとんどの機種でPOSTできます。自信が無いのでやや曖昧な表現とさせていただきました。

２．ループでメモリオーバーってウソっすよね？

PCだと想像できないことですが、400回程度のfor文やwhile文でも油断するとメモリオーバーにすぐになります。

ループでメモリオーバーの問題はDeviceCentralなどのエミュレーター上では再現されず、携帯で使ってみないと確認できないので脅威的です。

例えば下記のようにする等して、がんばってがんばって対応して、あとはガクガクブルブルしながら実機で使ってみましょう。

普通の処理

var _yLine:Number = 0; var _xLine:Number = 0; var pixColor:String; for (var i:Number = 0; i < 400; ++i ) { _yLine = Math.floor(i / 20); _xLine = i - 20 * _yLine; pixColor = "0x"+getColor( i); targetMC.beginFill(Number(pixColor)); targetMC.moveTo(_xLine,_yLine); targetMC.lineTo(_xLine,_yLine+pixelSize); targetMC.lineTo(_xLine+pixelSize,_yLine+pixelSize); targetMC.lineTo(_xLine+pixelSize,_yLine); targetMC.endFill(); }

参照をまとめて最適化

var _yLine:Number = 0; var _xLine:Number = 0; var pixColor:String; var PRERIX_HEX:String = "0x"; var PIXCEL:Number = pixelSize; var UNIT20:Number = 20; var LIMIT_LOOP:Number = 400; var i:Number = 0 for (i; i < LIMIT_LOOP; ++i ) { _yLine = Math.floor(i / UNIT20); _xLine = i - UNIT20 * _yLine; pixColor = PRERIX_HEX+getColor( i); targetMC.beginFill(Number(pixColor)); targetMC.moveTo(_xLine,_yLine); targetMC.lineTo(_xLine,_yLine+PIXCEL); targetMC.lineTo(_xLine+PIXCEL,_yLine+PIXCEL); targetMC.lineTo(_xLine+PIXCEL,_yLine); targetMC.endFill(); }

これで300%くらい最適化できます。この他にも上記の例だと、

• ・endFill、beginFillが結構コストのかかる処理なので、必要最小限にする。
• ・forループの処理をタイマーやEnterFrameを使って一回の処理を分割する

など少しずつ試して最適化します。

３．loadVarsで取ってきたデータがFlashのサイズを蝕んでいく

ケータイFlashのサイズは100kまでというのは有名な話ですが、100kとはコンパイルしたswfのサイズだけではありません。

loadVarsで取ってきたデータのサイズやFlashでの処理中に変数にセットされるデータ量など、表示されている間に追加されるすべてのデータサイズを足したサイズが100kまでということです。
もし１００k超えると、とたんに悲劇が起こります。

したがって、ガンバル携帯Flashではロードするデータ量もしっかり考慮しなければなりません

「デコメ絵文字作〜る」では20x20dot x 10 フレーム 分のデータサイズ等諸々を考慮して初期サイズが50kを超えないように注意して作成しました。

４．loadVarsでPOSTできないという衝撃

さぁ、だいたい機能の実装はおわりました！

しかし、ケータイの場合はココからが勝負です。docomoでは動いたのにauでは動かない。いや、auのある機種では動いたのにある機種では動かない。。。

そう、この戦いは延々と続きます。

この機種依存の中で最も厄介なのが、loadVarsでPOSTできない機種が存在する
これはGETを使うことで対応できますが、GETにすると一度に転送できるデータは2kからさらに減少することになります。
携帯Flashでは通信するためには何らかのユーザーアクションが必要なため、ユーザーアクションをむやみに増やせないという理由から、「デコメ絵文字作〜る」は申し訳ないですが、POSTできない端末は、非対応機種とさせていただきました。

５．突然電話がかかってくる恐怖

長い戦いもほぼ終わり、もう大丈夫だ！テストもばっちりだ！！
よし！自分のケータイで使ってみよう！！！

と、その時悲劇は起こります。

「ﾌﾟﾙﾙﾙﾙﾙ........」電話です。
通話終了。

するとなんと！flashの状況が起動ホヤホヤに戻っているではありませんか。。。

そう、全ての機種でおこるかどうかはわかりませんが、Flashで作ったコンテンツは突然の電話やメールによって初期化されるのです。
これはガンバルFlashでは致命的です。ユーザーががんばった分が台無しになってはブチギレされてもいいわけできません。

というわけで。ローンチ間近にまさかの追加機能の実装を余儀なくされます。

さてこの対策ですが、以下のような対策である程度カバーできますが、完全にカバーするのは非常に難しいと思います。

• ・大きなデータは適宜サーバに転送し保存する
• ・フラグで済むような状態はローカルのSharedObjectなどに保存する

６．突然ネットワークが切れる悪夢

何もかも問題なく完了した。苦しかったけどがんばった！後はテストあるのみ！！
よし！通勤の時間もテストしよう！！！

そんなわけで、朝、鎌倉へ向かう横須賀線車内でもテストをしていました。
そんな中、北鎌倉〜鎌倉間で悲劇は起こります。
「トンネル」です。
ケータイでは突然ネットワークがつながらなくなることがあるのです。

この瞬間ネットワークチェックが甘いFlashだと、ひたすらサーバーからのデータを待つだけの悲しいFlashとなり、腑抜けで使えない奴に成り下がります。

「絵文字作〜る」も当初、Flash起動時しかネットワークの接続チェックをしていなかったので、起動後のネットワーク切れによるバグが発生しました。

携帯のネットワークは、いつ何時でも突然出来なくなると思って実装しましょう。

７．決別しよう動かない機種達

さあ、ココまでがんばってローンチすると、見たことも聞いたこともない機種から次々と動かないよとか、不具合の報告が訪れます。

もうココまでくると全ての機種でテストすることは不可能です。

機種の発売日とスペックを確認して、普及度が少ない機種は、迷わず非対応機種としてしまうことも大切な勇気です。

また、ガンバルFlashを作るためにはFlashLite2.0以上にして最初からdocomo904以前を捨てる勇気も大事だと思います。

まとめ

ガンバルFlashLiteを作るときは実装に入る前に以下のことに注意しましょう。

1. POSTするデータが2kより大きくないか？大きいときは分割してPOSTさせる工夫をしましょう
2. 危険なループ処理はないか？ループを作るときは変数を減らす、ある程度で次のフレームに処理を移行するなど対策を頭に入れておきましょう。
3. サーバーからロードさせるデータサイズが大きすぎないか？どうしてもサイズが100kをオーバーする場合は、リロードしましょう
4. ローンチの前に多数の機種でテスト出来るような環境（大量の端末かテストセンターなど）を余裕を持って用意しておきましょう
5. Flashが突然初期化されることを頭に入れて、localのSharedObjectやサーバーにデータを保存しておく機能を実装しましょう
6. ネットワークはいつでも切れます。通信を行う処理はいつネットワークが切れても対応できるようにエラー処理をしっかりしましょう
7. 動かない機種はあきらめましょう。そのためにはサーバーで特定の機種を非対応機種として扱う仕組みは必ず作っておきましょう。

FlashLite3.0の登場から１年が経過しました。そろそろFlashLite1.1を無視してケータイでアプリ並みにがんばるFlashも続々と登場することかと思います。

そんな時に「しまった！！！」と泣く前に、何かの参考にしてもらえると幸いです。