前言部分
这次泄漏是自己代码写的太随意引起的，讲道理，代码写的太为所欲为了，导致有些问题根本就很难发现。
泄漏产生的原因，由于activity未被回收导致。这里给我们提出的一个警示，在使用上下文的时候，我们要特别注意，尤其是一些实例的上下文，如：activity、fragment等。
这次的错误原因就是我把activity作为上下文传给了Glide使用，结果后期我做夜间模式，需要重启activity让夜间模式生效的时候忘记Glide还在持有activity的引用导致了泄漏。
内容部分
产生了泄漏的时候我们需要一些分析工具，leakcanary算是一个必备工具了。我们通过leakcanary可以收集到app产生的泄漏信息，然后通过信息可以找到具体的类，定位到泄漏的类中，在顺着引用连接就可以找到了。下面看一个泄漏的图：
上图中可以看出一些重要信息：
MainActivity的实例发生了泄漏，这表明我们的MainActivity在实例销毁的时候由于被Glide引用，并没有被回收。
导致这个结果的原因就是下面这段代码：
Glide.with(this@MainActivity)
.load(R.drawable.head_photo)
.apply(RequestOptions.bitmapTransform(CircleCrop()))
.into(ivPersonPhoto!!)
1
2
3
4
这里传入Glide中的上下文我没有使用applicationContext，结果在启用夜间模式的时候进行重启activity的时候出现了泄漏。
一些简单的泄漏通过leakcanary帮助我们收集的信息是可以处理的。但是如果有很多地方都引用一个实例的话，我们就需要使用一下分析工具了。
下面我们来看一下如何通过studio查看泄漏的步骤
我们先通过操作产生泄漏，这个时候我们的内存已经出现了泄漏。
然后点击Profile如图：
下面我们手动触发GC来回收无用的内存。如图：
然后内存不在减少后我们点击一下小垃圾桶旁边的箭头。就可以获取到内存的情况了。
我们点击MainActivity这个类，在右侧我们发现有两个对象在内存中。
点击后发现MainActivity被GlideRequests引用。如图
上面基本定位完成，这里我们在去找Glide引用MainActivity的地方就可以了。
上面讲的其实不太实用，因为实在通过leakcanary中确定MainActivity发生了泄漏，然后去直接去找的MainActivity，并且找到了Glide引用了MainActivity的实例才能顺利解决。
实际场景中还有很多复杂的内容，比如我的MainActivity可能被很多地方引用，找起来还是很麻烦的。所以这篇文章也只是最简单的应用。就像以前我写的查找应用超时的问题一样，基本也是找到trace文件，在里面找到自己项目相关的代码，在进行定位（猜测）。
结语部分
很多人都会问怎么进行内存泄漏的排查，其实我觉得更多的还是看经验了。因为有些泄漏真的是很难发现，如果是偶然才会发生的泄漏，那就真的更难查找了。
---------------------