我有一个相对轻量级的应用程序，它似乎使用了大部分堆内存(在我看来)并且在垃圾收集后它没有缩小。
我无法使用 Eclipse 内存分析器识别任何内存泄漏。虽然我对这个工具的了解非常有限。
来自 LogCat 的 fragment :
(请注意，这只是日志转储中的一小段。无论我在我的应用程序中做什么，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% 的堆是空闲的/留给进一步扩展的。
供您引用，表示当前 fragment 布局(在上述输出时)的 XML 文件是一个内部带有 TableLayout 的 ScrollView，由大约 25 个 TableRow 元素组成，也许这就是堆占用如此之大的原因内存？
这有什么值得担心的吗？
如果您想查看我的一些代码，请告诉我。提前致谢。
更新:
该应用基本上只是一个包含两个 fragment 的 Activity。根据用户交互，其中一个 fragment 与其他 fragment 交换。 将其视为典型的菜单内容应用程序(如默认的 Android 联系人应用程序)。左侧的 MenuFragment(联系人列表)和右侧的一些 ContentFragment(联系人详细信息)。到目前为止还没有太多的功能 除了设置 UI 行为外。后台没有发生任何事情，没有保存状态或类似内容。我基本上专注于确保 当我从 MenuFragment 中选择一个项目时会显示正确的 fragment ，当 fragment 启动时会绘制正确的布局，并且正确的 fragment 当用户按下后退按钮时显示。
最佳答案
堆将根据您的应用程序的需要自动调整其大小。小型堆在 GC 上速度更快，因此如果您不需要，Android 不会以 64 MB 的堆开始。当您的应用程序使用大量当前堆时，堆对于 Android 4.x 应用程序来说非常小。仅一个简单的 4.x 应用程序将使用 7Mb。在我看来，你很好。
关于使用大部分堆的 Android 应用程序，无法成功识别内存泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14463788/