動画関係はかなり制約が多い。
レイヤーモード実装前程度の機能になっている。
詳細はプロジェクト Wiki の方にまとめている。
完全なレイヤーモードは実現が困難だが、動画の前にレイヤーを表示する事は可能なので、レイヤーモードにすると動画の前にレイヤー群が表示されるようにしている。
レイヤーモードの主な使い方は動画にメッセージレイヤーを重ねて動かすことだと思うので、そのような用途は何とか出来るはず。

サウンドもいろいろ制約があるが、ループチューナーを使用していないのであれば、制約は比較的少ない。
ただ、サンプルデータ取得が出来ないので、口パクとかする時は現状困る。
事前にデータを生成して音声の再生と同期出来るような形のものを実装しないといけない。

最適化は主に TJS2 のコンパイルの高速化と KAG パーサーの高速化、KAG バイナリ形式のサポートを行う予定。
TJS2 のバイトコードだけでなく、KAG3 もバイナリにして読み込みを早くする。
他にも細々としたところで最適化してもう少し起動を速くしたい。

メニューボタンを押すと表示され、タップで選べる。
バックボタンで階層を戻れ、メニュートップの時はメニューを閉じる。
表示中メニューボタンを押すと閉じる。
メニューで下位の項目がある場合は「＞」が末尾に表示される。

画面に対して項目が大きいのは指で押す事を考慮しているため。
これより小さいと少し押しづらい。
高さが 50dip 以上になるようになっている (解像度に合わせたサイズになる) 。
高さを 50dip で割った数が縦方向の項目数となる。
割った時の余りは各項目に分散される (上の方の項目が 1px大きくなる可能性がある) 。
幅は、その階層で表示されるメニューの文字の幅によって計算される。
文字数が少ないと、次の画像のように横の項目数が増える。

横方向の項目数は、その階層のメニューの最大幅で画面幅を割った数で計算される。
1未満になる時は、1になる。
1になった時で、文字が幅を超える時はそのメニュー文字列はそのメニューに入るように文字が削られ末尾に「…」が付与される。
1画面内にメニューが入りきらない時はメニュー末尾に「▽次へ」が挿入され、そのメニューを押下する事ではみ出てメニュー項目を表示するメニュー表示に切り替わる。
2ページ以降では、最初に「△前へ」が表示され、前のメニュー項目に戻れるようになっている。
セパレータは非表示で、その項目自体ないものとして扱われる。
チェックがある場合は以下のように表示される。

ラジオボタンは次のように表示される。

文字、背景、線の色はリソースの colors.xml で指定可能になっている。
文字、背景は通常、押下、無効の3種類定義してある。

メニューボタンを搭載しない場合、画面下部にメニューを表示しないように AndroidManifest.xml の targetSdkVersion で API Level 11 以上を指定したときのことを考慮し、Window.showMenu() を追加する。
これによってメニューボタンを押してメニュー表示した時と同じ動作をする。
API Level 11 以上を指定し、メニューを使用する場合は、画面内にこのメソッドを呼び出すボタン等を配置しておかないとメニューでのみ実現している機能があるのなら、その機能を呼び出す事が出来なくなってしまうので注意する必要がある。

なお、矢印キーでの項目選択やEnterでの選択は現状実装されていない。

dm("■lay:"+lay); で、lay がないと言われて例外発生。

このように記述すると問題なく動作する。

dm(p); での p の値が不定。

3個目の変数アクセスの方は比較的簡単。
中かっこのない if 文はスコープをネストしないので、var で変数宣言したら上位のスコープと思えるスコープに変数が作られる。
で、dm でアクセスした時、変数はあるが初期化されていないので、未初期化変数へのアクセスとなり、値は不定。

1個目の挙動は少しやっかい。
バイトコードを出してみると、delete は通らないし、デバッガで追ってみても通らない ( そもそも delete のコードは出力されない ) 。
例外が発生するのは、dm("■lay:"+lay); で lay へのアクセスが、proxy(this or global) のメンバ lay へアクセスしようとしてメンバが見付からないところ。
なぜここでローカル変数へのアクセスではなく、メンバアクセスになっているか。
ローカル変数に対する delete がどのようになっているかを調べると、処理はコンパイル時に行われていた。
ローカル変数に対する delete のバイトコードを作るところで、ローカル変数の lay が削除されてしまうので、dm("■lay:"+lay); ではローカル変数の lay は消えているため、メンバアクセスになっている。
そして、これはコンパイル時に行われるため、if 文は関係なく、単純に前にあるか後ろにあるかによって変数があったり、なくなったりする。

