调查内存使用情况时，GC_FOR_ALLOC是否更“严肃”？

调查内存使用情况时，GC_FOR_ALLOC是否更“严肃”？

从某种意义上讲，

GC_FOR_ALLOC

它比更为严重

GC_CONCURRENT

，因为这

GC_FOR_ALLOC

意味着没有足够的可用内存来满足分配请求，因此必须进行垃圾回收，而

GC_CONCURRENT

这仅意味着GC感觉像在运行，通常是因为可用内存量变得低于分配后的某个阈值。

但是，A

GC_FOR_ALLOC

本身并不表示您的应用程序有问题：

• Android应用程序以一个小的堆开始，当应用程序需要越来越多的内存时，该堆会增长（达到一定程度），并且

  GC_FOR_ALLOC

  在增加堆大小之前先完成一个堆。在这种情况下

  GC_FOR_ALLOC

  是完全正常的。
• 如果分配内存的速度快于并发GC有时间释放内存，这

  GC_FOR_ALLOC

  是不可避免的。而且，分配内存的速度没有比并发GC释放内存的速度固有的错误。

在Android上

GC_BEFORE_OOM

，更严重的GC类型是，当分配请求失败后

GC_FOR_ALLOC

，甚至在应用程序堆增长到允许的最大大小时，也会执行GC
。当发生这种情况时，作为最后的选择，Dalvik将在尝试最后一次分配内存之前，也尝试释放SoftReferences，如果失败，则抛出OutOfMemory异常。

如果您想查看此逻辑的代码

tryMalloc()

，请参阅dalvik.git / vm / alloc /
Heap.cpp中的代码。

无论如何，如果您不介意的话，我怀疑查看logcat输出是调试垃圾回收问题的最有效方法。我不知道您遇到什么具体问题，但是您是否研究过DDMS中的“分配跟踪器”之类的

hprof-conv

工具，并借助该工具分析堆转储？（例如，请参见http://android-
developers.blogspot.se/2011/03/memory-analysis-for-
android.html
入门）。