我注意到，在我的Galaxy Nexus的是 android.content.res.Resources 被分配约11MB。我发现这是我在分析使用DDMS和转储HPROF文件选项事情的过程。所以，我花了两个小时想看看是否分配是由于东西在我的code或支持库。我删除了我的所有数据，一吨的班，我所有的图书馆，看到没有任何变化。在活动的的onCreate（）方法的开头放置一个断点在我的code后，它表明，11MB分配已经present。

被彻底糊涂了之后，我决定将我的根Nook Color的运行CM7，看看它是报告为完全相同的应用程序的初始内存使用情况。在最坏的情况下记忆问题嫌疑人报道，通过垫的重量在只有896KB。

时ICS的头重脚轻？我失去了一些东西呢？据我所知，我的应用程序运行正常，但有堆使用情况表明全97％有我潜在的故障担心。

如果有帮助，MAT是表明消耗所有内存的主要对象是位图， BitmapDrawables 和 NinePatchDrawables 。我不明白的地方，这些拨款的来源。

pre-蜂窝（小于3.0），位图被分配在本机堆和垃圾场由Eclipse的MAT等如没有出现在Dalvik的堆这种原生的分配仍促成实现对应用程序的最大的Dalvik的堆限制，而且还造成垃圾收集逼近内存不足的情况​​时，运行在大约正确的时间。这种用法可以使用​​ Debug.getNativeHeapAllocatedSize进行测量（）。

由于Android 3.0（含ICS），现在分配在Dalvik的堆正常的字节数组位图的像素数据。这样做的实际效果是对位图（因为它们可以以更正统的方式进行处理）更好/简化垃圾收集行为，并在Dalvik的堆转储跟踪位图分配的能力。

我不认为为特定应用程序的实际内存使用量为pre-蜂窝和更新的版本之间显著的不同，并认为这是一种替代会计实务的只是一个问题。

为Android

Android中位图

I noticed that on my Galaxy Nexus that android.content.res.Resources is allocating about 11MB. I discovered this as I was in the process of profiling things using DDMS and the "Dump HPROF file" option. So, I spent two hours trying to see if the allocation was due to something in my code or supporting libraries. I removed all my data, a ton of classes, all my libraries, and saw no change. After placing a breakpoint in my code at the beginning of the onCreate() method of the activity, it showed that the 11MB allocation is already present.

After being thoroughly confused, I decided to connect my rooted Nook Color running CM7 to see what it was reporting for initial memory usage for the exact same application. The worst case memory "Problem Suspect" reported by the MAT weighs in at a mere 896KB.

Is ICS that top-heavy? Am I missing something here? As far as I can tell, my application is functioning correctly, but having the heap usage indicate 97% full has me worried about potential failures.

If it helps, MAT was indicating that the primary objects consuming all the memory were Bitmaps, BitmapDrawables, and NinePatchDrawables. I don't understand where these allocations are coming from.

Pre-Honeycomb (<3.0), Bitmaps were allocated in native heap and did not appear in Dalvik heap dumps as shown by Eclipse MAT, etc. This native allocation still contributed towards maximum Dalvik heap limits for an application, and still caused garbage collection to run at approximately the correct time when approaching a low memory situation. This usage can be measured with Debug.getNativeHeapAllocatedSize().

Since Android 3.0 (including ICS), it now allocates the pixel data for Bitmaps in normal byte arrays in Dalvik heap. The practical effects of this are better/simplified garbage collection behaviour for Bitmaps (since they can be treated in a more orthodox way) and the ability to track Bitmap allocations in Dalvik heap dumps.

I do not think the actual memory usage for a particular application is significantly different between pre-Honeycomb and more recent releases, and that this is just a matter of an alternative accounting practice.

Memory Analysis for Android

BitMaps in Android