ヒープメモリの大部分を使用しているように見える比較的軽量のアプリがあり（私の意見では）、ガベージコレクション後に縮小しません。
EclipseMemoryAnalyzerを使用してメモリリークを特定できませんでした。このツールに関する私の知識は非常に限られています。
LogCatからのスニペット：
（これはログダンプからの小さなスニペットにすぎないことに注意してください。LogCatは、アプリ内で何をしても、ガベージコレクションメッセージを継続的に出力するようです。ただし、空きヒープの量は比較的安定しており、（私には）次のことを示しています。実際のメモリリークはありませんか？）
01-22 17:04:51.672: D/dalvikvm(16274): GC_CONCURRENT freed 721K, 10% free 8074K/8968K, paused 4ms+7ms, total 33ms
01-22 17:04:53.742: D/dalvikvm(16274): GC_CONCURRENT freed 523K, 12% free 7977K/8968K, paused 4ms+5ms, total 29ms
01-22 17:04:54.012: D/dalvikvm(16274): GC_CONCURRENT freed 457K, 12% free 7941K/8968K, paused 3ms+2ms, total 29ms
01-22 17:04:56.432: D/dalvikvm(16274): GC_CONCURRENT freed 237K, 10% free 8116K/8968K, paused 2ms+2ms, total 22ms
01-22 17:04:58.632: D/dalvikvm(16274): GC_CONCURRENT freed 445K, 10% free 8094K/8968K, paused 3ms+3ms, total 33ms
01-22 17:05:00.332: D/dalvikvm(16274): GC_CONCURRENT freed 499K, 11% free 8013K/8968K, paused 1ms+10ms, total 33ms
01-22 17:05:00.582: D/dalvikvm(16274): GC_CONCURRENT freed 487K, 12% free 7916K/8968K, paused 3ms+6ms, total 38ms
01-22 17:05:02.382: D/dalvikvm(16274): GC_CONCURRENT freed 223K, 10% free 8107K/8968K, paused 3ms+3ms, total 23ms
01-22 17:05:03.882: D/dalvikvm(16274): GC_CONCURRENT freed 436K, 10% free 8107K/8968K, paused 9ms+12ms, total 76ms
01-22 17:05:05.392: D/dalvikvm(16274): GC_CONCURRENT freed 528K, 11% free 8059K/8968K, paused 2ms+3ms, total 35ms
01-22 17:05:06.962: D/dalvikvm(16274): GC_CONCURRENT freed 489K, 11% free 7998K/8968K, paused 4ms+3ms, total 32ms
01-22 17:05:07.212: D/dalvikvm(16274): GC_CONCURRENT freed 487K, 12% free 7928K/8968K, paused 3ms+3ms, total 29ms
01-22 17:05:08.832: D/dalvikvm(16274): GC_CONCURRENT freed 226K, 10% free 8094K/8968K, paused 3ms+3ms, total 22ms
01-22 17:05:12.152: D/dalvikvm(16274): GC_CONCURRENT freed 453K, 10% free 8080K/8968K, paused 4ms+3ms, total 48ms
上記は、ボタンのスパムや向きの変更を数回行う「頻繁な使用」の結果です。私の懸念は、ヒープの約10％だけが、さらに拡張するために空いている/残っているように見えるという事実です。
参考までに、現在のフラグメントのレイアウトを表すXMLファイル（上記の出力時）は、約25個のTableRow要素で構成されるTableLayoutを内部に持つScrollViewです。おそらく、これがヒープメモリのこのような大きなホギングの原因ですか？
これはまったく心配することですか？
私のコードのいくつかを見たい場合は私に知らせてください。前もって感謝します。
アップデート：
アプリは基本的に2つのフラグメントを含む1つのアクティビティです。上記のフラグメントの1つは、ユーザーの操作に基づいて他のフラグメントと交換されます。これを典型的なメニューコンテンツアプリ（デフォルトのAndroidコンタクトアプリなど）と考えてください。左側にMenuFragment（連絡先リスト）、右側にいくつかのContentFragment（連絡先の詳細）があります。これまでのところ、UIの動作を設定することを除いて、あまり多くの機能は含まれていません。バックグラウンドでは何も起こらず、状態の保存などもありません。私は基本的に、MenuFragmentからアイテムを選択したときに正しいフラグメントが表示されること、フラグメントが起動したときに正しいレイアウトが描画されること、ユーザーが戻るボタンを押したときに正しいフラグメントが表示されることを確認することに重点を置いています。