気づいたら朝の 4 時。
んー色々実験した結果 SurfaceView を切り離す事によって、端末を回転させた
ときの再開方法は見つかったが…
iアプリや MIDlet で「通信スレッド1つ、ゲームスレッド一つ」みたいに、
イベント駆動ではなくスレッドでループを作り管理し、横道のゲームループを
作るタイプだと色々ハマる所も多い。
ビジネスアプリケーションでは Canvas を複数作り、setCurrent() で切り替え、
paint() メソッドで描画を行うというのも一般的。
android では activity が iアプリなどの Canvas に似ている。画面又は機能単位で Activityを切り替えるのが王道っぽい。
さて Android でゲームループを作るのに「Activity は一つ、View は一つ」の
概念で作ってたのですが、onDestroy() の後スムーズにゲームを開始させたい
場合は「Activity は一つ、View は一つ、ロジック class が一つ」の方が簡単に
回転対策は出来るかも。
onCreate() が来たときは必ず new SurfaceView() を行い、各コールバックは
ロジックclass に通知するようにする。
そうすることにより SurfaceHolder インスタンスだけは onCreate() で新しいの
が生成され、他のインスタンスは継続して利用できる。
もちろんプログラマによって、onPause() で不必要なものを解放し onResume() で
重いリソースを再初期化させるのも良い。
onSaveInstanceState() は必ず呼ばれる保証もないとの噂もありますが、GUI
コンポーネント以外でそこまで使う必要あるのかは、今の段階では疑問。
そもそも onDestroy() でプロセスが死んでいない事があるという感覚に驚く。
いわゆる fastcgi みたいに常駐させておくことにより、起動のオーバヘッドを
無くしたいんだろうか。Windows Mobile のアプリも終了ボタンでは
終了しないのがデフォルトだったが。
話は戻り Android でゲームを作り、ネイティブ(Android)の機能で特別に対応
しないといけない機能は、
・Activity 一時停止時のサウンド制御
・Activity 再開時のサウンド制御
・isFinishing() かつ onPause() -> onStop() ->onDestroy() 時の解放処理、
特に static 利用時の場合。このフローで全て正常終了させてやる。
( 自身を kill process しているアプリも多い。それが一番楽なのは事実。 )
・isFinishing() では無いときの終了フロー。画面切り替えなど。この時は
次回スムーズに再開されるべきであるため、static 変数などの方が都合が良い。
view に関しては、非常にシンプルなインスタンスとして切り分けるべきかも。
これに関しては問題ないか調査中 => 問題なし、これは有効。
iアプリや MIDP 開発者だけとは限らないけど Android はハマる箇所多い。
0 コメント:
コメントを投稿