关于内存分析和优化，是我们app从开始到结束上线一直都要关注的问题。但是我发现我接触过得项目和公司，都是在APP成型之后，或者快上线了，才会去关注app内存使用情况。派专人去分析每个页面，每个动作是否会触发内存泄漏，ui卡顿等问题。个人认为这是个非常不好的习惯，内存分析优化，UI卡顿等应该是我们每个程序员编码的时候就刻意的去注意的问题。我们每完成一个需求，或者没添加一个逻辑，都要去想到这行代码会不会影响内存泄漏，ui卡顿。比如单例我们传的context，是activity的还是application的。我们的handler使用完是否需要在ondestory()里removeallcallBACK()。开启的线程什么时候回销毁。使用的Rxjava开启的流，最后都要调用dispose()等等。都是我们在编码的时候要注意的具体可以看一个我收藏的文章(点击)。不然很容易造成泄漏。
最近再做的一个华为音乐的项目，需要盘查内存泄漏和使用的情况。结合实际情况一步步分析优化的记录和总结。
今天我们使用的是Android studio 和 MAT来分析优化内存，具体怎么使用我们先来看看Androidstudio 和 MAT各自起到什么作用。
首先我们来介绍一下Android studio能帮我们做什么？
AS大家都比较熟悉了，但是AS不同的版本可能会有一点差异，比如我在公司使用的都是3.1版本的AS，我自己电脑上装的是2.3的。AS3.0以上版本和之前的有很大差别，具体大家可以去搜搜看。。但是今天我们还是用2.3的来分析。当然在3.0上也是通用的，只是按钮的位置，形状可能会有些差别。
首先写了一个泄漏的例子，来帮助我们分析。
1.比如我们有两个Activity，A和B。打开项目从activityA跳转到activityB等一系列的可能还有内存泄漏的操作，再回到activityA。这时候我们手动GC如图：
多GC几次，等到我们的memory稳定了，之后点击我们的dump按钮，生成.hprof文件，自动打开。之后我们也可以在左上角简单的看看一下具体的实例，内存占用等。但是太多不容易分析。
2.这时候我们得到的.hprof文件是不标准的，我们要转换成标准的给我们的MAT使用。看图：
生成标准的hprof文件之后，我们的as的工作就可以停止了。
（命令行方式生成标准的hprof文件，
1.在as的sdk-》platform-tools-》打开CMD窗口，
2.输入hprof-conv 原来.hprof 目标.hprof，
3.在sdk下面生成目标.hprof文件是标准的）
接下来就是我们的MAT了。
MAT的起到什么作用？
我们得到标准的hprof文件之后，我们就可以拿着我们的hprof文件去分析了。
首先我们要有MAT工具，下载地址：http://eclipse.org/mat/downloads.php
MAT工具全称为Memory Analyzer Tool，一款详细分析Java堆内存的工具，该工具非常强大，为了使用该工具，我们需要hprof文件。但是该文件不能直接被MAT使用，需要进行一步转化，可以使用hprof-conv命令来转化，但是Android Studio可以直接转化,转化方法如下：
打开MAT工具，File->Open File选择我们刚才生成的test.hprof文件 。如图：
我们之关系我们使用的功能，具体其他功能请找传送门。。
我们比较关系的功能Histogram是这个，点击进去。可以输入我们要搜索的activity，因为泄漏最终导致的问题就是我们的activity关闭了，但是内存不能够回收我们不用的activity。就是我们的activity实例被占用了，具体被谁占用了。接下来。。。
选中我们应该被销毁却没有销毁的activity实例，右键-》listobject-》with incoming references
然后对引用的对象进行软引用，虚引用，软引用过滤，我们之关系的是强引用。所以有上图。就会列出引用我们activity的类，这时候我们可以查找我们自己使用的类，，看看具体的类是不是有问题。
-------------------------------------------------------------------------------------------番外篇-------------------------------
基于上面的分析我们再来一个比较直观的能看到我们app有多少activity和 view是没有被销毁的。没有被GC回收的。。
具体操作：app一顿操作之后，按返回键，退到桌面，之后不用杀死进程，这时候我们手动GC，多GC几次，，直到内存稳定。。然后按图操作：
如图打开我们的内存使用功能，这个在AS3.0以上我真的没找到，找了半天，找不到，不知被gogle放哪去了。。。。有知道的小伙伴可以留言告诉我一下，哈哈。
然后下图：看到view的数量，和activity的数量，如果activity不为0，说明你的activity有泄漏。具体你就可以按照我们上面的方式去分析。
但是但是，，，，我找不到as 3.0 上这个功能的位置，，欲哭无泪咋办呢。。。。不用怕我们有伟大的命令行。
操作流程都是一样的，然后打开我们的CMD命令，
输入：adb shell dumpsys meminfo -d xxxapp包名。回车完事。
跟我们上图一样activity和view的数量都出来了
所以我们就讲到这里，下一篇给大家介绍一下leakcanary处理内存泄漏，，基本上这两种处理内存泄漏的方法就能满足我们的项目需求了。。。
推荐：
