GC_FOR_MALLOC（Android 4.0后是GC_OR_ALLOC）
新创建的普通java对象，一般都是分配在堆内存中（GC日志的free项），而当堆内存剩余空间不够新建该java对象时，就会触发此类GC以增大堆内存的容量。这里对开发做内存优化的优化点就是尽量减少和减小创建的对象。
GC_EXPLICIT
显式GC，如我们在DDMS中主动触发的GC，或者是某些特殊行为，如主动调用System.gc()方法、一个线程被杀死、一个连接被停止，这些动作都会触发此类GC。这也是唯一一种有用的可以人为控制触发时机的GC。这里的优化点是在合适的时机（如用户无明显感知的时机）主动触发GC，可以减少其他类型GC的出现次数。
GC_CONCURRENT
并发GC，堆中的对象数量达到一定程度触发的垃圾回收，一般时间较短，用户不会有明显感知。但是出现的太频繁说明内存中对象数量增长太快，也需要关注。
GC_CONCURRENT freed 181K, 4% free 13957K/14407K, paused 2ms+5ms
GC_EXTERNAL_ALLOC
虚拟机尝试减少用于可回收对象的总的内存空间，为更多的不可回收对象挪地方。从下面例子看出，本类型GC操作前，Native已占用部分已快达到最大值，本类型GC操作后，external内存可分配空间增大了（个人实践感觉，external部分内存显示的更像是是本次GC前的数值？）。如下例。另外，GC_EXTERNAL_ALLOC类GC后，对应的free部分可分配空间不变，可以看出free部分和external部分是不支持进程内部转换的，新分配内存需要向虚拟机申请全局的空闲内存。
03-07 19:04:02.889: DEBUG/dalvikvm(571): GC_EXTERNAL_ALLOC freed 931K, 27% free 11129K/15239K, external 2836K/2842K, paused 103ms
03-07 19:04:08.064: DEBUG/dalvikvm(571): GC_EXPLICIT freed 374K, 29% free 10952K/15239K, external2764K/3162K, paused 183ms
GC_HPROF_DUMP_HEAP
从DDMS打出某个进程堆信息时会触发此GC，正常系统不会自动触发，不需要关注。
GC_HPROF_DUMP_HEAP freed 25K, 29% free 10931K/15239K, external 2552K/3162K, paused 7761ms