s40 マシンはゲーム用のメモリが優れています, ポピュラーサイエンス。

メモリ使用量には、プログラムとリソースという 2 つの主なタイプがあります。・プログラムクラスはクラスバイトコードファイルにコンパイルされ、MIDlet起動時にメモリ上にロードされ、一括追加されます。つまり、MIDlet 内のクラスが増えるほど、単一クラス プログラムが長くなり、クラス内の文字列定数とデータが増えるほど、コンパイルされたクラス ファイルが大きくなり、ロード後に占有するメモリも多くなります。私はよく MIDlet クラスのコンストラクターで Runtime メソッドを使用して、MIDlet の開始後にプログラム全体が占有するメモリ量を確認します。 //最適化方法: 1. MIDlet プログラムはメモリ使用量を削減するために 2 つのクラスに書き込まれますが、Java の OOP 機能が犠牲になります。この欠点は、プログラムが比較的大きい場合に特に顕著になります。さらに、CoCoMo では、1 つのクラスが大きすぎてロード時間が長くなり、宝箱のロゴに表示されている 6 秒の制限に違反するという状況に遭遇したことがありました。 //2.エレガントなコードを作成し、関数の数を減らし、プログラムのリリース時に try catch を削除し、プログラムの行数を最小限に抑えるようにしてください。これは古い 40 では通常不可能ですが、現在 CoCoMo はメモリを節約するためにこれに依存しなくなりました。 //3.データと文字列をファイルに書き込み、使用時にそれらをメモリにロードし、使用しないときは null に設定します。 4. I/O 操作 getClass(). getResourceAsStream(file);、データベース操作 RecordStore。 openRecordStore(name, true);、サウンド作成マネージャー。 createPlayer();、画像作成 画像。画像作成(ファイル);短期間に大量のメモリを占有し、後で解放されます。 MIDlet プログラムの残りメモリが不足している場合、これらの関数が頻繁に呼び出されることでメモリ オーバーフローが発生し、いわゆるメモリ ピークが発生します。これは特に古い 40 でよく発生します。再び OutOfMemoryError が発生した場合は、Runtime を使用してメモリ ピークが発生する場所を見つけ、これらのステートメントを個別に呼び出すようにして、System を柔軟に使用してください。 gc() を使用して時間内に収集します。 //・リソース画像: 特に画像リソースが多いモバイル ゲームでは、大量のメモリを占有します。画像リソースのメモリ使用量を計算することは、J2ME ゲーム開発者にとって定期的なタスクになっています。ココモでは、画像のメモリ使用量の計算方法について説明します。 //メモリ使用量 = 幅 * 高さ * ピクセル バイト数 (ピクセル バイト数はモデルによって異なります)。 //たとえば、7210 の 64*64 画像のメモリ使用量 = 64*64*1.5 = 614 4 (バイト) = 6K、S60 のメモリ使用量 = 64*64*2 = 8192 (バイト) = 8K。ピクセルのバイト数はモデルによって異なります。たとえば、7210 は 4096 色モデルで、ピクセルを表すのに 12 ビットが使用されるため、1.5 を掛けます。一方、S60 は 65536 色モデルで、1 ピクセルを表すのに 16 ビットが使用されるため、2 を掛けます。 //最適化方法//画像を圧縮するとメモリが節約できると考えるのは間違いです。上記の説明によると、画像がメモリにロードされた後は幅と高さだけが関係し、画像データのサイズとは関係ありません。画像を圧縮すると、jar サイズが削減されるだけで、メモリ使用量は削減されません。 //1.静的方法: 画像のサイズを縮小します。幅と高さが小さい場合、結果は小さくなります。この考えに基づいて、ゲームロフトのプリンス オブ ペルシャなどのアニメーション エディターなどのツールが登場しました。キャラクターを分割した後、人体のパーツは再利用できます。各パーツをコンパクトに配置することで、絵のサイズを小さくし、絵の隅々までスペースを有効活用することができます。 //2.動的方法: 同時にメモリにロードされる画像の数を減らします。ココモはかつて、NARUTO -ナルト- サムライ プロジェクトでこの状況に遭遇しました。当時のモンスターは6種類ありました。これらを同時にメモリにロードすると、旧40では確実に爆発してしまいます。しかし、各レベルに出現するモンスターは2~3種類のみなので、各レベルはそのレベルに出現するモンスターの写真をロードするだけで済みます。そういえばこのプロジェクト、古い40ではオーバーフローが頻繁に発生していました。 //Sound//Sound も比較的メモリを消費するリソースです。サウンド内のオーディオ トラックが占めるバイトはバイト ストリームに変換され、メモリにロードされます。したがって、オーディオ トラックが占めるバイト数を減らすと、メモリの消費量を減らすことができます。 Gameloft の現在のアプローチは、サウンド変換ツールを使用してミッドからオットに変換し、それを ByteArrayInputStream バイト ストリームに変更してプレーヤーを作成することです。