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입니다.

예를 들어 Google에서 가비지 수집을 피하는 방법에 대한 정보를 찾을 수 있습니다. "가비지 수집 안드로이드 피하는 법".