我注意到我的Galaxy Nexus android.content.res.Resources正在分配大约11MB。我发现这是因为我正在使用DDMS和“Dump HPROF file”选项分析事物。所以，我花了两个小时试图查看分配是由于我的代码或支持库中的某些内容。我删除了所有数据，大量的类，我的所有库，并没有看到任何变化。在活动的onCreate()方法开头的代码中放置一个断点后，它显示已经存在11MB的分配。
在彻底混淆之后，我决定连接我运行CM7的root用户Nook Color，看看它是针对完全相同的应用程序的初始内存使用情况报告的内容。由MAT报告的最坏情况记忆“问题可疑”的重量仅为896KB。
ICS是头重脚轻的吗？我在这里错过了什么吗？据我所知，我的应用程序运行正常，但堆使用情况表明97％已满，让我担心潜在的故障。
如果有帮助，MAT表示消耗所有内存的主要对象是位图，BitmapDrawables和NinePatchDrawables。我不明白这些分配来自哪里。
答案 0 :(得分：6)
Pre-Honeycomb（＆lt; 3.0），Bitmaps在本机堆中分配，并没有出现在Eclipse MAT等所示的Dalvik堆转储中。这种本机分配仍然有助于应用程序的最大Dalvik堆限制，并且仍然导致垃圾收集在接近低内存情况时大约在正确的时间运行。可以使用Debug.getNativeHeapAllocatedSize()来衡量此用法。
自Android 3.0（包括ICS）以来，它现在在Dalvik堆中的普通字节数组中为Bitmaps分配像素数据。这样做的实际效果是Bitmaps的更好/简化的垃圾收集行为（因为它们可以以更正统的方式处理）以及跟踪Dalvik堆转储中的Bitmap分配的能力。
我不认为特定应用程序的实际内存使用量在前Honeycomb和更新版本之间存在显着差异，而这仅仅是另一种会计实践的问题。