Android中的GridView反复调用getView和getCount,并且getView中的position的值几乎都是0

本文深入探讨了GridView使用中的性能问题,特别是当ItemView中包含图片时,频繁的measure过程可能导致GC过多,引发ANR。文章详细解释了View的measure、layout和draw阶段的工作原理,并提供了避免自适应布局、固定大小或填充效果来优化性能的解决方案。
摘要由CSDN通过智能技术生成

      最近做项目发现一个界面当用到GridView的时候,getView和getCount中的log被疯狂调用,并且getVIew中的LOG每出来一次就是四条,并且这四条数据的position的值都是0。一个5个Item的GridView,getView竟然会被反复调用。尤其是当ItemView中需要加载图片时,很容易造成GC过多,很容易出现ANR。

       原因就在于measure过程, GridView 一般都会有好多个Item,而且也会同时显示若干组Item,这些Item的父元素都是这个 GridView 

更具Google的解释,View在Draw的时候分成两个阶段:measure和layout,在measure阶段时主要就是为了计算两个参数:height和width。而且要注意的是,这是个递归的过程,从顶向下,DecorView开始依次调用自己子元素的measure。计算完成这两个参数后就开始layout,最后再是draw的调用。

       对于ListView,当然每一个Item都会被调用measure方法,而在这个过程中getView和getCount会被调用,而且看用户的需求,可能会有很多次调用。

而为什么会有很多组次调用呢?

        问题就在于在layout中的决定ListView或者它的父元素的height和width属性的定义了。fill_parent会好一点,计算方法会比较简单,只要跟父元素的大小相似就行,但是即使是fill_parent,也不能给View当饭吃,还是要计算出来具体的dip,所以measure还是会被调用,只是可能比wrap_content的少一点。至于自适应的它会一直考量它的宽和高,根据内容(也就是它的子Item)计算宽高。可能这个measure过程会反复执行,如果父元素也是wrap_content,这个过程会更加漫长。

所以,解决方法就是尽量避免自适应,除非是万不得已,固定大小或者填充的效果会比较好一些。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值