Android开发者如何查看垃圾回收器(GC)的回收对象

API 探路者

2026-7-7

分析Android GC日志并定位回收对象

我是一名Android开发者，反复收到以下GC提示日志（非错误信息），为优化应用性能，想了解垃圾回收器正在回收的对象，目前已尝试使用Android Studio Profiler。

15:39:42.527  9559-9569  e.myproj.dem          com.myProject.demo          I  Background young concurrent copying GC freed 55849(2383KB) AllocSpace objects, 153(24MB) LOS objects, 43% free, 30MB/54MB, paused 65us,49us total 151.697ms
15:39:43.662  9559-9569  e.myproj.dem          com.myProject.demo          I  Background concurrent copying GC freed 64582(2659KB) AllocSpace objects, 164(25MB) LOS objects, 42% free, 32MB/56MB, paused 63us,52us total 320.779ms
15:39:44.634  9559-9569  e.myproj.dem          com.myProject.demo          I  Background young concurrent copying GC freed 57308(2367KB) AllocSpace objects, 153(23MB) LOS objects, 43% free, 31MB/55MB, paused 61us,49us total 150.726ms
15:39:45.795  9559-9569  e.myproj.dem          com.myProject.demo          I  Background concurrent copying GC freed 65080(2687KB) AllocSpace objects, 169(26MB) LOS objects, 43% free, 31MB/55MB, paused 70us,51us total 322.406ms
15:39:46.776  9559-9569  e.myproj.dem          com.myProject.demo          I  Background young concurrent copying GC freed 55599(2336KB) AllocSpace objects, 152(23MB) LOS objects, 43% free, 30MB/54MB, paused 60us,49us total 152.404ms
15:39:47.945  9559-9569  e.myproj.dem          com.myProject.demo          I  Background concurrent copying GC freed 65083(2663KB) AllocSpace objects, 165(25MB) LOS objects, 42% free, 32MB/56MB, paused 66us,48us total 323.390ms
15:39:48.913  9559-9569  e.myproj.dem          com.myProject.demo          I  Background young concurrent copying GC freed 59233(2451KB) AllocSpace objects, 155(23MB) LOS objects, 43% free, 31MB/55MB, paused 65us,51us total 151.311ms

日志关键信息解析

这些是ART虚拟机的Concurrent Copying GC日志，分为新生代（young）和普通并发GC两类，每次回收两类核心对象：

AllocSpace对象：新生代中的小对象，每次回收5.5万-6.5万左右，占用2.3-2.7MB，属于短生命周期对象的常规回收
LOS（Large Object Space）对象：大对象空间的对象，数量152-169左右，占用23-26MB，这部分是GC频繁触发的核心关注点，大对象频繁创建回收会显著影响性能

定位回收对象的具体方法

1. 深挖Android Studio Memory Profiler

开启Allocation Tracking，记录GC前后的内存分配数据，对比筛选出被回收的对象类型
手动触发GC前后捕获Heap Dump，通过两次快照的对象差异对比，精准定位被回收的对象及其创建栈
开启Profiler的GC Event自动捕获，关联GC事件对应的内存变化

2. 启用详细GC日志输出

在应用启动的VM参数中添加以下配置，获取更细粒度的回收对象信息：

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

这些参数会输出回收对象的具体类型、所属内存区域、数量等细节，直接定位高频回收的对象类

3. 用LeakCanary排查高频创建对象

LeakCanary不仅能查内存泄漏，还能记录频繁创建和回收的短生命周期对象，通过它的对象创建栈信息，找到代码中频繁分配对象的位置

4. 专项排查LOS大对象

日志中LOS对象每次回收20+MB，说明存在频繁创建的大对象（比如Bitmap、大数组）：

在Profiler中筛选Large Objects，查看对象类型和创建栈
优化大对象复用（比如Bitmap复用池）、避免重复创建大对象，减少LOS的GC频率

内容的提问来源于stack exchange，提问作者Roy