2個目がなぜ通るのかと言うと、上述の処理を見ればわかる。
if 文のスコープ内にある lay 変数は削除されるが、それより外のスコープの lay は削除されず、ローカル変数へのアクセスとして解釈されて、期待通りの動作をするはず。
これは実際に処理を追ってないのである程度推測。

動作はいいとして、ローカル変数への delete はこのような仕様であると認識して使わないと意図しない記述をしてしまいそう。
と言うか、ローカル変数を delete すること自体が問題の種か。
まあ、ローカル変数を delete しようとした事はないが。
中かっこのない if 文の方は、そんなことしないから気にする必要ないと思うけど。

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 使う前提で作るという手もあるが。

一つは遅延確保で、実際にそのレイヤーが描画される時、もしくは画像が読み込まれた時まで、メモリを確保しない。
オリジナルでは、setImageSize 等されると、その時点でそのサイズ分のメモリが確保されるが、Android ではこの時にそのレイヤーでまだメモリ確保されていないのであれば、この時点ではまだメモリを確保しない。
また、描画時も未確保のレイヤーを確保済みのレイヤーに描画する場合、単一色で塗りつぶす処理を行い、メモリ確保は行わない。
一種のシェイプ、もしくはカラードポリゴンのように扱われる。
ただ、状況によってはメモリ確保されるケースもある。
逆に描画される側の場合は必要なので、その時点でメモリ確保される。
未確保のレイヤーの全体を fill した場合、未確保のままで色を指定できる。
つまり、未確保のレイヤーはサイズと色を持った矩形のように扱われる。

レイヤーに purgeImage というメソッドを追加して、保持している画像のメモリを明示的に解放する処理を追加した。
KAG3 にある freeimage は、レイヤーと画像サイズを 32x32 に縮小するが、ピクセルデータが完全に未使用になるわけではない。
32x32 であれば、4KB 程度なのであまり大きくはないが、なくせるのならなくせた方がいい。
また、purgeImage はピクセルデータは解放するが、画像サイズは維持する。
ただ、吉里吉里2 はCopy-On-Writeで画像を共有しているケースがあるので、共有されている場合はピクセルデータは解放しない(すると他で壊れる)。
と書いたが、purgeImage が呼ばれた時に明示的に共有解除してしまった方が良いかもしれないので検討する。

レイヤーを非表示にした時に、内部で purgeImage をコールして、非表示にしたレイヤーのピクセルデータを破棄してしまうようにしたが、これは好ましくない状況もあると思うので、オプションで切り替えられるようにしようと思っている。

互換性を気にしないのであれば、複数の形状のシェイプや画像のタイリング等を加えれば、使用可能な状況ではメモリ使用量を削減できるが、UI やメッセージレイヤーなど結構限定されるので、無理をしていびつな形で入れるのは避けることに。

SurfaceView を使うのが一番使用メモリ量が少なそうだ。

これらのサイズは画面サイズが異なると当然使用量に変化が出ると考えられる。
実際、EeePad transformer TF101 (1280x800) では、SurfaceView のみの起動で 約9MB使われていた。

検索したところ Xperia Arc の VRAM はメインメモリと共有のようだ。
GLSurfaceView にして、テクスチャに転送しても使用メモリ量が減らなかったり、GLSurfaceView でも差がないのはこの辺りが原因だろうか？ 詳しくは調べていないが、使用メモリ量が減らない機種があるのなら、GLSurfaceView に対応してもあまり意味はなさそうだ。
将来的に選択可能になっていても良いとは思うが。

吉里吉里Java では、オフスクリーンバッファを使用している。
SurfaceView は、ダブルバッファリングを使って描画しているので、フリップすると1フレーム前の画像が入っているため差分描画を行う吉里吉里Java(オリジナルと同じ)だとうまく描画出来ない。
Android 側のソースをざっと見たところ SurfaceHolder.lockCanvas( Rect dirty ) で、dirty を指定すると、フロントバッファから dirty 以外の領域をコピーして、Canvas の clipRect に dirty が指定された Canvas が返って来る。
Surface.unlockCanvas でロック解除するとフリップを行わずにロック解除されるようだから、差分描画の1回目に dirty rect を指定しフロントバッファから変更しない部分をコピーして、差分描画し2回目以降は、dirty rect に null 指定して全体を更新する指定してコピーしないようにすることでオフスクリーンバッファを使わないように出来なくはない。
( 実際にこのような挙動になるのかどうかは動作させて確認をしたわけではないので、もしかしたら違う挙動かも知れない )
ただ、吉里吉里Java でゲームのサイズと画面サイズが異なり、拡大縮小が必要となった時差分描画で誤差が出て隙間が出来てしまう可能性がある。
オフスクリーンバッファで画像を保持しておいた方が良い局面もあるので、結局オフスクリーンバッファを使用するのが無難な実装だと考えられる。

