ヒープサイズが大きい原因の特定と修正
アプリが大量のメモリを使用している理由を解明しようとしています。 15〜18 MBを使用していることがよくありますが、これは予想よりも大幅に高くなっています。 DDMSを介してヒープサイズを調べたところ、次のことがわかりました。
私のアプリは大きな画像をまったく処理しないので、それは少し疑わしいように見えました。実際、私のアプリのドローアブルの合計は約250KBです。そこで、ヒープダンプを作成し、MATを使用してこのすべてのメモリの行き先を特定しました。 byte []配列は圧倒的に最大の消費者だったので、ドリルダウンして次のことに気づきました。
SPreloadedDrawablesがこのように高い保持ヒープサイズの原因である理由はまったくわかりません。また、根本原因を特定する方法や、それを「修正」する方法もわかりません。
ここからどこへ行けばいいの？私のアプリは、画像データをまったく処理しないサービスを介して、ほとんどバックグラウンドで動作します。ユーザーが使用することを選択できるアクティビティがありますが、ここでも、そのような大きなヒープサイズを説明しない小さなドローアブルを使用しています。また、アクティビティリークなどの厄介な発生をチェックしましたが、見つかりませんでした。
編集：エミュレーターで実行すると、ヒープサイズが大幅に小さくなることに気付きました。これはかなり紛らわしいです。 ：/
システムはデフォルトのシステムリソースをプリロードします。これは、チェックボックスやラジオボタンの標準のDrawableなど、アプリのリソースとは無関係です。 10.5MBは大きいように見えますが、デフォルトのシステムリソースがたくさんあり、メモリに保存されると画像は大きくなります。プリロードは新しいものではありませんが、ICSではプリロードのサイズが大きくなる可能性があります。ディスプレイ密度は、ICSにプリロードされたシステムDrawableを追加するだけで、おそらくこれに影響します。
現在、sPreloadedDrawablesが保持するメモリを削減する方法はありません。
システムのDrawableのほとんどを使用しないアプリ（特にゲーム）に対してアプリプロセスが生成された後、これをクリアする方法がないのは残念です。この場合、プリロードリソースのサイズが大きいことは、ICSの特定のリリース（またはハンドセットポート）のバグであるように思われます。それ以外の場合、通常は少量のメモリであるため、プリロードメモリの使用量を減らすためにこのようなメカニズムが必要になることはないと思います。
このキャッシュの結果としてメモリが不足している場合は、おそらくGoogleにバグレポートを提出します。
内部の詳細に関心がある場合は、ここでリソースのプリロードプロセスを追跡できます。 ZygoteInit.preloadResources