Dalvik Log信息

在Dalvik（不是ART）模式下，每次FC会在logcat输出如下信息：

D/dalvikvm:<GC_Reason> <Amount_freed>, <Heap_stats>,<External_memory_stats>, <Pause_time>

一、GC_Reason触发垃圾回收的回收的集中原因：

类型

描述

GC_CONCURRENT

堆内存使用将满时，并发的进行垃圾回收。

GC_FOR_MALLOC

当堆内存已满应用尝试分配内存时会出触发垃圾回收，所以系统会停止应用进行垃圾整理

GC_HPROF_DUMP_HEAP

请求创建一个用来分析heap的HPROF文件，当创建HPROF文件分析内存时触发垃圾收集。

GC_EXPLICIT

显示的垃圾收集，例如当你调用gc()（应该避免调用，而是交由系统处理）

GC_EXTERNAL_ALLOC

外部内存分配，只会在API10以下版本触发。新版都只会在DalvikHeap上分配。

Amount_freed
Heap_stats  :heap
中可用内存所占百分比，以及
[
已使用内存大小
]/[heap
总大小
]
External_memory_stats:
外部内存统计数据
(
在
API10
和更低版本中，外部分配的内存
)
Pause_time  
：
GC
时暂停的时间
注：当回收原因为
时，此时停顿包含两部分，第一次标记
root
集合停顿的时间，第二次标记集合停顿时间，其他回收的方式都只有一次停顿时间。

ART Log信息

与Dalvik不同，ART不会log非显式（隐式）请求的GC，GC只会在被判定为很慢时输出信息。更准确地，条件是GC停顿超过5ms，或者GC耗时超过100ms。如果app不是处于一种可察觉的停顿状态，那么GC不会就被判定为很慢，而显式GC会被log出来。

ART Log格式如下：

I/art: <GC_Reason><GC_Name> <Objects_freed>(<Size_freed>) AllocSpaceObjects, <Large_objects_freed>(<Large_object_size_freed>)
<Heap_stats> LOS objects, <Pause_time(s)>
GC_Reason
：
Concurrent:
Alloc    
： 当堆已经满时，此时应用尝试去分配堆内存，此时会触发
GC
动作。
Explicit 
：
GC
动作被应用主动调用，例如，调用
gc()
或
gc().
，在
ART
中，尽量避免使用主动调用
GC
的方式，因为主动调用
GC
会阻塞内存分配线程和消耗不必要的
cpu
时间，
注：jank是指第n帧绘制过后，本该绘制第n+1帧，但因为CPU被抢占，数据没有准备好，只好再显示一次第n帧，下一次绘制时显示第n+1帧。



NativeAlloc
：
CollectorTransition：在运行时开关GC会导致heap转换，从而导致收集的动作。收集器转换由拷贝所有对象从一个free-listbacked空间到一个bump
pointer空间（或者相反），当前收集器转换仅发生在当一个应用改变进程状态（从可见的暂停到一个可见的非暂停状态（或者相反）在低ram设备中）时。
HomogeneousSpaceCompact:
。
：
。
HeapTrim
：
。



GC Name



Concurrent mark sweep(CMS)
全堆垃圾收集器，负责收集释放除image外的所有空间
Concurrent partial mark sweep
几乎全堆垃圾收集除了
image
和
zygote
外的所有堆
Concurrent sticky mark sweep
。
Marksweep + semispace



Objects_freed
。



Size_freed
。



Large_objects_freed
。



注：
ART还引入了一个特殊的超大对象存储空间(large
object
space，LOS)，这个空间与堆空间是分开的，不过仍然驻留在应用程序内存空间中。这一特殊的设计是为了让ART可以更好的管理较大的对象，比如位图
对象(bitmaps)。在对堆空间分段时，这种较大的对象会带来一些问题。比如，在分配一个此类对象时，相比其他普通对象，会导致垃圾收集器启动的次数
增加很多。有了这个超大对象存储空间的支持，垃圾收集器因堆空间分段而引发调用次数将会大大降低，这样垃圾收集器就能做更加合理的内存分配，从而降低运行
时开销。



Large_object_size_freed
本次GC从大对象空间里回收的字节数。



Heap_stats
。



Pause_time(s)
一般情况下，GC运行时，停顿次数和被修改的对象引用数成比例。目前，ART
CMS GC只会在GC结束的时停顿一次，GC过渡会有一个长停顿，是GC时耗的主要因素