Android性能优化：内存泄漏

作者: tianyl | 来源:发表于2018-12-26 22:20 被阅读0次

索引

Android中的内存泄漏引起的原因有很多，首先我们需要了解Java和Android中的引用和回收机制，然后我们需要了解常见的Android内存泄漏的多种情况，最后则是内存泄漏的排查工具的使用方法

1.虚拟机和引用

我们知道Android的apk是运行在Android系统中的，这里我们可以简单的把它当成运行在Android的虚拟机中，Android的虚拟机的演变是从Dalvik虚拟机到ART虚拟机的，而最初的Dalvik虚拟机，又是Google在Java 虚拟机上改进的，所有需要我们从Java虚拟机开始了解

1.1 Java虚拟机

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则依赖用户线程的启动和结束而建立和销毁。——《深入理解Java虚拟机》
从上一段话中，可以得知，虚拟机中有些内存是随着虚拟机进程存在的，而有些内存则是随着用户线程存在的

image.png
(图1：Java虚拟机运行时的内存图)

这是我从网上找的的一张Java虚拟机运行时的内存图（侵删）

1.1.1 程序计数器

程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。——《深入理解Java虚拟机》
由上一段话，可以得知程序计数器是一块线程私有的区域，由于Java的多线程是通过线程轮流切换抢占式的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只会执行一条线程中的指令，因为为了切换线程之后能够恢复到正确的执行位置，每条线程都有一个程序计数器，各线程的计数器互不影响，相互独立

注意：如果一个线程执行的是Java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址，如果正在执行的是native方法，这个计数器则为空（Undefined）。此区域是Java虚拟机规范中唯一一个没有OutOfMemoryError的区域

1.1.2 Java虚拟机栈

Java虚拟机栈也是线程私有的，它的生命周期和线程相同。Java虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同事都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用到执行完成的过程，就队友一个栈帧在虚拟机栈中入栈和出栈的过程

注意：在Java虚拟机规范中，对这个区域规定了两种异常，如果线程请求的栈深度大于虚拟机所允许的深度，就会抛出StackOverflowError异常。如果虚拟机可以动态扩展（大部分都可以），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

1.1.3 本地方法栈

本地方法栈和Java虚拟机栈基本一样，只不过Java虚拟机栈是为Java方法服务，而本地方法栈则为Native方法服务，也有StackOverflowError和OutOfMemoryError。

1.1.4 Java堆

Java堆是Java虚拟机所管理内存中的最大一块，Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的是存放对象实例，几乎所有的对象都在这里分配内存。

Java堆是垃圾回收器管理的主要区域，也被称为GC堆
注意：Java堆可以处于物理上不连续的空间中，只要逻辑上可连续即可。如果堆中没有内存完成实例分配，并且堆也没法再扩展时，将会抛出OutOfMemoryError异常。

1.1.5 方法区

方法区和Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。这个区域也有OutOfMemoryError异常

1.1.6 运行时常量池

运行时常量池也属于方法区的一部分

1.2 Java中的GC

Java虚拟机有许多种，其中用得比较多的一种算法叫做可达性算法，而Android中的GC和Java中又不太一样，Android中的GC是基于标记-清除(Mark-Sweep)算法的，所以对于此我们暂时只做了解即可，以后有机会再深入学习Dalvik虚拟机和ART虚拟机中Mark-Sweep算法的实现细节

1.3Java中的引用

Java中有4种引用：Strong reference(强), SoftReference(软), WeakReference(弱), PhatomReference(虚)

强引用：就是最普遍的引用，比如”Object obj = new Object()”这种引用，垃圾收集器不会回收强引用的对象。
软引用：在系统将要内存溢出之前，会将这些对象列入回收范围进行第二次回收，如果回收后还是内存不足会抛出内存溢出。
弱引用：被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器回收时，无论内存是否足够都会回收。
虚引用：也称为幽灵引用或者幻影引用，是最弱的引用关系。一个对象的虚引用根本不影响其生存时间，也不能通过虚引用获得一个对象实例。虚引用的唯一作用就是这个对象被GC时可以收到一条系统通知

2 几种常见的Android内存泄漏

2.1 静态对象

静态Context和静态View，如果一个上下文对象被静态引用，那么它就很可能会发生内存泄漏

2.2 内部类

因为内部类会隐式的持有外部类的引用，所以当对象应该被回收时，如果它有内部类正在执行，那么它很可能发送内存泄漏，比较常见的有Handler，Threads，TimerTask和匿名内部类

2.3 监听器

监听器在很多时候都是使用的强引用，如果在需要清除引用的时候没有清除，那么就可能发生内存泄漏，比如比较常用的EventBus如果没有在退出的时候解除注册，那么便会内存泄漏
整理如图

