一次glide内存泄漏排查分析
glide是一款非常优秀的图片加载框架，目前很多项目在使用。提供了非常方法，在此，笔者就不一一列举了，可以到官网查找。
目前项目在做内存排查，因为是车机项目，之前开发的时候没有注意内存方面的问题（车机项目你懂的），现在ota期间系统提出让我们优化内存，说出现过应用内存一直增加的情况。
一脸懵逼，第一想法是系统在甩锅，哥可不接。后来自己偷偷的排查下，是有些需要优化的地方。特此记录如下。
第一想法是，车机项目加载了很多背景图，有些都在200k~~400k，和UI沟通，无法再压缩，会糊。
第二是排查代码，一顿操作，各种点击，发现本地代码有需要优化的地方。静态内部类，弱引用搞起。
最后发现是报了glide内存泄漏，话不多说上图
点进去一个
RequestManager是glide内部一个类，查找使用方法
从view 到application都可以传，传哪个就和哪个生命周期绑定
看了代码，当前我在fragment和adapter中传入的都是activity,修改写法，在activity中使用传入activity在fragment中使用传入fragment这也是官方推荐的使用方式。
AndroidStudio profiler 观察下内存情况
heap dump文件
点开其中一个
阿西吧，明明已经按照官方方法调用了，但是还是报了内存泄漏风险。我想静静。。。
moment later
我有到设置中去切换白天黑夜模式，看了下日志切换白天黑夜模式的时候并没有销毁activity，而是再次点击进入应用是才调用了ondestroy方法，是因为这个原因？
抱着这种想法，我多次切换白天黑夜模式，并且退出进入应用，没有报多个activity实例，一直都是2个，嗯...大概是这个原因了，这时候我想如果我进入应用中
这时候实例中activity应该只有一个实例了吧。然并卵，手动gc释放，没有变化。后来和后面一大佬聊天，被告知，androidstudio 手动gc并不能回收activity实例，
它是系统内存不足时被AMS回收的。如果这样的话那就能解释的通了。
后来我想如果传入application呢，上家公司做瀑布流列表我依稀记得是全局封装的application,说干就干。一顿操作
heap dump文件
androidtudio peofiler没有再报溢出，差不多时间两种方式内存占用趋势也基本一致，最后内存也大体相同。
得出结论：
1.glide能很好的管理内部，引用。profiler虽然提醒了内存溢出，但是这只是有风险，并不一定会报
2.glide传入application 在应用没有动态列表图片加载的时候可以满足加载图片和内存两者之间的平衡，如果瀑布流图片较多，可考虑加入内存清理机制
大家有什么观点，欢迎共同探讨