0

私のアプリのアクティビティにはフラグメントが含まれており、フラグメントにはビットマップ データでいっぱいのリストビュー/グリッドビューが含まれています。前のアクティビティとそのフラグメントのビューが破棄されないため、最終的にはユーザーのメモリが不足します。したがって、ユーザーが 10 番目のアクティビティに到達すると、9 つ前のアクティビティで大量のビットマップ データが保持されます。

私はすでにweakrefencesを使用していますが、MATは、一部のフラグメントのビューが、たとえばアダプターなどを保持するGalleryへの参照を保持していると述べています。

これまでのところ、フラグメントを完全に削除し、アダプターを削除して実験しました。うまくいくこともありますが、なぜこれがそれほど複雑なのか、そしてあまりコーディングせずに解放/取得する簡単な方法があるのだろうか?

UPD

同じ問題に挑戦しているオープンソースアプリの例をいただければ幸いです。

UPD2

私の活動のほとんどの青写真は次のとおりです。活動はフラグメントを保持します。フラグメントは、イメージビューでいっぱいの AbslistView を保持します。

ありがとう。

4

4 に答える 4

1

すべてのメモリを使い果たすことなくそれを実行することは困難です。

これには、オンデマンド (再) 読み込み、ビューの破棄時にメモリを解放すること、およびフラグメントとクラスを慎重に設計することが必要です。

https://developer.android.com/training/displaying-bitmaps/index.htmlには、画像をそのようにロードすることに関する貴重な情報があります。

ある種の非同期キャッシングローダーを介してすべての画像をロードする場合は、必要に応じてキャッシュをクリアしonViewDestroyed、onDetached問題のほとんどを削除したはずのビットマップへの他の参照を保持しないでください。

ライフサイクルはかなり対称的 ( onCreate<> onDestroy、...) であるため、そのライフサイクル部分の反対側で作成した参照を無効にすることをお勧めします。ライフサイクルで適切な場所を使用すると仮定すると、多くのメモリ管理が無料で得られます。あなたの場合、フラグメントが保持されている場合は、Galleryまたはへの参照を保持していないことを確認する必要があります ( ->ImageViewの間にのみ存在する必要があります)onCreateViewonDestroyView

于 2012-08-29T14:28:32.933 に答える
1

Android アプリのメモリ管理Google IO 2011 プレゼンテーションを見ることをお勧めします。

また、アプリのワークフローを調べて、古いアクティビティの破棄や他のリソースの解放をいつ開始できるかを判断する必要があります。

ActivityManager.getProcessMemoryInfo()を使用してプロセスのメモリ使用量情報を取得し、古いリソースを解放する必要があるかどうかを判断することもできます。

于 2012-08-29T14:17:44.593 に答える
1

必要なものだけをメモリに保持し、それ以外はすべて破棄することをお勧めします。利用可能なすべてのメモリを使い果たすのは悪い形です。アクティビティのライフサイクルを見て、問題を解決するために完全に理解します: https://developer.android.com/reference/android/app/Activity.html

于 2012-08-29T14:14:53.363 に答える
0

アダプタの getView メソッドで outofmemory 例外が発生した場合、

通常発生する行を分離し、次のように try-catch で囲むことができます。

try {
   // load image (or whatever your loadimage is)
    mViewHolder.thumbImage.loadImage();
} catch (OutOfMemoryError e) {
   // clear your image cache here if you have one
   // call gc
   System.gc();
   // load image retry
   mViewHolder.thumbImage.loadImage();
}

世界で最もエレガントなソリューションではありませんが、役立つはずです。

于 2012-08-29T14:29:02.357 に答える