Androidヒープメモリサイズが正しく表示されない

Question

私は、画像をたくさん表示するAndroidアプリを持っています。画像はURLから収集され、キューに追加され、4つのスレッドで収集され、リストビュービューで表示される4行の画像は、画面上に表示されるたびに6行ずつ表示されます。合計90枚の画像があります。

行（および画像ビュー）は常にリサイクルされるので、アイテムの量は常に同じで、何も初期化していません。

これはかなりうまくいくようですが、私はいつも平均13MBのヒープサイズを使用しています。

私が持っている問題が始まるマイル最大ヒープサイズで非常に小さく、私のようなGCメッセージを取得することです：

01-20 16：48：39.191：D/dalvikvm（9743）：GC_FOR_ALLOC 25msの

を一時停止したが、より多くの私はビュー上下にスクロールヒープサイズはますますuntileを育て、私は

01-20 17のようなものを取得し、12048K/17351K 31％無料、< 1Kを解放：02：0 5.339：D/dalvikvm（11730）は：GC_FOR_ALLOCは544K、あなたが使用する最大iがその限界までやったことがなかった場合にも増加しているのと同じであったとしても見るように自由が13871K/49159K、35ミリ秒

を一時停止して72％解放しました。本当の問題は、この時点で私はメモリー不足から抜け出すことです。

誰かが間違っていることを説明できますか？

ありがとうございます！

Answer 1

使用しているAndroidのバージョンは何ですか？ 3.0より前（つまり2.x）でテストしている場合、ほとんどの情報をビットマップに格納するバイト配列が割り当てられ、ネイティブメモリに格納されます。つまり、ヒープダンプやGC通知では、実際のサイズではなく、ビットマップ内のポインタに使用されるメモリの量が少なくなるだけです。詳細については

は、このGoogle IOをチェックアウトするメモリ管理で話すと、メモリリークを検出：http://www.youtube.com/watch?v=_CruQY55HOk

はまた、私は同様のことをやって、いくつかのアプリに働いてきました。私の推測では、あなたのキャッシュサイズが大きすぎるか、キャッシュに表示して保存している画像が実際に望むサイズよりもはるかに大きい（より可能性が高い）かのどちらかです。イメージビューにビットマップを表示すると、実際にビューに収まるビットマップよりもかなり大きい場合でも、イメージビューは元のビットマップをメモリに保存します。画像を表示しようとする前に、適切なサイズにディスクのサイズを変更してみてください。How do I scale a streaming bitmap in-place without reading the whole image first?

Answer 2

私は画像をキャッシュするにはMap<String, Drawable> drawableMapを使用してください。 OutOfMemoryErrorに私は、この関数を呼び出す：

private void cacheLeeren() 
{ 
    int size = drawableMap.size(); 
    int del = (int) (size * 0.3); 
    Set<String> s = drawableMap.keySet(); 
    for (String t : s) 
    { 
     if (del >= 0) 
     { 
      drawableMap.put(t, null); 
      del--; 
     } 
    } 
} 

私はそれが最善の方法ではないと思う...それは;-)

Answer 3

私の推測では、あなたのアプリがためのメモリ使用量の非常に高いピークに達したことがある作品短時間。平均して13MBしか使用しないことは事実ですが、ヒープが50MBもの大きさになると、考えているよりはるかに多くのメモリを消費したことを意味します。

これがどこで起きているのかを見てみましょう。あなたはLRUキャッシュを使っていると言いました。このキャッシュは、メモリがいっぱいになるとすぐに解放します。私の推測では、あなたは余りにもメモリを解放し始めているということです。このメモリはシステムGCに依存するので、すぐに解放されません。キャッシュからアイテムを解放するときは、いつでもSystem.gc()に電話してみてください。

また、Bitmap.recycle()と呼んでいるとお伝えしました。私の知る限りでは、ネイティブヒープはもはやビットマップに使用されないので、これはAndroid 3+では無用です。すべてのビットマップはダルビックヒープ上にあるので、GCによって解放されます。System.GC()に電話しない限り、前と同じように急ぐことはできません。

問題の原因のもう一つのアイデアは、ヒープフラグメンテーションです。このquestionの似たような問題に対する以前の私の答えを見てください。