本文转自:https://www.testwo.com/article/1153
1、前言
Hello,小伙伴们,相信大家在项目测试中都遇到过内存泄露问题,小编也着实爬过很多坑。比如小编所测项目,更换了多实例版本的sdk,横竖屏切换后有MapView没有销毁,导致内存泄露。小编测试手表项目,因为手表内存有限,测试中常遇到应用无响应或者闪退,故而小编对GC机制进行了进一步学习了解。
本文先对Android内存垃圾回收机制进行介绍,之后对分析、定位内存泄露常用的测试方法进行总结,分享给大家。
2、Android内存垃圾回收(GC机制)
2.1综述
Android 应用中默认有三个线程:“main”主线程、GC线程、和Heap线程,而且在GC线程运行的过程中,主线程会中断执行。Java程序与C/C++等原生程序的一个不同点就是,Java虚拟机在运行Java程序的过程中,可以自动回收不再使用的对象实例,从而避免了程序员人工管理内存的繁琐工作。如果设备是单核CPU设备,一次只能运行一个线程,因此在GC线程运行的时候,必须中断主线程。但是如果设备上有多核CPU,即主线程可以和GC线程同时运行,在这种情况下执行GC,会不会中断主线程呢?答案是会的。
虽然有不同的内存垃圾回收实现算法,但有些算法需要中断其他Java线程的执行,如果中断的时间过长,给用户的感觉就是应用的响应速度变的越来越慢,甚至有可能出现ANR错误。
2.2Android内存管理原理
2.2.1垃圾内存回收算法
常见的垃圾回收算法引用计数法、标注并清理、拷贝、逐代回收,其中android系统采用的是标注并清理和拷贝GC,并不是大多数JVM实现中采用的逐代回收算法。在很多垃圾回收实现中,常常可以看到将几种算法合并使用的场景。
2.2.2Logcat中的GC信息
Logcat中GC输出的信息格式如下:
Dalvik虚拟机的Log信息
在Davlik虚拟机(非ART)中,每一次垃圾回收都会返回一条类似的信息。例子如下:
D/dalvikvm( 9050): GC_CONCURRENT freed2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
它们大致可以分成如下几个部分:
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
[GC的原因][回收的内存总量][GC堆内存的统计信息][外部内存的统计信息][中断时间]
各个字段的含义如下:
(1)、GC的原因,也就是GC类别,可分为:
- GC_FOR_MALLOC 表示内存垃圾回收过程是因为在分配内存空间如(创建对象)时,内存不够而引发的。系统会杀死应用的进程并且回收所有内存。
- GC_CONCURRENT 表明GC是在内存使用率达到一定的警戒线时,自动触发的。
- GC_EXPLICIT 表明GC是被显式请求触发的。
- GC_EXTERNAL_ALLOC在API版本10(Android3.0)以下的时候的垃圾回收机制。3.0以上版本所有的内存都在Dalvik堆中分配。它是用来回收dalvik虚拟机以外的内存(例如Bitmap中的内存或者NIObuffer中的内存)。
- GC_HPROF_DUMP_HEAP 当请求生成HPROF文件来分析内存的时候会触发此类垃圾回收
(2)、回收的内存总量
(3)、回收后GC内存对的统计信息
堆中可用空间所占的百分比和(堆中对象的数量)/(堆的大小)
(4)、外部内存的统计信息
系统API版本10以下的系统中,Dalvik虚拟机堆外(分配的内存)/(限制的内存量)
(5)、GC造成的应用其他线程中断的时间
Concurrent类型的垃圾回收有两次暂停时间:一次发生在开始,另一次发生在结束。堆的内容越多,暂停的时间越长。
观察这些Log信息,如果heapstats中的数值(堆中对象数量)/(堆的大小)越来越大,那么应用中很有可能存在内存泄漏。
(6)、总结
一般根据下面两个线索判断应用是否存在内存泄露问题
1、应用运行一段时间后,因为内部抛出java.lang.OutOfMemoryError异常而崩溃;
2、在logcat中看到频繁的GC信息;
3、内存泄露
3.1什么是内存泄漏
对于不同的语言平台来说,进行标记回收内存的算法是不一样的,像Android(Java)则采用GC-Root的标记回收算法。下图(Google 2011的IO大会)展示了Android内存的回收管理策略。
图中的每个圆节点代表对象的内存资源,箭头代表可达路径。当圆节点与GC Roots存在可达路径时,表示当前资源正被引用,虚拟机是无法对其进行回收的(如图中的黄色节点)。反过来,如果圆节点与GC Roots不存在可达路径,则意味着这块对象的内存资源不再被程序引用,系统虚拟机可以在GC过程中将其回收掉。
有了上面的内存回收的栗子,那么接下来就可以说说什么是内存泄漏了。
从定义上讲,Android(Java)平台的内存泄漏是指没有用的对象资源任与GC-Root保持可达路径,导致系统无法进行回收。举一个最简单的栗子,我们在Activity的onCreate函数中注册一个广播接收者,但是在onDestory函数中并没有执行反注册,当Activity被finish掉时,Activity对象已经走完了自身的生命周期,应该被资源回收释放掉,但由于没有反注册,此时Activity和GC-Root间仍然有可达路径存在,导致Activity虽然被销毁,但是所占用的内存资源却无法被回收掉。
3.2泄漏的源头
这里,将其归位以下三类:
(1). 自身编码引起
由项目开发人员自身的编码造成。
(2). 第三方代码引起
这里的第三方代码包含两类:第三方非开源的SDK和开源的第三方框架。
(3). 系统原因
由Android系统自身造成的泄漏,如像WebView、InputMethodManager等引起的问题,还有某些第三方ROM存在的问题。
3.3泄漏的定位
内存泄漏不像闪退的BUG,排查起来相对要比较困难些,比较极端的情况是当应用OOM了才发现存在内存泄漏问题,对用户影响太大。为此,我们希望在测试过程中能够尽早发现问题。下面介绍几种分析内存泄露问题的工具、方法。
3.3.1静态代码分析工具 —— Lint
Lint是 Android Studio自带的工具,使用姿势很简单Analyze -> Inspect Code然后选择想要扫面的区域即可。
对可能引起泄漏的编码,Lint都会进行温馨提示。
关于Lint,大家可以自行拓展学习。
3.3.2Android Memory Monitor
Android Studio提供的工具,用于监控应用的内存使用状态,在开发中也是非常实用的工具,可以用来打印出内存的状态信息。
打印获得的内存信息如下,可以通过右上角的绿色三角形按钮去分析泄漏的Activity和一些重复的字符串,目前只支持这两个,希望Google后面能够加入更多可选分析规则。
3.3.3adb shell 命令
使用 adb shell dumpsys meminfo [PackageName],可以打印出指定包名的应用内存信息。
使用该命令可以很直观的观察到Activity的泄漏问题,是平常分析比较常用的一种方式。除了使用命令外,Android Studio也提供了下面的功能,和使用命令是一样效果的。
以上就是我在做内存泄漏定位分析的时候会用到的工具和方法,通常都是结合起来用,使用多个工具互补分析问题可以提高我们的效率和最终取得的效果。
以上,就是小编做内存泄漏分析的一些心得总结,如有错误和不足,还请大家指出。如果大家针对内存泄露测试、分析,还有什么建议或者心得,欢迎留言、一起探讨~~O(∩_∩)O~~
原文地址:https://www.cnblogs.com/botoo/p/8182133.html