mieki256's diary

別途作成したレジューム動作確認用アプリに関しては、レジューム時に選択キーの入力が入ってしまわない状態で動作するところまで修正できたかな、という感じなのだけど。本番用アプリも、ソレと同じ処理の流れにしたはずが、そちらは選択キーの入力が入ってしまう。実に不可解。

ちなみに不具合が発生してるのは P902iS。Pシリーズ全般で不具合が起きてるという報告もあり。

本番用アプリでトレース情報を出力してみた。

最初の数字が (System.currentTimeMillis() % 1000000) の値。単位はミリ秒(1/1000秒)。「key=」はキー情報。「キートリガ.キープレス」、もしくは、キートリガのみを16進数で出力してる。

652090 ▼:key=0.0    <--- メインループ頭のキー入力読み取り直後。通常処理時。
652092 Main:key=0.0  <--- メインループ内の各シーンメイン処理開始。通常処理時。
652130 ▼:key=0.0
652132 Main:key=0.0
652170 ▼:key=0.0
652172 Main:key=0.0
652210 ▼:key=0.0
652212 Main:key=0.0
652250 ▼:key=0.0    <--- 「終了」ボタンを押す直前のフレーム。

                     <--- 「終了」ボタンが押されて、「終了しますか？」が表示されている。 

667056 Main:key=0.0  <--- 「終了しますか？ YES/NO」で、「NO」を選んだ直後。
                           一つ前の出力から数秒経過してるので、「サスペンド」？していたことがわかる。
                           最初にレジューム処理に飛ばず、メインループ内に戻ってきてる、ということがわかる。
                           ただ、メインループ内で参照してるキー入力値は、
                           「終了」ボタンを押す前のキー入力値なので、ここに戻ってくる分には問題はない。

667067 ▼:key=100020.100000   <--- レジューム時なのだから、一旦レジューム処理に飛んでほしいところだが、
                                   その前に、メインループが1回実行されてしまっている。
                                   このタイミングで、「NO」を押した際の、選択キー入力が読み取られてしまう。

667071 Main:key=100020.100000  <--- そのまま各シーンメイン処理に入る。
                                    選択キーが押されてるから、次のシーンに進んでしまう。

667257 RESUME_VM_EVENT S:key=100020  <--- ここでようやくレジューム発生がアプリに通知される。
                                          低レベルイベントとして processEvent() が呼ばれるので、
                                          レジューム発生フラグを立て、キーバッファをクリアしておく。
                                          でも、もう遅い…。

667259 RESUME_VM_EVENT E:key=0       <--- processEvent() 内処理を終了。

IA.rsm S                <--- IApplication.resume() 開始。
IA.rsm null chk try:0
667271 resume() S:key=0  <--- Canvas 内の resume メソッド開始。
                              ここでも、レジューム発生フラグを立て、キーバッファをクリアしておく。

667273 resume() E:key=0  <--- Canvas 内の resume メソッド終了。
IA.rsm mcRsm try:0
IA.rsm E                <--- IApplication.resume() 終了。

667303 ▼:key=100020.100000    <--- メインループ頭に処理が戻ってきた。
667343 ▼:key=0.100000      <--- レジューム発生フラグが立っていて、かつ、キー入力が入ってるので、
                                 キーが離されるまでループを空回しする。
667383 ▼:key=0.100000
667423 ▼:key=0.100000
667463 ▼:key=0.100000
667503 ▼:key=0.100000
667543 ▼:key=0.100000
667583 ▼:key=0.100000
667623 ▼:key=0.100000
667663 ▼:key=0.100000
667703 ▼:key=0.100000
667743 ▼:key=0.100000
667783 ▼:key=0.100000
667830 ▼:key=0.0         <--- キーが離されたので通常処理に戻る。が、もう次のシーンに進んでしまってるわけで…。
667869 Main:key=0.0
667879 ▼:key=0.0
667882 Main:key=0.0

ということで、レジューム処理が行われる前に、メインループを複数回通過する状態になっているみたいで。

アプリ側でレジュームが起きたことを知る方法としては、

• Canvas.processEvent(int type, int param) で type == Display.RESUME_VM_EVENT になった時。
• IApplication.resume() が呼ばれた時。

の2つしか把握してないのだけど。どちらも、メインループが通常通りに動いた後で呼ばれるようなので、「レジュームが発生したから、その直後はしばらくキー入力を見ない」といった処理をわざわざ書いても、「時すでに遅し。その処理が行われる前に、もうキーを読んでしまってメイン処理が先に進んでる」わけで。

しかし不思議なのは、レジューム動作確認用アプリではこの症状がおきてないこと。本番用アプリで症状が出るというのは何故なんだろう…。それぞれ、何が違うんだろう。使ってる変数の量か。バイナリのサイズか。バイナリのサイズが大きいとレジューム関連処理が呼ばれるのが遅くなるのか？

さておき、解決策として思いつくのは、キープレストリガ(キーを押した時のトリガ)じゃなくて、キーリリーストリガ(キーを離した時のトリガ)でシーンを進める、といった方法に全部書き換えるぐらいだろうか。しかし、メニュー選択等の、タイミングが重要ではない場面ならそれで解決できるだろうけど。今企画のゲーム本編は、そこそこリアルタイム性がある・ボタンを押したタイミングというのが重要なので、リリーストリガでは反応が1フレーム遅れてしまってそれってどうなんだという不安も。

数週間前にk長さんから、大学時代の仲間内全員に、「同人誌の原稿が大量に発掘された。返却して欲しい人が居たら連絡を」的メールが送られてきたので、「自分の原稿があったら一応何かの記念に残しときたいような気もなんとなくするような感じでもあるから返却してくれると嬉しい。自分の原稿があったら、だけど」てな返信をしたのだけど。

昨日、「返却希望者が君しか居なかったんで、面倒くさいから原稿全部送るわ」というメールが届いて、笑ってしまった。予想外の展開。ていうか、えー？ 俺だけ？ そうなの？ で。今日になって原稿が入った段ボール箱が届いて、それを見て、また笑ってしまった。箱、デカっ。めちゃくちゃ重い。本当に大量だ。そりゃ奥さんも、「こんなもん処分しろ」と言いますわな。

ていうか。この中に自分の原稿、本当にあるんだろうか…。なんだか開ける気力も湧かない。

時間に余裕ができたら、住所の判ってる範囲で無理矢理送って片づけてしまおう。時間に余裕ができたら。