Glide使用内存飙升记
把解决方案放到前面: 不要再ScrollView中使用Glide/Fresco加载图片,因为这两开源框架是根据RecyclerView回收池来复用图片,所以使用ScrollView会出现无法回收图片的问题
稍微改下布局格式..之前的排版太乱了
BUG产生的原因仅仅是个简单的滑动布局,ScrollView嵌套RecycleView;
布局文件..大概是这个样子的
<SmartRefreshLayout>
<Header/>
<NestedScrollView>
<LinearLayout>
<Banner/>
<GridView/>
<RecyclerView/>
</LinearLayout>
</NestedScrollView>
<Footer/>
</SmartRefreshLayout>
看似无毒的布局.
Q1 运行起来就发现第一个问题,RecyclerView滑动不流畅,感觉像脚底粘了胶...
Google一下:NestedScrollView导致
RecyclerView设置.setNestedScrollingEnabled(false)属性即可
设置完,哇 简直流畅! 完美
Q2 新需求马上已经到达战场
大概就是加了个渐进效果的ToolBar,根据滑动的高度显示或隐藏ToolBar,改完后布局也很简单
<FrameLayout>
<原布局>
<SelfToolBar/>
</FrameLayout>
呃 直接重写了NestedScrollView的OnScroll方法,低版本不能用,监听下高度,设置个渐进颜色就GG
Q3 啊 测试的来了!!! PS: 文章所指问题
问题:大概测出的问题就是 当首页的图片加载到20左右页,图片加载了180张左右,出现卡顿问题,刷新的动画卡,Item增加的动画也卡...很卡很卡
初步认为是RecyclerView的notifyDataSetChanged() 数据更新的问题,
所以我把notifyDataSetChanged()改成了notifyItemRangeInserted(),有一点效果, 但是不明显( PS: 这里还有个小细节问题,
PS:顺便跟大家说一下,setHasFixedSize,貌似这个属性是这么写的,导致的问题是 下拉刷新后,再进行下拉加载更多,RecyclerView无法下拉到底部,但是下拉刷新的事件已经产生了... 把这个属性去掉就好,如果想实验可以写个Demo测试下,RecyclerView对这个属性也做了介绍,大家可以查看下源码 还是很好懂的,就不过多解释了)
再怀疑是Glide在刷新的时候请求图片造成的卡顿,于是在RecyclerView的Scoller事件中控制滑动时暂停所有请求,运行,效果还是一样,再群里提问,还是得到一样的答案,并没有亮眼的回答
后通过打印日志发现,在RecyclerView中的Scroll事件压根没有触发,查了下资料,由于设置了setNestedScrollingEnabled这个属性,R的滑动事件交给了Ne的NestedScrollingChildHelper,哇! 问题岂不是马上就要解决了,待我压抑一波激动地心情,跑起来吧,很明显,Glide的请求加载在滑动时已经停止,但是卡顿的问题还是没有解决…哎 心累
跑了趟Glide的GitHub,搜到了个类似的问题,看描述也是在加载的图片的过程中,导致内存飙升,是因为使用了CenterCrop导致...看了代码,简直一毛一样啊,解决办法是.format(DecodeFormat.PREFER_RGB_565),设置在Glide的option中,再run一次! 果然有效果,内存涨的果然没那么厉害了;但是每次加载还是在涨1.5M左右,并且不会下降,主动GC也没有效果...
难道我的神Glide要GG了??? 于是我换成了fresco, 嗯~~~fresco默认加载图片确实很舒服...但是问题为什么还在啊!!! 后来我在Fresco的使用文档里发现了一句关键的话
嗯,好吧 就是这样Fresco官方不建议这么做,相同道理,Glide也是这么设计的吧,试了下,去掉了NestedScrollViewg果然流畅了,内存保持在100上下浮动,至于上面的那些View,直接做成HeaderView Add进去
解决:不要再ScrollView中使用Glide/Fresco加载图片,因为这两开源框架是根据RecyclerView回收池来复用图片,,,所以使用ScrollView会出现无法回收图片的问题
至此,这次内存飙升的问题就解决了,虽然不是啥大问题,只是点出来给遇到这种问题的朋友指个路,节省下开发的时间
文章完全没有排版,当做日志写了写,非喜勿喷
谢谢
