2

J2ME アプリケーションにイメージをロードする標準的な方法は、Image.createImage メソッドを使用することであり、推奨されるイメージ形式は PNG です。

現在、J2ME の仕様では、このメソッドの実装やイメージのメモリ内表現に制限を設けていないため、ベンダーごとに実装が異なります。

特に Motorola には、画像作成時に PNG が ARGB バイト配列に完全にデコードされるという、本当にお粗末な実装があります。これは、サイズが 176x208 の 8K の png は、読み込みに約 170K のピーク メモリを占有し、Image オブジェクト自体が使用するメモリは約 145K であることを意味します。Nokia、Sony Ericsson などの他の携帯電話では、同じ画像を読み込んでメモリに保存するのに約 16K しかかかりません。

これは私の J2ME アプリに大混乱をもたらし、Motorola の携帯電話で適切なバージョンを実行することはほとんど不可能になっています。画像の gzip された ARGB バイト配列を使用してペイント中に収縮させるなど、さまざまな回避策を試しましたが、ペイントが 10 倍遅くなります。

この問題の回避策を知っている人はいますか? Motorola にはないスマートな機能を備えた J2ME 用のオープン ソース PNG 画像デコーダ? または、メモリのフットプリントを削減するために PNG 画像に対して実行できることはありますか? （私は現在、インデックス付きモードのPNGを使用しています）ポインタはまったく歓迎されます..

ゴウリ

4

6 に答える 6

3

ソニーエリクソンに関する1つのこと。彼らにそれほど多くの信用を与えないでください。画像を読み込むときにも（image_width x image_height x bytes_per_pixel）のメモリを使用します。

SE J2ME開発者向けドキュメントによると、「すべての画像は、16ビット/ピクセルのRGB形式で、場合によっては1ビットまたは8ビット/ピクセルのアルファチャネルで電話メモリに保存されます。」つまり、少なくとも2バイトです。違いは、Sony Ericsson電話（Nokiaについては話せません）には、ヒープに画像をロードする前に最初にいっぱいになる画像用の個別のメモリブロックがあることです（これは、Runtime.getRuntime（）。freeMemoryでロードをラップすることで確認できます（）...ヒープサイズは、新しいオブジェクトのサイズである数バイトだけ増加します）。

SE電話からMotorolaに移植するのに問題があったので、これはMotorolaを擁護していませんが、SEが画像をはるかに最適化された方法でヒープに保存する方法を見つけたからではありません。Motorolaはすべてをヒープに格納するだけなので、不足が早くなります。

デコーダー部分だけでなく、ヒープの断片化の観点からも、小さい画像を使用することをお勧めします。これにより、画像を大きな連続ブロックではなく、小さなメモリブロックに収めることができます。

于 2008-11-15T19:46:40.927 に答える
1

画像を作成するときにすべての画像フォーマットが即座に ARGB 配列にデコードされる場合、実際にできることは、オブジェクトをディスプレイに表示するために使用するメモリ量の上限を作成することだけです。画面。

各イメージがその特定のデバイスで使用しているヒープ メモリの量を把握するイメージ キャッシュを作成し、必要なイメージのロードとアンロードを行うことができます。もちろん、アプリケーションの応答性を維持するには Grabage Collector に頼りすぎている可能性があります。

キャッシュ管理は、おそらく専用スレッドで行う必要があります。

アプリケーション画面が十分に静的であり、あまり多くのアニメーションを必要としない場合は、任意の時点で 1 画面分の画像のみをロードしたままにしておくことができます。

また、MIDP キャンバスは通常、自分自身をリセットしないことに注意してください。Canvas.paint() への 2 つの異なる呼び出しを使用して、2 つの異なる画像を画面の 2 つの異なる領域にペイントする場合、実際の画像オブジェクトがガベージ コレクションされた後も、できるだけ長い間、両方の画像を表示し続けることができるはずです。それらの上に何もペイントしないでください。

純粋に商業的な観点から言えば、一部の電話機には Java の実装が非常に悪いためサポートしないことを顧客に伝える必要があります。

于 2008-11-06T10:50:52.653 に答える
0

Motorola の開発者フォーラムでは、大きな画像全体を一度に読み込むのではなく、大きな画像を小さなストリップに切り取り、これらの小さなストリップをロードすることを提案しています。これは、イメージのメモリ内フットプリントを削減しないことに注意してください。それでも、すべてのストリップの合計 (幅 * 高さ * ピクセルあたりのバイト数) が必要です。ただし、png 画像をデコードしてロードするために必要なメモリは削減されます。それが今のところ私がやっていることです。それはいくつかを助けました。しかし、全体的なメモリ使用量は依然として問題です。

于 2008-11-10T13:43:04.693 に答える
0

より良い解決策は、ARGBをデータとして保存することです（圧縮するために何らかのインデックスを使用します）。パレットなどを変更する/ PNGヘッダーを使用しないという利点があります。異なる PNG 画像を保存する代わりに、createImage 関数を使用して画像を作成します。

于 2008-11-18T05:35:54.137 に答える
0

PNGは肥大化する傾向があります。

代わりに gif を使用しないでください。

http://www.ddj.com/mobile/184406435;jsessionid=SBUQN2ECITM5OQSNDLOSKHSCJUNN2JVN?_requestid=76071

于 2008-11-05T15:23:19.330 に答える