Profiler分析内存抖动，Memory Analyzer（mat）分析内存泄漏（不懂砍我）

前言： 最近在系统性的温习了一遍android性能优化。写博客是学习也是记录，希望在记录的同时也能帮助其他同学。最近我觉得我想出一个不懂系列。“不懂揍我”，“不懂砍我”，“不懂捶我”

一、Profiler分析内存抖动

在我们开发项目中，如果稍不注意，往往会出现内存抖动的情况。而有些内存抖动也可能造成我们的程序卡顿，甚至泄漏。接下来使用Android Studio自带的Profiler分析内存抖动。

1.1、模拟内存抖动并打开Profiler

首先在MainActivity创建一段内存抖动的代码：

private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            //创造内存抖动
            for (int i = 0; i < 100; i++) {
                String arg[] = new String[100000];
            }
            mHandler.sendEmptyMessageDelayed(0, 30);
        }
    };

然后点击下图红色框内按钮运行程序

运行之后出现如下图，

鼠标移动到MEMORY上双击，进入内存分析

如果你的项目已经运行，也可以通过View --> Tool Windows --> Profiler打开

1.2、分析内存抖动

点击按钮，触发内存抖动的代码，来看看我们的内存情况，可以看到呈锯齿状

点击上图红色框内record,然后点击stop分析一段我们的锯齿状，如图：

Allocations： 表示当前分配的数量
Shallow Size： 表示当前内存占用情况

可以看到我们的String[]占用最多，左键点击String[]后，右侧会出现所有的String[]，然后左键点击任意一个，会出现Allocation Call Stack：内存分配的堆栈信息：

可以很明显看到在我们代码里，是因为handleMessage:21, MainActivity$1 (com.leo.memoryanalyzertest)，造成的内存抖动。右键这条，点击Jump to Source.可以跳转到我们的问题代码。这就是我们Profiler分析内存抖动的情况。

1.3、如果用上篇的traceView方式，即CPU Profiler方式

首先我们推测下，traceView是分析卡顿利器，当然在这里能测出。但要知道它是偏向耗时情况的。上篇说过，这里就不说明了。同样点击CPU，然后record，stop记录一段。如图来到我们的Top Down：

可以看到耗时时间在MessageQueue里，这也正和我们的内存抖动代码相关联，每间隔30ms发送一次，在handleMessage()里，也指明了代码在com.leo.memoryanalyzertest.MainActivity里。可以发现这种方式去分析，并不明显。

注意：我们都知道内存抖动，我们要寻找的话，也是找循环或者频繁调用的地方。所以这么看我们用CPU Profiler的方式也能大概确认问题代码的位置。

二、Memory Analyzer之分析内存泄漏

同样我们先创建一段内存泄漏的代码，先定义个接口

public interface CallBack {
    void leoFun();
}

然后创建个静态list，添加CallBack实例

public class CallBackManager {
    public static ArrayList<CallBack> sCallBacks = new ArrayList<>();

    public static void addCallBack(CallBack callBack) {
        sCallBacks.add(callBack);
    }

    public static void removeCallBack(Callback callback) {
        sCallBacks.remove(callback);
    }
}

再创建个BitmapActivity实现CallBack接口，设置一个大图main_bg,同时把实例假如到静态sCallBacks中，这样每次打开BitmapActivity然后退出，都会造成BitmapActivity不能被回收。

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_bitmap);

        ImageView imageView = findViewById(R.id.image);
        Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.mipmap.main_bg);
        imageView.setImageBitmap(bitmap);
        CallBackManager.addCallBack(this);
    }

这样我们不停打开这个页面然后关掉看内存情况，如图，可以看到内存直接上升：

红色框1：功能是主动发起一次gc。目的是回收一些可回收的，虚引用等。避免内存分析干扰
红色框2: 堆转储，将内存分配情况转换成hprof文件。（注意这里是studio的hprof文件，如果需要用Memory Analyzer分析，还要转换成标准的hprof文件）

点击右键Export，将文件存储在文件夹里。

转换成mat能识别的hprof文件，只要cmd命令行来到我们的studio自带的hprof-conv.exe文件下，输入命令，即可转换

hprof-conv 源文件路径输出文件路径，这样就生成了我们的my.hprof

2.1、怎么使用我们的Memory Analyzer

生成了hprof文件后，然后就是使用Memory Analyzer。官网下载地址：www.eclipse.org/mat/downloa…，因为捐赠什么的，不建议。我这找到了一个比较靠谱的版本，csdn下载

下载好后启动我们的MemoryAnalyzer.exe。File --> Open Heap Dump打开我们的my.hprof文件如图：

先简单介绍下Memory Analyzer的信息。

2.1.1、红色框1： OverView大概信息

Size 内存大小
Classes : class对象
Objects : Objects个数，也就是实例个数
Unreachable Objects Histogram ：可被回收的对象，扔在内存当中

2.1.2、红色框2： Histogram直方图

Objects: 这个类有多少个实例
Shallow Heap: 单个实例占用的内存
Retained Heap: 单个实例及其引用一共占有多少内存

我们可以利用直方图，里的Regex搜索我们最开始的内存泄漏案例。搜索BitmapActivity如图，可以看到我们的BitmapActivity有3个实例：

我们可以右键点击com.leo.me,oryanalyzertest.BitmapActivity --> List objects --> with incoming reference (谁引用了我)，如图可以看到有3个地方引用了BitmapActivity：

此时我们右键一个实例点击 Path To GC Roots --> with all refrence,如图，找到文件下带小太阳的文件，可能触发内存溢出的地方。这里是说我们的sCallBacks引用了，也证实了在我们内存泄漏代码里的CallBackManager里的静态集合sCallBacks添加了它。