小编点评

## glide内存泄漏分析总结 **主要问题:** glide 应用在内存管理方面存在漏洞，导致内存泄漏。 **原因:** 1. **背景图过多:** glide 在加载背景图时，会创建多个 `RequestManager`，每个 `RequestManager` 对应一个 Activity。背景图数量与 Activity 数量之间没有定理关系，导致过多 `RequestManager` 会导致内存泄漏。 2. **代码优化不当:** 在代码中存在一些优化操作，例如使用 `WeakReference` 来管理弱引用的对象，但这些优化操作可能导致内存泄漏。 3. **全局应用:** glide 在瀑布流列表中使用全局 `application` 对象，这可能导致内存泄漏。 **解决方案:** 1. **限制背景图数量:** 优化 Glide 的背景图加载机制，例如只创建必要数量的 `RequestManager`。 2. **仔细优化代码:** 仔细分析代码，寻找可能导致内存泄漏的代码片段。 3. **避免全局应用:** 将所有全局应用对象缓存到 `Application` 中，或者使用其他机制实现全局数据共享。 4. **使用 `System.gc()` 进行手动内存清理:** 在应用程序退出时，调用 `System.gc()` 进行内存清理，以释放资源。 5. **监控内存情况:** 使用 Android Studio 的内存分析工具，监控应用的内存占用情况，及时发现和解决内存泄漏问题。

正文

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 在应用没有动态列表图片加载的时候可以满足加载图片和内存两者之间的平衡，如果瀑布流图片较多，可考虑加入内存清理机制

大家有什么观点，欢迎共同探讨