そのため、水平方向にスワイプして次の画像に移動できる画像を含む ViewPager である画像スライダーがあります。
新しい画像を画像スライダーにロードする前に、各ビットマップで mBitmap.recycle() を呼び出して、メモリを浪費していないことを確認します
Android Studio でメモリ モニタを確認すると、Android 4.4 (Dalvik) ではこれが適切に機能し、新しい画像が読み込まれるたびに、画像が読み込まれていないときに使用するメモリ量まで常に減少することがわかります。
Android 5.0 以降では、必ずしもそうとは限りません。横にスクロールして画像スライダーの各画像を少なくとも 1 回表示すると、新しい画像セットをロードするときに、収集されない残りのガベージがいくつかあります。画像。
これにより、ヒープサイズが小さい (96 MB など) 電話機がクラッシュし、ヒープサイズが大きい (256 MB など) 電話機では、収集されていないガベージが約 100 MB になり、正当な使用済みメモリが 90 MB になるまで、この問題が数回悪化する可能性があります。
190/256MB のポイントに達すると、ガベージ コレクション システムが「機能」し始めたように見えますが、実際に機能している Bitmap.recycle() 呼び出しがまだわかりません。ヒープを再調整する必要がある場合、毎回 20MB のように大量のメモリを解放しますが、(Android Studio のボタンをクリックして) ガベージ コレクションを呼び出すだけでは解放されません。画像間をスライドします。
要約すると、画像スライダー/ViewPager の画像が表示されない場合、Bitmap.recycle() は期待どおりに実行されますが、それぞれの画像が少なくとも 1 回表示される場合、ガベージ コレクションは何らかの形で Bitmap.recycle() を無視しているようです。
これは、私が話していることを正確に示す画像です (これは Android v5.0(ART) 用です。v4.4(dalvik) の他の画像を参照してください)。
何が起こっているのかについての私の説明について質問があれば、明確にすることができます。
編集: Android 4.4 で同じアクションを実行すると、次のようになります。recycle() が呼び出されるたびに、約 20MB のメモリに減少することに注意してください。これは、ビットマップをカウントせずにアプリが使用するものです。
