Problem
Recently encountered a very difficult problem in the project, is ListView in the slide after the inexplicable display of disorder, online access to information after the problem is very easy to solve, but for the cause of the problem is still a smattering of, so unwilling to settle my heart, malicious read the source code, and finally cleared the "mystery."
Origin
In general, the writing of GetView in adapter is as follows:
The code is as follows |
Copy Code |
@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; } |
The implementation of the GetView method in the Android source code is based on the above forms, such as Arrayadapter. Because the advantages of this writing is also obvious, if the position Convertview has been loaded, in the data set has not been altered, the system will automatically cache the position convertview, to avoid repeated loading of resources.
Then the problem came, then I was "smart", I think when Convertview==null just did the load of the item layout and related control ID binding operations, why even the loading of the contents of the operation also put it, so that the next load cache is to omit the content set operation, Then there is the problem of data display dislocation after sliding listview-. -。
Reason
Then look at the source found that the original ablistview to get GetView () and sliding operation is asynchronous, where the sliding operation in a flingrunnable of the feeder run, so this leads to the ListView in the sliding may have slipped to the tenth line, But perhaps the second row of data is being used directly, which is the root cause of the data-loading disorder.
Enclosed in the source code for flingrunnable comments:
The code is as follows |
Copy Code |
/** * Responsible for fling behavior. Use {@link #start (int)} to * Initiate a fling. Each frame of the fling was handled in {@link #run ()}. * A Flingrunnable would 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; ... ... } |
Solving method
So the only workaround is to cache the Childview's layout only in Convertview, but the data in Childview must be retrieved and loaded each time. In fact, ListView data loading and data caching is more complex (several related classes add up to the end of the line =. =), so there will be a chance to study the source code, so that more thorough understanding of the principle.