« 遅延確保と明示的解放 | メイン | 気になる挙動を調べてみた »
2012年04月11日
吉里吉里Java:: 吉里吉里Java/KAG3 のメモリ消費量
Tweet @jin1016をフォロー吉里吉里Java の実際の使用量だが、吉里吉里Javaで KAG3 のバイトコードを読み込んで動作している段階で、Javaヒープは約10MB使われている。
SurfaceView のみで起動するだけでも、ネイティブヒープは約4.2MB必要。
トランジションや Layer.piledCopy を使用した時、そのベースとなったレイヤーと同サイズのキャッシュ領域が内部に作られる。
キャッシュ領域は、一時的なもの( 設定によって毎回削除しないようにする事も可能 )ではあるが、キャッシュ領域が必要となる機能を使う場合、このサイズも考慮に入れておく必要がある。
LayerManager はレイヤー合成に必要な領域を持つ。
この領域は画像演算の分割処理の指定によってサイズは変わるが、現状吉里吉里Javaでは画像演算の分割処理をなしにしているので、プライマリレイヤーと同じサイズ確保される事になる( レイヤー合成は画像演算の分割処理を考慮した作りとなっているが、現状トランジションはこの辺り考慮していないため )。
後、プライマリレイヤー1枚は最低必要となるだろうから、オフスクリーン、キャッシュ、合成領域、プライマリの4枚分最低限必要となる(トランジションと Layer.piledCopy を使わないのであれば、キャッシュ領域は不要)。
800x480 で 32bitカラーで計算すると 800x480x4x4 = 約6MB
ここまで合計すると約20.2MBは必要になる。
アプリケーションヒープが24MBの機種で動作させるのは KAG3 を使わなくても相当きついことがわかってくる。
KAG3 では、さらに最低でもヒストリーレイヤー、プライマリーレイヤーの裏 で約3MBは必要になる。
これで23MB。
そのままでは立ち絵やメッセージを出したらメモリが足りなくなる可能性が濃厚。
追加した purgeImage で普段は必要のない ヒストリーレイヤーと裏にあるレイヤーの分を解放しておけば、この分は必要なくなる(使用時は必要になるので、その時の検討は必要)。
トランジションを使わないようにすれば、キャッシュ領域が作られないので、その分使用量を浮かせられる。
黒一色のレイヤーにα値を変化させながら合成すれば、フェードアウト/インするトランジションが出来るので、キャッシュ領域を使わないトランジションが出来る( base に画像、その上のレイヤーに黒一色でα値を変化させるレイヤーを置く形。遅延確保によって単一色レイヤーをメモリ確保せずに実現できる )。
また、完全に画面が消えた時に、バックで表に画像を読み込むことになるので裏面も不要になる。
メッセージレイヤーは、そのサイズ分と文字描画用のレイヤーがメッセージレイヤーの幅+8 x 高さ+8 分使われる。
また、リンク等のハイライトでメッセージレイヤー幅 x 文字高さが使われる。
このため無駄なメッセージレイヤーは出来るだけ作らないようにし、初期サイズも出来るだけ小さくしておいた方が使用メモリ量は少なくて済む。
メッセージレイヤーにフレーム画像を使わないようにして、purgeImage して単一色で塗ればメッセージレイヤーのベース部分のメモリが浮かせられる。
この辺りの工夫を入れる事で、見栄えは少し劣るが 24MB で動作させることも不可能ではなくなるはず。
3.0 以降は largeHeap を使って PC と遜色ない作りにして、それ未満は少メモリ版とする対応もありかもしれない。
数年で 4.0 が普及する事を見込んで、largeHeap 使う前提で作るという手もあるが。
投稿者 Takenori : 2012年04月11日 17:13
comments powered by Disqus