LeakCanary接入MM项目中遇到的问题总结

“A small leak will sink a great ship.” - Benjamin Franklin

千里之堤， 毁于蚁穴。 -- 《韩非子·喻老》

LeakCanary是一款强大而易用的内存检测工具，感谢Mars组这周在跟进将内存泄露检测工具LeakCanary接入MM项目的事情，期间遇到了一些问题。以下是一些学习和总结相关：

1、内存泄露

        Java中的每个对象都有着有限的生命周期。当这些对象所要做的事情完成了，我们希望他们会被回收掉。但是如果还存在（一个或者多个）对这个对象的引用，那么当这个对象生命周期结束后，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。比如，当 Activity.onDestroy 被调用之后，activity 以及它涉及到的 view 和相关的 bitmap 都应该被回收。但是，如果有一个后台线程持有这个 activity 的引用，activity 对应的内存就不能被回收。这最终将会导致内存耗尽，然后会出现OutOfMemoryError错误 而 crash。

使用LeakCanary进行内存检测的一个例子 ：

class Cat {
}
class Box {
  Cat hiddenCat;
}
class Docker {
  static Box container;
}

// ...
Box box = new Box();
Cat schrodingerCat = new Cat();
box.hiddenCat = schrodingerCat;
Docker.container = box;

然后新建一个refwatcher实例，让它来检测schrodingerCat 对象是否存在内存泄露：

// We expect schrodingerCat to be gone soon (or not), let's watch it.
refWatcher.watch(schrodingerCat);

当内存泄露问题被检测到时，LeakCanary会给出一份很详细的leak track报告。

* GC ROOT static Docker.container
* references Box.hiddenCat
* leaks Cat instance

而要将LeakCanary添加到项目中进行监测的方法也很便捷：在项目中的Application的onCreate()方法中添加一行代码就可以了。然后LeakCanary就会自动侦测到activity的内存泄露情况了。

public class ExampleApplication extends Application {
  @Override public void onCreate() {
    super.onCreate();
    LeakCanary.install(this);
  }
}

玲泉MM给出了LeakCanary接入项目中的详细文档，而佑荣GG提供了自动化插桩工具，这使得接入工作能够很方便的进行。然后，本小白在工具引入还是遇到了一些问题，感谢两位大牛的悉心指导，也把问题在这里总结下：

1.配置cfg文件时遇到的问题：

由于应用的启动Activity和MainActivity会在插桩代码运行之前就启动，如果对LauncherActivity和MainActivity进行插桩的话就会导致程序出错。需要在配置文件中将不需要进行插桩的Actiivty列举出来。

2.乱码问题：

开始使用记事本工具打开cfg配置文件，出现以下问题。使用submite工具打开，OK。

2.由一个逗号引发的问题：

插桩完成之后发现MM

3.编译过程中路径引用问题：