コード内でヒープメモリを動的に空にする方法やクリアする方法

Question

私のアプリケーションでは、単純なギャラリーとカバーフローの両方を使用しています coverflowでクリックした画像にcoverflowイメージギャラリーを追加しました。私はフルスクリーンギャラリーをスクロールすることもできます。 私のアプリに画像や高解像度の画像をたくさん入れると、ビットマップサイズがVMの予算を超えているため強制終了する

私はカバーフローとギャラリーを終了するたびにヒープメモリをクリアしたいどのような量または任意の解像度の画像を私のアプリ のいずれかが私を助けることができる場合は読み込みます... 私のコードで自分の活動を動的に終了するたびにヒープメモリをクリア/空にする方法？ 私は既にリサイクルとSystem.gcメソッドを試しました

Answer 1

「ヒープをクリアする」ことはできません。オブジェクトはもはや参照されなくなったときに自動的に実行されます。

言われているように、ビットマップはアンドロイドでは厳しいものです。メモリが限られているため、画像をビットマップにデコードすると、圧縮された画像フォーマットそのものよりも多くのメモリを消費する可能性があります。

あなたの解決策には簡単な答えはありません。たとえすべてを正しく行っても、単にメモリ不足になる可能性があります。それは言っている、いくつかのヒントがあります：

1. を使用Bitmap.release()を使用しています。ビットマップは、ネイティブスタック（VMではなく）のヒープに割り当てられる点で特別です。 javadocは少し曖昧ですが、通常はこれを呼び出す必要はありませんが、私の経験では、ビットマップをバッキングするメモリを使って行われたこのVMの「手がかり」が重要です。 編集：Android 3.0（APIレベル11）では、ピクセルデータがDalvikヒープに関連付けられたビットマップとともに保存されます。

2. ビットマップをメモリにロード縮尺。ここにはblog postがあります。いくつかのデバイスでは24MBのヒープしか得られず、ビットマップオブジェクトにロードされたときに高解像度のイメージがすべて消耗する可能性があります。その周りには道がないので、あなたはそれを拡大しなければなりません。

3. 別の答えとしてSystem.gc()と呼んではいけません。 GCアルゴリズムを構築した人々は、あなたと私よりもスマートです。彼らは彼らが何をしているかを知っている。 GCを介して解放できるメモリがある場合、OOMEを取得することはありません.GCは常にあなたにOOMEを渡す前に実行されます。

4. これは明らかですが、ビットマップが不要になったときに参照を保持していないことを確認してください。

5. 最後に、この1つを吸うと、Androidはヒープ圧縮を行いません。ここに私はSO questionを投稿しましたが、満足のいく回答はありませんでした。要するに、Androidは決してヒープを圧縮しないので、あなたのアプリがビットマップのために大きな、あるいは中規模のチャンクを割り振り続けると、最終的にはメモリ不足ではなく、連続した十分な連続割り当てのためのメモリのチャンク、あなたはOOMEを取得します。 私の質問に書いたように、これを回避する方法は、ユーザーが終了するときにアプリのプロセスを終了することです。これにより、次回は起動が遅くなりますが、新しいヒープが保証されます。私は間違っていないでください。私はこれが正しいことだとは信じられませんが、誰も良い解決策を考え出していません。