探究Android中Listview顯示錯亂問(wèn)題

問(wèn)題

最近在項目中遇到過(guò)一個(gè)很棘手的問(wèn)題，就是ListView在滑動(dòng)后就莫名其妙的顯示錯亂，網(wǎng)上查閱資料后問(wèn)題很容易的就解決了，但是對于問(wèn)題產(chǎn)生的原因仍是一知半解，所以不甘心的我定下心來(lái)，狠讀源碼，終于理清了其中的”奧秘“。

由來(lái)

一般的關(guān)于A(yíng)dapter中g(shù)etView的寫(xiě)法不外乎以下形式：

@Override

public View getView(int position, View convertView, ViewGroup parent) {

ViewHolder holder;

if (convertView == null) {

convertView = mLayout.inflate(R.layout....);

holder = new ViewHolder();

holder.textView = (TextView) convertView

.findViewById(R.id.textview);

... ...

convertView.setTag(holder);

} else {

holder = (ViewHolder) convertView.getTag();

}

holder.textView.setText(mText + position);

return convertView;

}

在A(yíng)ndroid源碼中關(guān)于getView方法的實(shí)現就是采用的以上形式，如ArrayAdapter等。因為這種寫(xiě)法的好處也是顯而易見(jiàn)的，如果該position的convertview曾經(jīng)被加載過(guò)，在數據集合未被改動(dòng)的前提下，系統會(huì )自動(dòng)將該position的convertview緩存起來(lái)，避免重復加載耗費資源。

然后問(wèn)題就來(lái)了，當時(shí)我就”自作小聰明“，覺(jué)得當convertview==null時(shí)只是做了item布局的加載以及相關(guān)控件ID的綁定操作，為什么連內容的加載操作也放入其中呢，這樣下次加載緩存是就省去內容set的操作了，然后就出現了滑動(dòng)ListView后數據顯示錯位的問(wèn)題-。-。

原因

后來(lái)看源碼發(fā)現，原來(lái)AbListView中獲取getView()和滑動(dòng)操作是異步進(jìn)行的，其中滑動(dòng)操作在一個(gè)FlingRunnable的支線(xiàn)程中運行，所以這就導致了在ListView在滑動(dòng)時(shí)可能已經(jīng)滑動(dòng)到了第十行，但可能第二行的數據這時(shí)就被直接使用了，這就是導致數據加載錯亂的根本原因。

附上源碼中對FlingRunnable的注釋?zhuān)?/p>

/**

* Responsible for fling behavior. Use {@link #start(int)} to

* initiate a fling. Each frame of the fling is handled in {@link #run()}.

* A FlingRunnable will keep re-posting itself until the fling is done.

*

*/

private class FlingRunnable implements Runnable {

/**

* Tracks the decay of a fling scroll

*/

private final OverScroller mScroller;

... ...

}

解決方法

所以唯一的解決方法就是只在convertview中緩存該ChildView的layout，但ChildView 中的數據必須每次都重新獲取并加載。其實(shí)ListView數據加載及數據緩存是比較復雜的(幾個(gè)相關(guān)的類(lèi)加起來(lái)上完行=。=)，所以以后有機會(huì )還是要好好研讀源碼，這樣才能更加透徹的理解原理。