GC日志分為兩種情況，Dalvik虛擬機下的GC日志和ART虛擬機下的GC日志。

1、Dalvik

Dalvik虛擬機下的GC格式日志如下：

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

引起GC原因

? 引起GC的原因有以下5種：

• GC_CONCURRENT：堆快被用完的時候，就會觸發這個GC回收內存。
• GC_FOR_MALLOC：當堆內存已滿時，app嘗試分配內存而引起的GC，系統必須停止app并回收內存。
• GC_HPROF_DUMP_HEAP：當你請求創建 HPROF 文件來分析堆內存時出現的GC。
• GC_EXPLICIT：顯示的GC，例如調用System.gc()（應該避免調用顯示的GC，信任GC會在需要時運行）。
• GC_EXTERNAL_ALLOC：僅適用于 API 級別小于等于10 ，用于外部分配內存的GC。

其他信息

• Amount_freed：本次GC釋放內存的大小。
• Heap_stats：堆的空閑內存百分比 （已用內存）/（堆的總內存）。
• External_memory_stats：API 級別 10 及更低級別的內存分配 （已分配的內存）/（引起GC的閥值）。
• Pause time：暫停時間，更大的堆會有更長的暫停時間。并發暫停時間顯示了兩個暫停：一個出現在垃圾收集開始時，另一個出現在垃圾收集快要完成時。

案例介紹：

D/dalvikvm: GC_FOR_ALLOC freed 4499K, 30% free 14182K/20024K, paused 40ms, total 40ms

這個GC日志的含義為：引起GC的原因是GC_FOR_ALLOC；本次GC釋放的內存為4499K；堆的空閑內存百分比為30%，已用內存為14182K，堆的總內存為20024K；暫停的總時長為40ms。

2、ART

ART的GC日志與Dalvik不同，ART 不會為沒有明確請求的垃圾收集打印GC日志。只有在認為GC速度慢時才會打印GC日志（僅在GC暫停超過5ms 或GC持續時間超過 100ms 時才會打印GC日志）。如果app未處于可察覺的暫停進程狀態，那么它的GC不會被認為是慢速的。ART的GC日志始終會記錄顯式的垃圾收集。

ART的GC日志具體的格式為：

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

引起GC原因
ART的引起GC原因（GC_Reason）要比Dalvik多一些，有以下幾種：

• Concurrent： 并發GC，不會使App的線程暫停，該GC是在后臺線程運行的，并不會阻止內存分配。
• Alloc：當堆內存已滿時，App嘗試分配內存而引起的GC，這個GC會發生在正在分配內存的線程。
• Explicit：App顯示的請求垃圾收集，例如調用System.gc()。與Dalvik一樣，最佳做法是應該信任GC并避免顯示的請求GC，顯示的請求GC會阻止分配線程并不必要的浪費 CPU 周期。如果顯式的請求GC導致其他線程被搶占，那么有可能會導致 jank（App同一幀畫了多次)。
• NativeAlloc：Native內存分配時，比如為Bitmaps或者RenderScript分配對象， 這會導致Native內存壓力，從而觸發GC。
• CollectorTransition：由堆轉換引起的回收，這是運行時切換GC而引起的。收集器轉換包括將所有對象從空閑列表空間復制到碰撞指針空間（反之亦然）。當前，收集器轉換僅在以下情況下出現：在內存較小的設備上，App將進程狀態從可察覺的暫停狀態變更為可察覺的非暫停狀態（反之亦然）。
• HomogeneousSpaceCompact：齊性空間壓縮是指空閑列表到壓縮的空閑列表空間，通常發生在當App已經移動到可察覺的暫停進程狀態。這樣做的主要原因是減少了內存使用并對堆內存進行碎片整理。
• DisableMovingGc：不是真正的觸發GC原因，發生并發堆壓縮時，由于使用了 GetPrimitiveArrayCritical，收集會被阻塞。一般情況下，強烈建議不要使用 GetPrimitiveArrayCritical，因為它在移動收集器方面具有限制。
• HeapTrim：不是觸發GC原因，但是請注意，收集會一直被阻塞，直到堆內存整理完畢。

垃圾收集器名稱
GC_Name指的是垃圾收集器名稱，有以下幾種：

• Concurrent mark sweep (CMS)：CMS收集器是一種以獲取最短收集暫停時間為目標收集器，采用了標記-清除算法（Mark-Sweep）實現。 它是完整的堆垃圾收集器，能釋放除了Image Space之外的所有的空間。
• Concurrent partial mark sweep：部分完整的堆垃圾收集器，能釋放除了Image Space和Zygote Spaces之外的所有空間。關于Image Space和Zygote Spaces可以查看Android內存優化（一）DVM和ART原理初探這篇文章。
• Concurrent sticky mark sweep：分代收集器，它只能釋放自上次GC以來分配的對象。這個垃圾收集器比一個完整的或部分完整的垃圾收集器掃描的更頻繁，因為它更快并且有更短的暫停時間。
• Marksweep + semispace：非并發的GC，復制GC用于堆轉換以及齊性空間壓縮（堆碎片整理）。

其他信息

• Objects freed：本次GC從非Large Object Space中回收的對象的數量。
• Size_freed：本次GC從非Large Object Space中回收的字節數。
• Large objects freed： 本次GC從Large Object Space中回收的對象的數量。
• Large object size freed：本次GC從Large Object Space中回收的字節數。
• Heap stats：堆的空閑內存百分比 （已用內存）/（堆的總內存）。
• Pause times：暫停時間，暫停時間與在GC運行時修改的對象引用的數量成比例。目前，ART的CMS收集器僅有一次暫停，它出現GC的結尾附近。移動的垃圾收集器暫停時間會很長，會在大部分垃圾回收期間持續出現。

實例介紹

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

這個GC日志的含義為：引起GC原因是Explicit ；垃圾收集器為CMS收集器；釋放對象的數量為104710個，釋放字節數為7MB；釋放大對象的數量為21個，釋放大對象字節數為416KB；堆的空閑內存百分比為33%，已用內存為25MB，堆的總內存為38MB；GC暫停時長為1.230ms，GC總時長為67.216ms。
————————————————
參考鏈接：Android內存優化（二）DVM和ART的GC日志分析

總結

以上是生活随笔為你收集整理的Android GC日志的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。