SurfaceView でオフスクリーンバッファを使うと言う、元々の実装がやはり良さそうと判断した。
最終描画周りで使用メモリ量を削減できないかいろいろと検討したが、この辺り削るのは難しそうだ。

ネイティブヒープ + Java ヒープ の合計サイズというのは、Debug.getNativeHeapAllocatedSize() + (runtime.totalMemory() - runtime.freeMemory()) で計算できるサイズのようだ。
この合計値がアプリケーションヒープの最大値を超えた時 OutOfMemoryError 例外が発生する。
アプリケーションヒープの最大値は ActivityManager.getMemoryClass() で得られるもののようだが、runtime.maxMemory() と同じ (単位は異なる) ようなので、runtime.maxMemory() で計算できる。
ActivityManager の方は Context が必要なので、Runtime で得られる方がいろいろと扱いやすい。
つまり、擬似コードで書くのなら以下のような感じ。

Runtime runtime = Runtime.getRuntime();
if( (Debug.getNativeHeapAllocatedSize() + (runtime.totalMemory() - runtime.freeMemory())) > runtime.maxMemory() ) {
　throw new OutOfMemoryError();
}

この辺りがわかるとメモリ限界付近を調査しやすくなる。

Android 3.0 ( APIレベル11 ) から AndroidManifest.xml の application に android:largeHeap="true" を加える事でアプリケーションで使用するHeapサイズを拡大できるが、このサイズは 256MB 辺りのようだ。
上述のページや他のページ、手持ちの TF101 で調べたところ GalaxyNexus、Motorola Xoom(MZ600)、EeePad transformer TF101 で 256MB ということなので、256MB は使えるのではないかと思われる。
調べた範囲では、最低どの程度なのかという仕様は見あたらなかった。

なお、所有端末やネットで調べた範囲だと、アプリケーションヒープは以下のサイズのようだ ( largeHeap指定がない場合 ) 。
Xperia 24MB
Galaxy TAB 48MB
Xperia arc 32MB
IS03 40MB
EeePad transformer TF101 48MB
Galaxy S2 70MB
MEDIAS N-06C 30MB
NEXUS ONE 24MB
NEXUS S 32MB
ATRIX 4G 32MB
IS01 24MB
Optimus chat (L-04C) 24MB

使用する Project Build Target を Android 2.2 API Level 8 以上にする。
古いバージョンでも動作させたい場合は、AndroidManifest.xml に <uses-sdk android:minSdkVersion="4" /> 等指定する。
また、使用している API がここで指定したもの以下であるようにする。
Project Build Target で新しいバージョンを指定すると新しいAPIを使用していてもビルド自体は問題なく通るが、古いバージョンの Android マシンで動かした時に落ちるので注意が必要。

デベロッパーコンソールでアプリをアップロードする時、公開設定のオプションのコピー防止をオフにする。
ここをオンにしているとSDにインストール出来ない。

ある程度サイズが大きいアプリはアンインストールされやすいが、SDインストールに対応していると消されづらいようなので、対応して問題なアプリは対応しておいた方が良さそう。
サイズが大きいと言っても5MBでも大きいと思われたりするから、積極的に対応した方がいい。

取得後、各ピクセルにグレースケール化処理を行い、書き戻した場合はそれぞれ以下のようになった。
1. 56～59msec ( 343～674msec )
2. 29～34msec ( 280～321msec )
3. 1107～1248msec ( 1718～2143msec )
括弧内の数値は初回で、それ以外は２回目以降の数値。
JIT 等の効果により、２回目以降は速度が上がっていると思われる。
3 が異様に遅いのは、IntBuffer.get/put によってピクセル値の取得と書き戻しを行っているせいだと思われる。
他は、配列で処理している。

array を wrap した Buffer で取得設定し、array で処理するのが一番か。

Canvas.drawBitmap(int[] colors, int offset, int stride, int x, int y, int width, int height, boolean hasAlpha, Paint paint) を使って、書き戻した場合はどうかも計測した。
1. Bitmap.copyPixelsFromBuffer 3 ～ 4msec
2. Canvas.drawBitmap 31 ～ 33msec
この場合も Bitmap.copyPixelsFromBuffer が大幅に早い様子。

