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进行内存检测的一个例子 ：

1. class Cat {
   
2. }
   
3. class Box {
   
4.   Cat hiddenCat;
   
5. }
   
6. class Docker {
   
7.   static Box container;
   
8. }
   
9. 
   
10. // ...
    
11. Box box = new Box();
    
12. Cat schrodingerCat = new Cat();
    
13. box.hiddenCat = schrodingerCat;
    
14. Docker.container = box;
    

复制代码

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

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

复制代码

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

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

复制代码

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

1. public class ExampleApplication extends Application {
   
2.   @Override public void onCreate() {
   
3.     super.onCreate();
   
4.     LeakCanary.install(this);
   
5.   }
   
6. }
   

复制代码

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

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

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

2.乱码问题：

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

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

插桩完成之后发现MM

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