5

私たちのアプリのメモリ使用量を分析していて、Drawables数メガバイトのヒープを常に「食べる」奇妙な を発見しました。以下は、MATのスクリーンショットです。

ドミネーターツリー 2 つのかなり大きなビットマップを持つドミネーター ツリー

path_to_gc_roots 上記のビットマップのいずれかの GC ルートへのパス

このビットマップは、アプリの使用時間や集中度に関係なく、携帯電話 ( Samsung Galaxy Nexus、OS 4.1.1 )のヒープ ダンプに常に表示されます。

私はすでに MAT を使用してこのビットマップのソースを検索しようとしましたが、うまくいきませんでした。私が見つけることができたすべての有用な情報は、ビットマップでwidthありheight、両方とも512x512です。 bitmap_info

しかし、私たちのアプリには 512x512 のドローアブルが 1 つもありません。これは「システム」のドローアブルだと思います。しかし、正確には何ですか？なぜそんなに大きいのですか？

android.content.res.Resourcesクラスのソースコードも調べて、sPreloadedDrawablesフィールドの使用法を検索しましたが、運もありませんでした。メモリ ダンプから得られるのはkey配列sPreloadedDrawablesだけですが、このキーからファイル名またはリソース ID を特定できません。

だから、私の質問は次のとおりです。

  • このビットマップの名前または ID を特定するにはどうすればよいですか?

  • この巨大なビットマップがロードされる理由と、それらが常にメモリにとどまる理由は何ですか?

更新：

メモリ ダンプからこのビットマップを調べる方法を見つけました。この 2 つのビットマップは単純なグラデーションで、1 つは黒、もう 1 つは白です。これはHolo.LightおよびHolo.DarkICS テーマのリソースだと思います。しかし、私の 2 番目の質問はまだ現実的です: なぜこのビットマップは常にメモリに残るのでしょうか? それらをアップロードまたはリサイクルする方法はありますか?

4

3 に答える 3

0

プロジェクトに含める必要がある android.jar からのこの写真。垂直方向のグラデーションを持つ 2 つの正方形があります。1 つ目は 0x000000 から 0x272d33 まで、2 つ目は 0xe8e8e8 から 0xfafafa までです。それらは android.jar/res/drawable-nodpi/background_holo_dark.png と background_holo_light.png にあります。もちろん、Android SDK のバージョンによって異なる結果が得られる可能性があります。

于 2012-10-01T15:13:54.197 に答える
0

それらはアクティビティのデフォルトの背景であるため、メモリに残ると思います。テーマで別の背景を指定してみて、それらがまだそこにあるかどうかを確認してください。

于 2012-10-05T15:17:01.053 に答える