この素晴らしいライブラリで見逃しているのは、NetworkImageView でビットマップをリサイクルしないという事実です。メソッド NetworkImageView.onDetachedFromWindow でリサイクルがどこかで呼び出された場合は完璧です。現在、ライブラリには、ビットマップをリサイクルせず、OOM 例外が発生するという重大なリークがあります。この概念を統合する計画があるかどうか誰か知っていますか?
質問する
1731 次
1 に答える
2
「ビットマップをリサイクルする」とは、Bitmap オブジェクトで .recycle() を呼び出すことを意味していると思います。
これにより OOM の状況が改善されると考える理由は何ですか? むかしむかし、Android (つまり 2.x) がこの問題に悩まされていたことは認めます。ビットマップはネイティブ ヒープに格納され、クリーンアップに (少なくとも) 2 つの GC パスが必要でした。recycle() を呼び出すと状況が改善される場合がありました。
Android 4.x 3.0 以降、これはあまり問題になりません。
ドキュメントでは、これは通常使用すべきではない高度な呼び出しと見なされていることに注意してください: http://developer.android.com/reference/android/graphics/Bitmap.html#recycle()
onDetachedFromWindow() でビットマップをリサイクルするというあなたの推奨事項については、これは悪い考えのようです。このメソッドは、ビューがウィンドウから切り離されたときに呼び出されます。ビューが後で再接続されないという保証はありません。onDetachedFromWindow() で Bitmap をリサイクルすると、View が Window に再接続されると例外がスローされます。
また、これが必要な場合は、ImageView 自体で処理できると思います。
記録として、Volleyはビューの境界内で画像をスケーリングしようとし、一度に 1 つのスレッドのみがビットマップをデコードできるようにすることで、OOM をかなりうまく処理します。
OOMの原因となっている他の問題があると思われます...
------------編集---------------
Android 開発者のコメント コメントの後、回答を更新しました。Volley はビューの境界内で画像を自動的にスケーリングしませんが、ImageRequest でサポートしています (コンストラクターを参照してください: https://android.googlesource.com/platform/frameworks/volley/+/master/src/com/ Android/volley/toolbox/ImageRequest.javaと maxWidth および maxHeight)
これは、適切な ImageRequest コンストラクターを使用するように NetworkImageView を変更する必要があることを意味します (ビューが最初に測定されるように注意する必要があります)。
于 2013-07-16T00:45:04.333 に答える