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