mieki256's diary

起動時に全ての画像を展開せず、各シーンに入った際に必要な分だけ展開するようにしてみた。50xi用を作ってた時は、ヒープメモリだかネイティブメモリだかが少なかったので、シーンに入ったり抜けたりするたびに、画像展開・画像廃棄を逐一してたのだけど。今回は基本的に90xi以降に対応すればいいらしいので、モノグサ的に、起動時に全部展開してたわけで。

モノグサ的に、とは言ってるけれど。そうしておけば、起動は遅いけど後で待たされることはないというメリットがあるわけで。そのあたり、今回の修正で、さあゲームが始まるぞ、となるところでたっぷり待たされるようになって、これはこれでどうなんだろうという感も。これでいいのであろうか。

本来は何かの処理と並列して画像展開すべきなのかな。と思ったけれど、何か処理してる間に画像展開するとメモリのフラグメントが起きやすくなりそうな不安もあるし。うーん。展開後の画像データが、どういう形でメモリ上に展開されるかが判らんので、事前に必要な分メモリを確保しておく等もできるかどうかよく判らず。たぶん機種毎に違う予感。＞展開後のデータのサイズ。うーん。

たしかに現状では長い。ストップウォッチで計ってみたら、3分ぐらいかかっていてクラクラした。しかし、どうすれば短縮できるのか。スクラッチパッドに入れる画像を削るしかないかな。

と思ってたけど。他のアプリが、スクラッチパッドのほとんどを使ってるように見えるのに、40秒前後でDLできていることを確認。であれば、これは何か解決策があるはず。と思ったところで気がついた。データファイルの分割数が多すぎるのが原因なんじゃなかろうか。試しに分割数を少なくする＝1ファイルあたりのサイズを大きくしてみたり。…おおお。劇的に改善。自宅サーバからネット経由でDLしてみたら、こちらも40秒前後になった。

ただ、iアプリの場合、一度のアクセスで読めるHTTP受信データサイズに制約が。DoJa3.0以前は、一度のアクセスで20KByteまで。DoJa3.5以降は、150KByteまで。なんだか怖いので、20KByte以下の分割サイズにしてみたり。ただ、今回の変更で、ダメダメ機種ではメモリが足りなくって落ちるのではないかという不安も。いや、他アプリがこのくらいのDL時間で済んでるということは、分割サイズもそれなりに大きいはずだし。おそらく問題は出ないからそういう状態にしてる、のだろうからたぶん大丈夫、だといいな…。

む。今まで、読み込みバーの増加を、ファイル数を元にして行っていたので、全体的なDL時間は短くなったものの、バーの進み方はちと判りづらくなってしまった。最初に、読み込むべきバイト数が判れば、バイト数を元にした表示もできるのだろうけど。機種によって読み込むデータサイズが違うから…。どうしたもんか…。