写在前面
英文原版链接,若是觉得本文哪里不好还请指出,以便及时修改,以下是译文
安卓是为移动设备设计的,所以开发者应该时刻留意app占用的RAM(Random-Access Memory)。尽管Dalvik和ART会例行垃圾回收(GC),但并不代表开发者可以忽略app的内存使用情况(什么时候在哪里分配/释放了多少内存)。为了确保稳定的用户体验,让系统能够在多个app之间迅速切换,app不要在用户没有和它交互时消耗不必要的内存,这一点很重要
P.S.Dalvik(Android专用的JVM)、ART(Android Runtime),Android4.4引入了ART,之前是Dalvik
即便在开发期间遵循所有的最佳实践来管理app的内存(开发者理应这样做),也可能会出现对象泄漏或者其它内存bug。唯一可靠的,能尽量减少app内存占用的方法就是用工具分析app的内存使用情况,本篇指南将详细说明应该怎么做
Log信息解释
查看app内存使用情况最简单的方式是运行时的log信息,GC执行后,会输出一段信息到logcat。logcat的输出可以在Device Monitor里查看,或者直接在IDE比如Android Studio里查看
Dalvik Log信息
在Dalvik(不是ART)模式下,每次FC会在logcat输出如下信息:
D/dalvikvm: , , ,
例如:
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
GC Reason
什么触发了GC,以及属于哪种类型的垃圾回收,可能出现的值包括:
GC_CONCURRENT
heap快满了引起的并发GC
GC_FOR_MALLOC
heap已经满了,此时app尝试分配内存,所以系统只好阻止app并回收内存,导致内存分配失败
GC_HPROF_DUMP_HEAP
请求创建一个用来分析heap的HPROF文件,引发GC
P.S.hprof文件描述了heap使用情况,类似于Chrome的heapsnapshot文件
GC_EXPLICIT
显式GC,例如调用gc()(这种方式应该避免,要相信GC会在需要的时候自动执行)
GC_EXTERNAL_ALLOC
外部内存分配(比如像素数据存储在native memory里或者NIO byte buffer)引起的GC,只会在API 10和更低版本中出现(新一点的版本所有东西都在Dalvik heap里分配)
Amount freed
本次GC回收的内存大小
Heap stats
heap中可用内存所占百分比,以及[已使用内存大小]/[heap总大小]
External memory stats
外部内存统计数据,
在API 10和更低版本中,外部分配的内存,以及[已分配内存大小]/[GC下限]
P.S.达到GC下限时进行GC
Pause time
heap越大,需要的停顿次数越多,并发GC(GC Reason为GC_CONCURRENT)的停顿次数分2部分:第一部分是GC开始时,另一部分是GC结束时
记下这些log信息,关注heap stats(例子中是3571K/9991K),如果持续增长,可能就存在内存泄漏了
ART Log信息
与Dalvik不同,ART不会log非显式(隐式)请求的GC,GC只会在被判定为很慢时输出信息。更准确地,条件是GC停顿超过5ms,或者GC耗时超过100ms。如果app不是处于一种可察觉的停顿状态,那么GC不会就被判定为很慢,而显式GC会被log出来
ART的GC log中包含了以下信息:
I/art: () AllocSpace Objects, () LOS objects,
例如:
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 Reason
什么触发了GC,以及属于哪种类型的垃圾回收,可能出现的值包括:
Concurrent
并发GC,不会挂起app线程,这种GC在后台线程中运行,不会阻止内存分配
Alloc
GC被初始化,app在heap已满的时候请求分配内存,此时,GC会在当前线程(请求分配内存的线程)执行
Explicit
GC被app显式请求,例如,通过调用System.gc()或者runtime.gc()。和Dalvik一样,ART建议相信GC,尽可能地避免请求显式GC。不建议使用显式GC,因为会阻塞当前线程,并引起不必要的CPU周期。如果GC导致其它线程被抢占的话,显式GC还会引发jank
P.S.jank是指第n帧绘制过后,本该绘制第n+1帧,但因为CPU被抢占,数据没有准备好,只好再显示一次第n帧,下一次绘制时显示第n+1帧
NativeAlloc
来自native分配的native memory压力引起的GC,比如Bitmap或者RenderScript对象
CollectorTransition
heap变迁引起的GC,运行时动态切换GC造成的,垃圾回收器变迁过程包括从free-list backed space复制所有对象到bump pointer space(反之亦然)。当前垃圾回收器过渡只会在低RAM设备的app改变运行状态时发生,比如从可察觉的停顿态到非可察觉的停顿态(反之亦然)
HomogeneousSpaceCompact
Homogeneous space compaction是free-list space与free-list space的合并,经常在app变成不可察觉的停顿态时发生,这样做的主要原因是减少RAM占用并整理heap碎片
DisableMovingGc
不是一个真正的GC原因,正在整理碎片的GC被GetPrimitiveArrayCritical阻塞,一般来说,因为GetPrimitiveArrayCritical会限制垃圾回收器过渡,强烈建议不要使用
HeapTrim
不是一个真正的GC原因,但GC被阻塞,直到heap trim结束
GC Name
ART有几种不同的GC
Concurrent mark sweep (CMS)
全堆垃圾收集器,负责收集释放除image外的所有空间
Concurrent partial mark sweep
差不多是全堆垃圾收集器,负责收集除image和zygote外的所有空间
Concurrent sticky mark sweep
分代垃圾收集器,只负责释放从上次GC到现在分配的对象,该GC比全堆和部分标记清除(mark sweep)执行得更频繁,因为它更快而且停顿更短
Marksweep + semispace
非并发的,复制堆过渡和homogeneous space compaction(用来整理heap碎片)使用的GC
Objects freed
本次GC从非大对象空间(non large object space)回收的对象数目
Size freed
本次GC从非大对象空间回收的字节数
Large objects freed
本次GC从大对象空间里回收的对象数目
Large object size freed
本次GC从大对象空间里回收的字节数
Heap stats
可用空间所占的百分比和[已使用内存大小]/[heap总大小]
Pause times
一般情况下,GC运行时,停顿次数和被修改的对象引用数成比例。目前,ART CMS GC只会在GC结束的时停顿一次,GC过渡会有一个长停顿,是GC时耗的主要因素
如果在logcat看到一堆GC信息,找到heap stats(例子中是25MB/38MB),如果持续增长从不减小,就可能存在内存泄漏。如果看到GC的原因是Alloc,那么说明heap已经要满了,快OOM了