この件がよく議論されていることは知っていますが、メモリの問題に対する回避策や解決策が見つかりません。
問題は、Android 4.0 ではガベージ コレクションが機能しないことです (少なくとも私はそう信じ始めています)。以下は、私のコードでの同じ状況に関する acer iconia タブレット (4.0、48M ヒープ) および motorola defy (2.2、30M ヒープ) からのスナップショット トレースです。つまり、ゲームから次のステージを取得します -> 古い画像を破棄し、新しい画像をメモリにロードします。
4.0
08-15 21:33:07.020: V/ThemePacket(25564): debugSaveMemInfo: D:23.61 N:2.12 O:2.65
08-15 21:33:07.020: ThemePacket(25564): ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
08-15 21:33:07.050: D/dalvikvm(25564): GC_EXPLICIT freed 4K, 74% free 10909K/41671K, paused 2ms+3ms
08-15 21:33:07.260: V/ThemePacket(25564): debugSaveMemInfo: D:23.61 N:2.12 O:2.65
08-15 21:33:07.260: V/DrawableResourceDataReference(25564): Bitmap size is: w:1875 h:1250 Asking for: w:1215 h:780
08-15 21:33:07.280: D/dalvikvm(25564): GC_FOR_ALLOC freed 36K, 74% free 10940K/41671K, paused 18ms
08-15 21:33:07.410: I/dalvikvm-heap(25564): Forcing collection of SoftReferences for 9375016-byte allocation
08-15 21:33:07.450: D/dalvikvm(25564): GC_BEFORE_OOM freed <1K, 74% free 10940K/41671K, paused 44ms
08-15 21:33:07.510: E/dalvikvm-heap(25564): Out of memory on a 9375016-byte allocation.
2.2
08-15 22:10:53.132: V/ThemePacket(15074): GetStage(1)
08-15 22:10:53.155: V/ThemePacket(15074): debugSaveMemInfo: D:2,73 N:3,36 O:15,97
08-15 22:10:53.155: V/ThemePacket(15074): ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
08-15 22:10:53.218: D/dalvikvm(15074): GC_EXPLICIT freed 911 objects / 115904 bytes in 54ms
08-15 22:10:53.241: V/ThemePacket(15074): debugSaveMemInfo: D:2,73 N:3,36 O:9,02
08-15 22:10:53.241: V/DrawableResourceDataReference(15074): Bitmap size is: w:1875 h:1250 Asking for: w:885 h:600
08-15 22:10:53.241: V/DrawableResourceDataReference(15074): Scaling down by 2
// all goes fine
次の行に注意してください。
debugSaveMemInfo: D:23.61 N:2.12 O:2.65
ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
debugSaveMemInfo: D:23.61 N:2.12 O:2.6
対。
debugSaveMemInfo: D:2,73 N:3,36 O:15,97
ClearBitmapsFromMemory: 7 friends 20 foes 2 GFIs
debugSaveMemInfo: D:2,73 N:3,36 O:9,02
そして、これらのトレースを少し解読するために、これがメモリ情報を取得する方法です:
Debug.MemoryInfo memInfo = new Debug.MemoryInfo();
Debug.getMemoryInfo(memInfo);
double nativeMem = memInfo.nativePss/(double)1024;
double otherMem = memInfo.otherPss/(double)1024;
double dalvikMem = memInfo.dalvikPss/(double)1024;
//some formatting...
Log.v(LOG_TAG, "debugSaveMemInfo: D:" + dalvik + " N:" + nativeM + " O:" + other);
メモリ ビーフからビットマップをクリアすると、次のようになります。
// Bitmap mBitmap
mBitmap.recycle();
mBitmap = null;
はい、両方のプラットフォームでコードをデバッグしましたが、私のコードではすべてがまったく同じように動作します。したがって、誰かがまだこれを読んでいる場合、いくつかの疑問が生じます。4.0 でビットマップをリサイクルしてもメモリが解放されないのはなぜですか? GC は、OoM をスローする前に空きメモリのすべてのビットを見つけていると思われませんか? OoM を防ぐためにメモリの使用量を全体的に減らすと、それらのビットマップは最終的に解放されます。しかし、メモリが必要なときではありません...
さらに興味深いことに、ゴースト ビットマップがメモリ内にあるケースから hprof ファイルを取得しましたが、そうではありません。メモリ アナライザーは、23M の数値を画面に出力し、その 9M の割り当てから OoM を取得すると同時に、dalvik ヒープが約 10M であることを示しています。私はここでちょっとしたアイデアなので、どんな提案も大歓迎です。私の次の解決策は、OoMになったら画質を下げることだと思います