大型堆的大小定位和纠正的原因 [英] Locating and remedying cause of large heap size

问题描述

我试图找出为何我的应用程序正在使用这么多的内存。我经常看到它用15至18MB，这是相当高的，比我期待的。我接过来一看，透过DDMS堆大小，看到这样的：

I'm trying to work out why my app is using so much memory. I often see it using between 15 and 18MB, which is substantially higher than I'd expect. I took a look at the heap size via DDMS and saw this:

这看着一点点可疑的，因为我的应用程序不会有大的图像处理的。事实上，可绘制在我的应用程序的总和为约250KB。所以，我创建了一个堆转储并用MAT来定位这一切​​的记忆去。字节[]数组是迄今为止最大的消费者，让我钻下来，发现了以下内容：

That looked a tad suspicous because my app doesn't deal with large images at all. In fact the total sum of the drawables in my app is about 250KB. So I created a heap dump and used MAT to locate where all this memory was going. byte[] arrays were by far the greatest consumer, so I drilled down and noticed the following:

我完全不知道为什么小号preloadedDrawables负责这么高的保留堆大小。我也有不知道如何找出根本原因，或者如何解决了。

I have absolutely no idea why sPreloadedDrawables is responsible for such a high retained heap size. I also have no idea of how to identify the root cause, or how to 'fix' it.

我应该在哪里何去何从？我的应用程序，通过它不处理图像数据的所有服务工作主要是在后台。我有，用户可以选择使用活动，但同样，他们使用的小型可绘不解释这么大的堆大小。我也查活动泄漏等任何讨厌occurances，但没有找到任何。

Where should I go from here? My app works mostly in the background via services which don't deal with image data at all. I do have Activities that the user may choose to use, but again, they use small drawables which don't explain such a large heap size. I also checked for any nasty occurances of Activity leaks etc, but didn't locate any.

任何想法？

编辑：我注意到，在模拟器中运行时堆的大小是低得多。这是相当混乱。 ：/

I noticed that the heap size is substantially lower when run in the emulator. This is quite confusing. :/

推荐答案

，系统将preLOAD默认的系统资源，这是独立于您的应用程序资源，像标准的可绘制的复选框和单选按钮。 10.5MB似乎很大，但也有很多默认的系统资源和图像越大，一旦存储在内存中。 preloading是不是新的，而是preLOAD规模可能在ICS更大。显示密度可能与简单地增加ploaded在ICS更多的系统可绘制$ P $起着这项工作的一部分。

The system will preload the default system resources, this is independent of your app resources, things like standard Drawables for check boxes and radio buttons. 10.5MB does seem large but there are a lot of default system resources and the Images are bigger once stored in memory. Preloading is not new, but the size of preload could be larger in ICS. Display density probably plays a part in this along with simply the addition of more system Drawables preloaded in ICS.

目前还没有办法来减少持有的内存取值preloadedDrawables

There is currently no way to reduce the memory held by the sPreloadedDrawables

不幸的是，没有一种方法来清除此之后，应用程序进程产生的应用程序（尤其是游戏）不使用大多数系统可绘制的。在这种情况下，尽管preLOAD资源的大尺寸似乎已经与ICS的特定版本（或听筒端口）的错误。它是一切正常少量的内存，所以我怀疑它会永远需要有这样一个机制，以减少preLOAD内存使用。

It is unfortunate that there isn't a way to clear this after the app process is spawned for apps (especially games) that don't use most of the system Drawables. In this case though the large size of the preload resources seems to have been a bug with a specific release (or handset port) of ICS. It is otherwise normally a small amount of memory, so I doubt it would ever be necessary to have such a mechanism to reduce the preload memory use.

如果您正在运行内存，因为这缓存的结果，那么我可能会文件到谷歌的bug报告。

If you are running out of memory as a result of this cache then I'd probably file a bug report to Google.

您可以通过资源preLOAD过程跟踪在这里，如果你有兴趣了解更多内部细节。 <一href="http://grep$c$c.com/file/repository.grep$c$c.com/java/ext/com.google.android/android/4.0.3_r1/com/android/internal/os/ZygoteInit.java#ZygoteInit.$p$ploadResources%28%29">ZygoteInit.$p$ploadResources

You can trace through the resource preload process here if you are interested in more internal details. ZygoteInit.preloadResources

这篇关于大型堆的大小定位和纠正的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！