2

元に戻す操作に使用されるビットマップの配列を保持したいグラフィカル アプリに取り組んでいます。ビットマップはそれぞれ約 9M と非常に大きいため、一度にメモリに保持できるのはごくわずかです。

何枚持てるか事前に調べておきたい。

使用可能なメモリを照会するさまざまな方法を試しましたが、不要になったビットマップをリサイクルするように注意していますが、それにもかかわらず、アプリは EOutOfMemory でクラッシュするようです。

ビットマップを縮小したり、RGB565 を使用したりしたくありません。許可できる元に戻すステップの数を把握するための、合理的に信頼できる方法が必要です。

ありがとう

編集#1

コメントにリンクされている方法を含め、使用可能なメモリを特定するさまざまな方法を引き続き試しましたが、まだ問題が発生しています。

奇妙なことに、私の古い Samsung I9000 携帯電話では、サイズが 9 MB ごとに多数のビットマップを作成してアクセスするのにそれほど多くの問題はありませんが、新しい Samsung Tab 3 は 3 番目のビットマップを割り当てて停止します。

十分なメモリが利用可能である必要があります。Android 3以降でビットマップにメモリが割り当てられる場所に違いがあることについて読んだことがありますが、完全には理解していません。これが私のタブが EOutOfMemory で死ぬ原因になっているのでしょうか?

編集#2

必死になって、マニフェストでlargeHeapを有効にすることにしました。推奨されていないことはわかっていますが、Tab 3 の動作がより予測しやすくなり、根本的な問題について何かを示している可能性があります。

4

2 に答える 2

0

これは、画像ファイルを「res/drawable」フォルダーに入れるという非常によくある間違いを思い出させます。

このようなことにより、画面密度が高くなるほど、ビットマップはより多くのメモリを消費します。

たとえば、100x100 の画像の場合、mdpi デバイスでは 100*100*4 = 40,000 バイトしかかかりませんが、xhdpi デバイスでは (2*100)*(2*100)*4 = 160,000 バイトかかります ( 4倍以上)。

ただし、Galaxy Tab 3 は高密度の画面ではないようですので、すべてのビットマップを保持するためのヒープ サイズが小さいため、OOM になると思います。

メモリとビットマップのヒントについては、こちらの投稿をご覧ください。

于 2013-09-22T09:00:36.960 に答える