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 在应用没有动态列表图片加载的时候可以满足加载图片和内存两者之间的平衡，如果瀑布流图片较多，可考虑加入内存清理机制
大家有什么观点，欢迎共同探讨
1.本站内容仅供参考，不作为任何法律依据。用户在使用本站内容时，应自行判断其真实性、准确性和完整性，并承担相应风险。
2.本站部分内容来源于互联网，仅用于交流学习研究知识，若侵犯了您的合法权益，请及时邮件或站内私信与本站联系，我们将尽快予以处理。
3.本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
4.根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。”您需知晓本站所有内容资源均来源于网络，仅供用户交流学习与研究使用，版权归属原版权方所有，版权争议与本站无关，用户本人下载后不能用作商业或非法用途，需在24个小时之内从您的电脑中彻底删除上述内容，否则后果均由用户承担责任；如果您访问和下载此文件，表示您同意只将此文件用于参考、学习而非其他用途，否则一切后果请您自行承担，如果您喜欢该程序，请支持正版软件，购买注册，得到更好的正版服务。
5.本站是非经营性个人站点，所有软件信息均来自网络，所有资源仅供学习参考研究目的，并不贩卖软件，不存在任何商业目的及用途
暂无评论内容