Android ListView 卡顿分析
来源:互联网 发布:怎么在手机淘宝搜同款 编辑:程序博客网 时间:2024/04/29 06:09
场景:
复杂的ListView布局,嵌套很多层,十分不好修改,滑动特别卡,首先从setTag与getTag重复使用曾经创建的View来解决卡顿问题,但是最后发现7条数据getView还是被重复调用,甚至被调用超过50次,可想如果数据一多得卡成什么样...
问题:
为什么getview会被重复调用呢?
解决与分析:
通过百度,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,这个过程会更加漫长。
所以,解决方法就是尽量避免自适应,除非是万不得已,固定大小或者填充的效果会比较好一些。
于是我们把listview与他父控件的所有高度与宽度都设置为fill_parent,果然getview调用正常了,注意是所有的高度和宽度!
当发现初始化adapter的时候正常调用之后,我们再来尝试滑动listview,发现每出现一个item,当前视图显示的item又调用了一次getview,通过刚哥的这篇帖子,定位到问题在我的getview中使用了// notifyDataSetChanged(); 把这行去掉 listview 就已经宣告不再卡顿了!
附带刚哥的listview卡顿终极解决方案原帖:刚哥的Listview卡顿终极解决方案。
- Android ListView 卡顿分析
- Android ListView 卡顿分析
- android listview 卡顿的原因分析
- ListView卡顿分析
- ListView卡顿原因分析
- Android ListView 卡顿问题分析与解决方案
- Android-ListView卡顿优化
- BlockCanary分析android卡顿
- Android app 卡顿分析
- BlockCanary分析android卡顿
- Android ListView滑动卡顿优化
- android listview 滑动卡顿问题解决
- ListView卡顿问题解决
- listview滑动卡顿
- ListView嵌套卡顿问题分析及解决
- android 动画卡顿分析工具
- Android App卡顿问题分析
- Android为什么卡顿系统原理分析
- 设计模式(3):抽象工厂模式
- Linux Tomcat 强制性停止
- 改变学习模式,在课外学习中获得突破
- 世界上最伟大的推销员
- MsgBox-自定义消息对话框控件(非重写MessageBox)
- Android ListView 卡顿分析
- 常用Java开源库(新手必看)
- Gvim配置(Windows and Linux)for C/C++
- linux的hostname修改
- Android 手机震动调用
- FLSL2.0学习笔记(三)
- 在IDEA中加载 JSTL标签库
- JS有趣的单线程 [学习]
- HTTP请求:GET与POST方法的区别