1e6be2f9531a3e1d5aa62c57c5c61e26.png
(图2：几种常见的内存泄漏)

3 Android内存泄漏的排查方法

出现问题不可怕，最重要的是要能解决问题，对于排查app发生的内存泄漏，首先我们需要获得通知，这里建议使用leakcanary这个框架，这个框架引入非常简单，不超过3行代码，这里就不做描述了，现在假设我们的app发生了内存泄漏，我们应该如何排查呢

3.1 获取内存数据

首先需要我们打开Android Studio中底部的Android Profiler窗口（在Android Studio3.0以上都有此窗口），如果没有则需要用View->Tool Windows->Profiler进行打开（此功能对Android系统的版本有要求，如果版本过低，还需要升级系统版本，或者使用早期的Android Studio中的DDMS，这里就不做引申了屏幕快照 2018-12-26 下午10.06.42.png
(图3：Android Profiler窗口的打开方式)
在手机上运行我们的客户端，然后点击Profiler窗口左边的"+"选中我们的设备中的应用(图4) 图4，选中设备和右边对应的应用
然后选中其中的memory栏

图5：选中memory栏

点击Profiler中左上角的那个垃圾桶图标进行GC，然后再点击垃圾桶旁边的那个图标将当前应用的内存dump下来 dump图标
稍作等候，便会出现当前系统中的内存数据图6：系统中的内存数据

到此，我们应用中的内存数据就已经获取到了

3.2 分析泄漏点

首先，选中左上角的Arrange by package，然后找到leakcanary中提醒我们发生内存泄漏的类，然后在package name的窗口中找到它，例如我们此时选中的MainActivity 找到发生内存泄漏的类

如果某个类发生了内存泄漏，只要我们不断的做发生内存泄漏时同样的操作，那么内存中它的实例很有可能就会超过1个，例如此时我们的MainActivity的Allocation数量是1，就说明他并没有泄漏。

如果MainActivity发生了内存泄漏应该是什么样的呢？所以现在我们要想办法让它内存泄漏

我们在MainActivity中加入这一一段代码

private Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            sendEmptyMessageDelayed(1,1000);
        }
    };

之前的几种常见内存泄漏的情况中，已经有了这种情况的说明，匿名内部类会持有外部类的引用，当我们Activity销毁时，如果这个匿名内部类还在运行，那么就会发生内存泄漏

我们运行app，果然，发生了内存泄漏

内存泄漏后

可以发现，内存中有4个MainActivity对象，很显然，正常情况下，MainActivity只会存在一个，那么其他3个就是系统无法回收的对象

3.3 找到泄漏对象被谁引用

此时我们点击Package Name中的MainActivity，那么AndroidStudio右方就会出现一个Instance View

Instance View
然后我们点击Instance View中的任意一个MainActivity，下方都会出现一个引用表，这张表说明了这个MainActivity现在被谁引用

引用图很显然，除了下方的一些成员对象之外，还有一个很明显的this$0，我们知道，这是匿名内部类，然后联想到我们刚才加的那个匿名内部类，bingo，原因找到了

当然，真正的开发过程中，内存泄漏的查找肯定不会这么简单，往往一个对象出现内存泄漏的原因，不是因为一个原因导致的，如果我们通过这个方法找不到泄漏的原因，那么还有一个工具MAT

3.4 MAT(Memory Analysis Tools)

MAT是一款eclipse的插件，用来分析内存的，当然，我们如果不想下载eclipse，也可以下载单独的版本，相关下载方式可以百度

下载完成后，我们首先将刚才生成的内存信息导出，将鼠标放在内存图蓝色的区域右键，选中Export 导出内存信息

这样，我们就可以得到一个后者名为hprof的文件
然后，我们将这个我们转成java的内存文件，通过Android SDK中的命令工具hprof-conv(工具在platform-tools文件夹下)
hprof-conv -z src dst,其中src是原文件名，dst是目标文件名，例如：
生成java内存信息这样，我们得到了java内存文件
将生成的文件用MAT打开，然后选中Leak Suspects Report 屏幕快照 2018-12-27 下午10.56.37.png
选中Overview下方的Histogram
然后用同样的方式找到我们发生内存泄漏的类MainActivity
然后选中发生内存泄漏的类MainActivity右键，选择List Objects->with outgoing references
随后会出现一个新的窗口，这个窗口展示了当前所以的没有回收的对象MainActivity，然后我们再次在随机个一个MAinActivity上右键，选中Merge Shorttest Paths to GC Roots->exclude all phantom/weak/soft etc. references
神奇的事情发生了，过滤个结果正是泄漏的原因

这张图表示，我们的主线程消息队列中，还存在着一个消息，它持有我们MainActivity的引用，这也正是我们之前加的泄漏代码