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