本文转自：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~~