ringa_lee2017-04-17 15:50:42
android:largeHeap="true"
ピクチャー ウォールが読み込まれた後、90% 以上のメモリが必要になります。developer.android.com/training/displaying-bitmaps/process-bitmap.html で使用される公式チュートリアルにもビットマップ メモリ リークの問題があります。アクティビティに入るときと出るときのメモリ量は約 1% 増加しますが、ロードされる画像の最大数はほぼ同じです。 ！
Android 自体がビットマップの問題を処理する準備ができていないのではないかと思います
ringa_lee2017-04-17 15:50:42
ツールが理想的かどうかについては話さず、メモリ使用量を削減する方法について説明しましょう。
通常の方法は、Options.inSampleSize を使用してサンプリングすることですが、これにより画質が低下しますが、効果的です。
universal-imageloader によって提供されています。 config に関連する設定がありますが、ソース コードを見ると、デフォルトの設定では画像が画面解像度より小さい場合に縮小されないことがわかります。この場合、universal-imageloader は inSampleSize=1、つまりサンプリングなしで処理します。
したがって、私の処理方法は、ソース コードに基づいて変更し、いくつかのサンプリングを追加することです。画像が現在のものより小さい場合でも、画面の解像度はサンプリングのために制御できます。元の構成と比較して、このメモリ使用量は削減されます (サンプリング サイズ + 1 メモリ使用量が 75% 削減されるはずです)。理論的には画像の効果は悪くなりますが、実際には携帯電話の解像度は向上していますが、サムネイルの場合、この損失は肉眼では判断できません。
さらに、imageloader については、.bitmapConfig (Bitmap.Config.RGB_565) を使用することでメモリ使用量を削減することもできます。これについては、公式ドキュメントで説明されています。
さらに、繰り返しました。アクティビティに参加したり終了したりすると、この問題が発生します。これらのフレームワークを組み合わせることは考えていません。
大家讲道理2017-04-17 15:50:42
「繰り返し入力」するとオーバーフローするため、メモリ リークが発生する可能性があります。
ヒープをダンプして、誰がビットマップ参照を保持しているかを確認できます
阿神2017-04-17 15:50:42
「アクティビティには 100 枚以上の写真があります。」
すべてを表示しますか? 一部のみを表示する必要があります。
その他の場合は、対応する位置までスライドしてから表示してください
大家讲道理2017-04-17 15:50:42
OOM がオーバーフローした場合は、Java 層でのリークに違いありません。MAT を使用して参照状況を分析します。
android:largeHeap="true" のメソッドは、OOM の出現を遅らせるだけです。
