Android性能优化第（二）篇---Memory Monitor检测内存泄露

多练习多写代码.jpg

上篇说了一些性能优化的理论部分，主要是回顾一下，有了理论，小平同志又讲了，实践是检验真理的唯一标准，对于内存泄露的问题，现在通过Android Studio自带工具Memory Monitor 检测出来。性能优化的重要性不需要在强调，但是要强调一下，我并不是一个老司机，嘿嘿！没用过这个工具的，请睁大眼睛。如果你用过，那么就不用在看这篇博客了。

先看一段会发生内存泄露的代码

public class UserManger {

    private static UserManger instance;

    private Context context;

    private UserManger(Context context) {
        this.context = context;
    }

    public static UserManger getInstance(Context context) {
        if (instance == null) {
            instance = new UserManger(context);
        }
        return instance;
    }
}


public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        UserManger userManger = UserManger.getInstance(this);
    }
}

代码很简单，就是一个单利模式泄露的场景，我们现在的关心的不是代码本身，而是如何将代码里面的内存泄露给找出来。但是对于上面的代码发生内存泄露的原因还是有必要提一下。

上篇博客说了，内存泄漏产生的原因是：当一个对象已经不需要再使用了，本该被回收时，而有另外一个正在使用的对象持有它的引用从而就导致，对象不能被回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中，就产生了内存泄漏。

在上面的代码中，发生泄露的不是UserManger,而是MainActivity，UserManger中有一个静态成员instance，其生命周期和应用程序的生命周期一致，当退出应用时，才能被销毁，但是当GC准备回收MainActivity时,结果呢MainActivity的对象（this）在被UserManger所引用，UserManger本身又不能被干掉，所以就发生了内存泄露。

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第2张图片

monitors.png

Memory Monitor是Android Monitors中的一种，Monitors主要包括四种，Memory Monitor ,CPU Monitor ,NetWork Monitor, GPU Monitor ,今天介绍的是Memory Monitor ，其他的Monitor，在后面也准备讲。

Memory Monitor界面

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第3张图片

Memory Monitor.png

图中水平方向是时间轴，竖直方向是内存的分配情况
图中深蓝色的区域，表示当前正在使用中的内存总量，浅蓝色或者浅灰色区域，表示空闲内存或者叫作未分配内存。
左上角工具栏三个圆圈按钮依次代表
GC按钮，可以手动GC，回收程序垃圾
内存快照（Dump Java Heap），点击可以生成一个文件（包名+日期+“.hprof”），可以记录摸一个时间点内，程序内存的情况
Allocation Traking ，点击一次开始, 再次点击结束,也可以可以生成一个文件。

回到我们的程序，多点击几次GC，看一下这个应用的内存使用情况。

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第4张图片

内存使用情况.jpg

可以看到现在已经分配的内存有19.68M，我把手机旋转一下，在看。

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第5张图片

旋转后内存使用情况.png

可以看到现在的内存使用量是21.09M,还是一样的界面，却多了1.41M!!!这很关键。

接下来，我们找一下，哪里发生了泄露。点击Dump Java Heap，生成快照文件tool.test.memory.memoryleak_2016.11.13_21.38.hprof,Android Studio 自动弹出HPROF Viewer来分析它。

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第6张图片

快照文件分析.png

现在介绍一下HPROF Viewer的用法

HPROF Viewer查看方式
左上角两个红框，是可选列表, 分别是用来选择Heap区域, 和Class View的展示方式的.
Heap类型分为:
App Heap -- 当前App使用的Heap
Image Heap -- 磁盘上当前App的内存映射拷贝
Zygote Heap -- Zygote进程Heap(每个App进程都是从Zygote孵化出来的, 这部分基本是framework中的通用的类的Heap)
Class List View -- 类列表方式
Package Tree View -- 根据包结构的树状显示

我通常点击App heap下面的Classs Name把Heap中所有类按照字母顺序排序，然后按照字母顺序查找。

HPROF Viewer主要分ABC三大板块
板块A：这个应用中所有类的名字
版块B：左边类的所有实例
板块C：在选择B中的实例后，这个实例的引用树

A板块左上角列名解释

列名	解释
Class Name	类名，Heap中的所有Class
Total Count	内存中该类这个对象总共的数量，有的在栈中，有的在堆中
Heap Count	堆内存中这个类对象的个数
Sizeof	每个该实例占用的内存大小
Shallow Size	所有该类的实例占用的内存大小
Retained Size	所有该类对象被释放掉，会释放多少内存

B板块右上角上角列名解释

列名	解释
Instance	该类的实例
Depth	深度, 从任一GC Root点到该实例的最短跳数
Dominating Size	该实例可支配的内存大小

B板块右上角有个"的按钮, 点击会进入HPROF Analyzer的hprof的分析界面:

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第7张图片

Analyzer Tasks.png

"
在这个界面中可以直接把内存泄露可能的类找出来。

下面分析一下MainActivity的泄露情况

Android性能优化第（二）篇---Memory Monitor检测内存泄露_第8张图片

MainActivity发生内存泄露.png

一个Activity应该只有一个实例，但是从A区域来看 total count的值为2，heap count的值也为2，说明有一个是多余的。
在B区域中可以看见两个MainActivity的实例，点击一个看他的引用树情况
在C区域中可以看到MainActivity的实例Context被UserManger的 instance引用了，引用深度为1.
在Analyzer Tasks 区域中，直接告诉你Leaked Activities，MainActivity包含其中

多方面的证据表明MainActivity发生了内存泄露

解决方案

public class UserManger {

    private static UserManger instance;

    private Context context;

    private UserManger(Context context) {
        this.context = context;
    }

    public static UserManger getInstance(Context context) {
        if (instance == null) {
            if(context!=null){
                instance = new UserManger(context.getApplicationContext());
            }
        }
        return instance;
    }
}

不要用Activity的Context,因为Activity随时可能被回收，我们用Application的Context,Application的Context的生命周期是整个应用，不回收也没有关系。

Memory Monitor获得内存的动态视图，Heap Viewer显示堆内存中存储了什么，可惜Heap Viewer不能显示你的数据具体分配在代码的何处，如果还不过瘾，想知道具体是哪些代码使用了内存，还有一个功能是Allocation Tracker,用来内存分配追踪。在内存图中点击途中标红的部分，启动追踪，再次点击就是停止追踪，随后自动生成一个alloc结尾的文件，这个文件就记录了这次追踪到的所有数据，然后会在右上角打开一个数据面板
Allocation Tracker启动追踪