0.前言
Android Studio升级到3.0以后DDMS入口不见了，不要着急，取而代之的是Layout Inspector，File Explorer以及Profiler等新工具。很多人对新工具还不是很了解，Profiler是一个分析app性能的强大工具合辑，可以分析内存、cpu、启动时间、网络情况、功耗等各个指标，今天先来看看Profiler如何分析应用的内存情况吧。
1.打开Profiler
如何打开Profiler呢？点击菜单栏上的Run -> Profiler ‘app’可以开始分析app性能。不过我更喜欢用Ctrl+Shift+a，执行find action命令，搜索profiler，可以不用鼠标更快地打开Profiler。
app启动好后，profiler也会起来，主界面如下：
点击左上角红色的按钮可以停止分析，想要再次分析就点左边的+号开始新的会话。
可以看到主界面一直在跑的有四个性能指标，分别是CPU、MEMORY、NETWORK、ENERGY，今天我们是来看内存分析的，所以点击MEMORY看看。
2.进入Memory分析界面
可以看到，这里以四种颜色分别表示四种内存占用情况，其中我们比较关心的Native和Java堆内存在最下面，把鼠标放上去可以看到具体的数值。
点击左上的垃圾桶可以强制进行gc垃圾回收，在定位内存泄漏的时候很有用。
3.查看Java堆内存和具体Java实例
点击任意一个时间点可以看到当前的java堆内存情况，下面来做个实验，在当前Activity添加几个自定义对象Person并保存到一个成员变量集合中：
public class MainActivity extends AppCompatActivity {
List<Person> persons = new ArrayList<>();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
persons.add(new Person("zhangsan",23));
persons.add(new Person("lisi",24));
persons.add(new Person("wangwu",25));
}
private class Person {
String name;
int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}
}
按道理来说，被成员变量persons集合持有后，这三个实例肯定不会被回收，我们来看下是不是这样，点击启动后的任意一个时间点，下方会列出所有的java对象，然后我们点击右侧的搜索，搜索到Person
可以看到Person对象的totalsize是3,点击后右侧显示的正好是三个实例。现在我们明白了如何去查询某个时间点内存对象的数量了。
当然你的模拟器或测试机可能不支持这种随时点击任意时间点就能看到Java堆的feature（看官网写的好像是要8.0以上），没关系点击垃圾桶右边的Dump Java Heap按钮一样可以打印Java堆的情况。打印下来的文件可以在左侧另存为hprof文件，可以用MAT等内存分析工具进行分析。
4.内存泄漏分析
Android内存优化最常见的问题就是发现并解决内存泄漏了，其中又以Activity泄漏最为常见。下面我们来手写一个会发生泄漏的Activity（没用问题制造问题也要上- -），看看怎么用Profiler定位泄漏问题：
public void openLeakActivity(View view) {
startActivity(new Intent(this, LeakActivity.class));
}
创建一个新的LeakActivity，并在MainActivity添加一个启动LeakActivity的按钮。然后我们来给LeakActivity制造泄漏。
public class LeakActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_leak);
mHandler.sendEmptyMessageDelayed(0, 24 * 60 * 60);
}
}
Activity泄漏的经典案例：Handler持有造成的泄漏。handler持有Activity对象，让Handler延时发送消息这样Handler在消息发完之前就不会回收，Activity也跟着无法销毁。其实这段代码写出来就会被Android Studio疯狂diss，用大大的黄块告诉你Handler应当用static修饰，否则可能会发生泄漏。但是现在我们要的就是泄漏。打开应用，开启Profiler，不断反复打开、关闭LeakActivity，我这里打开关闭了六次，看下内存的波动情况：
我这里图没截好，不过也能看出来趋势了，每次打开LeakActivity内存都会上涨一点点。这里我忘记点force gc了，当然由于handler无法销毁，gc自然也是没用的。
现在我们可以确认LeakActivity存在泄漏了，那如何定位泄漏原因呢？我们先Dump一下Java堆，来查找一下LeakActivity：
果不其然，打开的六个LeakActivity一个也没有销毁，右侧点击任意一个LeakActivity，我们来看看引用情况。
很明显可以看到，前面的八个this$0引用都是值得那一个Handler匿名内部类，这样我们就轻松定位到了泄漏原因。原因找到了，再根据内存引用的知识去修改就容易了。这里我们只要根据提示把匿名内部类Handler改为静态内部类就可以，如过引用了成员变量无法用static修饰，就使用弱引用去获取对象。
好了，使用Profiler去分析内存是不是轻松加愉快呢？不要再怕定位内存泄漏啦！