自前でピクセル処理する場合、Bitmap.copyPixelsToBuffer/copyPixelsFromBuffer (array) を使うのが良さそう。

H.264 のライセンスは、MPEG LA、H.264の共同ライセンス体系を発表－エンコーダ/デコーダは0.20ドル。無料放送は1万ドル/年 では、「12分以下のものにはライセンス徴収を行なわない。」というのと、「搭載製品の総数が年間10万個/以下の場合は、ライセンス料を支払う必要は無く」という記述があるが、「初期のライセンス期間は2010年の12月31日まで」となっていて、その後どのようになったのかはっきりしない。
無料のインターネット配信の場合は、2015年まで無料で、その後さらに永久的に無料という発表はあったが、その他は不明。
5年ごとにライセンスは見直されるらしいが……
「デコーダ搭載製品」に当たるのかどうかも不明。

VP8 ( WebM ) は、現時点ではライセンス料は発生していないが、Android 2.3.3以降となっているので、それ以前のバージョンでの再生に問題が残る。

Android 版では、初回リリースは OS の機能をそのまま使う予定なので、これらの問題はそのまま発生する。
動画についてのライセンスについてはよく調べて対処してもらう必要がある。
NDK で Theorarm を使って Theroa を再生すると言う手もあるが、NDK を使うとそれはそれで再生できない機種が出る問題がある。

ちなみに、VC-1 ( WMV ) も、ライセンス料が発生しうる。
WMV3 ( WMV9 ) は、グレー。
昔、WMV のライセンスまとめ にまとめている。

FPS を見てみると……

初代Xperia Android 1.6 - 6fps ～ 4fps
初代Xperia Android 2.1 - 23fps ～ 16fps
IS03 - 23fps ～ 16fps
Xperia arc - 27fps ～ 16fps
Galaxy tab - 21fps ～ 16fps
Eee Pad Transformer TF101 - 27fps ～ 16fps

Android 1.6 の Xperia は異様に遅いが、それ以外は 20FPS以上出ている。
Paint.setFilterBitmap を true にしているが、これを false にすると数FPS上がる。
分割数を減らしたり、面積を減らせばもっと早くなる。
そこそこ使えそうな速度で動くようだ。

FreeType の Java 版があるか探したが見付からず。
自力で FreeType を Java に移植することも考えたが、かなり労力がかかりそう。
FreeType があれば、共通化や縦書きも出来るようになると思うが、対応は大変。
と言うことで、自前でのフォント関係の処理をすることは諦めた。

少メモリ環境下では、ディスク容量やメモリ容量節約のため使用する文字のフォントデータのみ出力したいが、オリジナルのレンダリング済みフォント作成ツールでは指定した文字のフォントデータのみ出力する機能はない。
ツールのソースを読んでもそれっぽい機能はない。
機能追加するのはそれほど難しくなさそう。
作るかどうか悩んでいたら、既にあることを教えてもらった。

吉里吉里レンダリング済みフォント作成ツール改

吉里吉里Java の場合は、常に matrix を指定して描画する。
そのため頂点指定の場合は、頂点から matrix を割り出す必要がある。
matrix から頂点を求めるのは簡単 (普通の行列演算) だけど、逆は手間がかかる。
最初は幾何学的に求められるかと思ったが、いろいろ検討するも難しい。
と言うことで方程式を解くことに。
吉里吉里2では3つの頂点が与えられるので、2つの連立三元一次方程式を作ることができる。
これは matrix から頂点を求める式そのまま。

連立三元一次方程式1
x0 = (-0.5)*a + (-0.5)*c + tx
x1 = (width-0.5)*a + (-0.5)*c + tx
x2 = (-0.5)*a + (height-0.5)*c + tx

連立三元一次方程式2
y0 = (-0.5)*b + (-0.5)*d + ty
y1 = (width-0.5)*b + (-0.5)*d + ty
y2 = (-0.5)*b + (height-0.5)*d + ty

このうち a, b, c, d, tx, ty が求める値。
それ以外は事前にわかっている。
連立方程式は、ガウス=ザイデル法やガウスの消去法等いくつか数値演算で求める方法がある。
効率を考えてガウス=ザイデル法を用いて上式を解くようにしたら、解が収束せずに求められず、ガウスの消去法を用いることにした。
期待通り matrix が求められている。

ただ、オリジナルとは異なり頂点を与える方が方程式を求める分効率が悪い。
直後の描画処理に比べたらそれほどでもないかも知れないが。