私のondestroyメソッドでは、私はメモリを解放し、画面の回転中にアプリケーションがクラッシュするのを防ぐために使用したすべてのビットマップをリサイクルします。これは、アイスクリームサンドイッチ（アンドロイド4.0）まですべてのapisのために行う正しいことであることが証明されています。今、私がICSで回転するとき、私は力を得て、logcatは役に立たない。コードに戻すことはできませんが、ビットマップのリサイクルを取り除くと、ICSにとってはうまくいきます。これに関するアイデア？リサイクルビットマップアイスクリームサンドイッチ強制終了
リソースから取得したビットマップをリサイクルしていますか？ OSがビットマップへの参照を保持し、それを同じリソースへの将来の呼び出しに使用するように聞こえる。その場合、画面が回転すると、リサイクルしたのと同じビットマップを使用しようとします。これにより、強制的に閉じることになります。
ビットマップを手動でリサイクルする必要はありません。これは非常に危険な呼び出しです。特に、リソースからロードされたビットマップではそうです。
はい、私はリソースから来たビットマップをリサイクルしています。私はリサイクルを呼びかけることなくOKですが、それが非ICSバージョンのOutOfMemoryErrorsを防ぐために見つけた唯一の方法です。何か提案はありますか？私はFroyo以上で動作するようにこれが必要です.... – JLK
私たちのアプリでは、我々はダウンロードし、多くの画像をキャッシュします。まだ使用されているかどうかはわかりませんので、しばらく毎回System.gc（）を呼び出します。以前にrecycle（）を呼び出していた場所でSystem.gc（）を呼び出すことができます。さらに、OutOfMemoryErrorsをtry/catchで囲み、System.gc（）の後に再試行します。 –
私が理解しているように、System.gc（）は、ICSコード以前のビットマップメモリリークを助けません。 「ビットマップをリサイクルしないと画像が集中するアプリが死んでしまう」から「イメージリッチなビットマップをリサイクルすると画像が大量のアプリが死んでしまう」というものから、バージョン間でサイレントに変更された場合、私は最も感銘を受けた開発者です。 – Adrian
これは無関係かもしれませんが、最近私は*初期メモリ使用量がICSに上がったことを知りました。私はそれが今すべてのdrawablesを先読みしていると信じています。おそらく、あなたがdrawableへの参照を持っていなくても、フレームワークはまだそれを行い、リサイクルしたビットマップを設定しようとしていますか？ – dmon
onDestroy（）以降にクラッシュが発生しているかどうかを確認できますか？発見に役立ついくつかの場所にLog.d（TAG、 "メッセージ"）コールを張っているとしますか？実際のrecycle（）呼び出し中であれば、isRecycled（）がfalseを返すBitmapオブジェクトに対してのみrecycle（）を呼び出すとどうなりますか？ –