Androidのガベージコレクションが実行されない

Question

アクティビティに次のコードがあります。最終的に、私はフレームアニメーションをしようとしていますが、GCはパフォーマンスを殺しています。私は明示的にリサイクルを試みましたが、違いはありません。

ビットマップをBitmapFactor.Options.inBitmapで再利用できることも知っていますが、実際に問題を解決するものの、オプションではないAPI> = 11に制限されています。

このコードは単に問題を示しています。私のアプリの一部ではありません：

 Log.d("GC_badness", "0: " + SystemClock.uptimeMillis()); 
     Bitmap image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "1: " + SystemClock.uptimeMillis()); 
     image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "2: " + SystemClock.uptimeMillis()); 
     image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "3: " + SystemClock.uptimeMillis()); 
     image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "4: " + SystemClock.uptimeMillis()); 
     image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "5: " + SystemClock.uptimeMillis()); 
     image = BitmapFactory.decodeResource(getResources(), R.drawable.my_image); 
     Log.d("GC_badness", "6: " + SystemClock.uptimeMillis()); 

この結果、次のログエントリが表示されます。 jpgリソースからの各ビットマップロードは、少なくとも3つのガベージコレクションと8つ以上の結果をもたらします。ほとんどの場合、ほとんど何も収集しません。たとえ複数のメッセージがあるとしても、ヒープは成長していません。それもかなり混乱しています。

私は困惑しています。私はビットマップAPI 11を再利用する方法を見つけることができず、これらの役に立たないガベージコレクションのすべてによって巨大な遅延が生まれることはありません。

04-07 18:17:51.860: D/GC_badness(7510): 0: 360583998 
04-07 18:17:51.900: D/dalvikvm(7510): GC_FOR_ALLOC freed 34K, 5% free 6320K/6595K, paused 32ms 
04-07 18:17:51.900: I/dalvikvm-heap(7510): Grow heap (frag case) to 7.744MB for 1584016-byte allocation 
04-07 18:17:51.950: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 5% free 7867K/8199K, paused 27ms 
04-07 18:17:52.000: D/dalvikvm(7510): GC_CONCURRENT freed <1K, 5% free 7868K/8199K, paused 2ms+3ms 
04-07 18:17:52.030: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 5% free 7868K/8199K, paused 31ms 
04-07 18:17:52.030: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 704016-byte allocation 
04-07 18:17:52.070: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 4% free 8555K/8903K, paused 37ms 
04-07 18:17:52.070: D/dalvikvm(8107): GC_FOR_ALLOC freed 1464K, 39% free 17183K/27911K, paused 62ms 
04-07 18:17:52.100: D/GC_badness(7510): 1: 360584238 
04-07 18:17:52.100: D/dalvikvm(8189): GC_CONCURRENT freed 286K, 8% free 6917K/7495K, paused 17ms+3ms 
04-07 18:17:52.110: D/dalvikvm(7510): GC_CONCURRENT freed 1546K, 22% free 7009K/8903K, paused 2ms+2ms 
04-07 18:17:52.150: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 22% free 7008K/8903K, paused 32ms 
04-07 18:17:52.150: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 1584016-byte allocation 
04-07 18:17:52.200: D/dalvikvm(7510): GC_FOR_ALLOC freed 0K, 4% free 8555K/8903K, paused 37ms 
04-07 18:17:52.250: D/dalvikvm(7510): GC_CONCURRENT freed <1K, 4% free 8555K/8903K, paused 2ms+2ms 
04-07 18:17:52.280: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 4% free 8555K/8903K, paused 30ms 
04-07 18:17:52.280: I/dalvikvm-heap(7510): Grow heap (frag case) to 9.086MB for 704016-byte allocation 
04-07 18:17:52.310: D/dalvikvm(7510): GC_FOR_ALLOC freed 0K, 4% free 9243K/9607K, paused 23ms 
04-07 18:17:52.330: D/dalvikvm(8107): GC_CONCURRENT freed 588K, 34% free 18618K/27911K, paused 4ms+5ms 
04-07 18:17:52.350: D/GC_badness(7510): 2: 360584482 
04-07 18:17:52.350: D/dalvikvm(7510): GC_CONCURRENT freed 1546K, 20% free 7696K/9607K, paused 1ms+2ms 
04-07 18:17:52.380: D/dalvikvm(7510): GC_FOR_ALLOC freed 688K, 28% free 7008K/9607K, paused 22ms 
04-07 18:17:52.380: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 1584016-byte allocation 
04-07 18:17:52.400: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 11% free 8555K/9607K, paused 21ms 
04-07 18:17:52.440: D/GC_badness(7510): 3: 360584577 
04-07 18:17:52.450: D/dalvikvm(7510): GC_CONCURRENT freed <1K, 4% free 9243K/9607K, paused 1ms+2ms 
04-07 18:17:52.470: D/dalvikvm(7510): GC_FOR_ALLOC freed 2234K, 28% free 7008K/9607K, paused 20ms 
04-07 18:17:52.470: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 1584016-byte allocation 
04-07 18:17:52.500: D/dalvikvm(7510): GC_FOR_ALLOC freed 0K, 11% free 8555K/9607K, paused 29ms 
04-07 18:17:52.510: D/dalvikvm(8107): GC_CONCURRENT freed 1785K, 33% free 18832K/27911K, paused 2ms+5ms 
04-07 18:17:52.530: D/GC_badness(7510): 4: 360584668 
04-07 18:17:52.540: D/dalvikvm(7510): GC_CONCURRENT freed <1K, 4% free 9243K/9607K, paused 1ms+2ms 
04-07 18:17:52.570: D/dalvikvm(7510): GC_FOR_ALLOC freed 2234K, 28% free 7008K/9607K, paused 28ms 
04-07 18:17:52.570: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 1584016-byte allocation 
04-07 18:17:52.590: D/dalvikvm(7510): GC_FOR_ALLOC freed <1K, 11% free 8555K/9607K, paused 22ms 
04-07 18:17:52.620: D/dalvikvm(7510): GC_CONCURRENT freed <1K, 4% free 9243K/9607K, paused 3ms+2ms 
04-07 18:17:52.630: D/GC_badness(7510): 5: 360584765 
04-07 18:17:52.650: D/dalvikvm(7510): GC_FOR_ALLOC freed 2235K, 28% free 7008K/9607K, paused 21ms 
04-07 18:17:52.650: I/dalvikvm-heap(7510): Grow heap (frag case) to 8.416MB for 1584016-byte allocation 
04-07 18:17:52.680: D/dalvikvm(7510): GC_FOR_ALLOC freed 0K, 11% free 8555K/9607K, paused 27ms 
04-07 18:17:52.710: D/GC_badness(7510): 6: 360584844 

Answer 1

なぜイメージを再利用しますか？

ガベージコレクタに何かを収集する機会を与えないでください。基本的に、ローカルで定義したオブジェクトはすべて、早急に収集されます。

イメージ変数を再利用しないでください。あなたのアニメーションコードの前にimagearrayとイメージを作成してください（最善の方法は、アクティビティが作成されている間に読み込むことです）。 または画像にObjectPoolを使用することを検討してください。

ここでは、ガベージコレクションを回避する方法については、SO answerが良いです。

最後に、ガベージコレクションの回避方法に関する情報がたくさんあります。 "ガベージコレクションアンドロイドを避ける方法"。