从某种意义上讲，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
入门）。