摘自[url]http://blog.csdn.net/jzf429/article/details/6575660[/url]
Android ListView反复调用getView和getCount
最近做项目发现一个界面当有ListView是,getView和getCount中的log被疯狂调用。一个5个Item的ListView,getView竟然会被反复调用7组。尤其是当ItemView中需要加载图片时,很容易造成GC过多,很容易出现ANR。
原因就在于measure过程,ListView一般都会有好多个Item,而且也会同时显示若干组Item,这些Item的父元素都是这个ListView。
更具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,这个过程会更加漫长。
所以,解决方法就是尽量避免自适应,除非是万不得已,固定大小或者填充的效果会比较好一些。
Android ListView反复调用getView和getCount
最近做项目发现一个界面当有ListView是,getView和getCount中的log被疯狂调用。一个5个Item的ListView,getView竟然会被反复调用7组。尤其是当ItemView中需要加载图片时,很容易造成GC过多,很容易出现ANR。
原因就在于measure过程,ListView一般都会有好多个Item,而且也会同时显示若干组Item,这些Item的父元素都是这个ListView。
更具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,这个过程会更加漫长。
所以,解决方法就是尽量避免自适应,除非是万不得已,固定大小或者填充的效果会比较好一些。