ListView卡顿原因分析

1..Adapter的getView方法里面convertView没有使用setTag和getTag方式；
2.在getView方法里面ViewHolder初始化后的赋值或者是多个控件的显示状态和背景的显示没有优化好，抑或是里面含有复杂的计算和耗时操作；
3.在getView方法里面 inflate的row 嵌套太深（布局过于复杂）或者是布局里面有大图片或者背景所致；
4.Adapter多余或者不合理的notifySetDataChanged；
5.listview 被多层嵌套，多次的onMessure导致卡顿，如果多层嵌套无法避免，建议把listview的高和宽设置为fill_parent. 如果是代码继承的listview，那么也请你别忘记为你的继承类添加上LayoutPrams，注意高和宽都是fill_parent的;

----------------------------------------------------------------

在构造方法中耗时会导致ListView第一次加载时比较慢, 但是如果在getView方法中耗时就会导致整个ListView卡顿

 

1..Adapter的getView方法里面convertView没有使用setTag和getTag方式；

    每次getView都要执行 findViewById, 这是相当耗时的

 

2.在getView方法里面ViewHolder初始化后的赋值或者是多个控件的显示状态和背景的显示没有优化好，抑或是里面含有复杂的计算和耗时操作；

    如果使用了ViewHolder, 那么viewHolder初始化, 或者控件操作太复杂,导致耗时

 

3.在getView方法里面 inflate的row 嵌套太深（布局过于复杂）或者是布局里面有大图片或者背景所致；

    单个item的布局太复杂, 或者 加载大图片, 或者从网上获取图片

 

4.Adapter多余或者不合理的notifySetDataChanged；

    通知所有的观察者, 底层数据已经改变, 所有显示这些数据的View都应该刷新

 

5.listview 被多层嵌套，多次的onMessure导致卡顿，如果多层嵌套无法避免，建议把listview的高和宽设置为fill_parent. 如果是代码继承的listview，那么也请你别忘记为你的继承类添加上LayoutPrams，注意高和宽都是fill_parent的;

        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调用正常了，注意是所有的高度和宽度！