Explore the problem of incorrect display of Listview in Android
The problem has recently encountered a very difficult problem in the project, that is, the display of ListView After sliding is inexplicably disordered, and the problem can be easily solved after reading the information on the Internet, but the cause of the problem is still unknown, so I am unwilling to settle down, read the source code, and finally clarify the "mystery". Generally, getView is written in the following form: @ Overridepublic 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;} in the Android source code, the getView method is implemented in the preceding format, such as ArrayAdapter. The advantage of this method is obvious. If the convertview of the position has been loaded, the system automatically caches the convertview of the position without changing the data set, avoid resource consumption during repeated loading. Then the problem came. At that time, I was "self-made smart" and thought that when convertview = null, I only loaded the item layout and bound the related control ID, why do I need to add the content loading operation to it? In this way, the next time the cache is loaded, the content set operation will be omitted. Then, the problem of data display dislocation after the ListView sliding occurs -. -. After looking at the source code, we found that the getView () and slide operations obtained in AbListView were performed asynchronously, and the slide operation was executed in a FlingRunnable route, therefore, the ListView may have moved to the Tenth row when sliding, but the data in the second row may be directly used, which is the root cause of data loading disorder. Add the FlingRunnable annotation in the source code:/*** 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 roller ;......} solution, so the only solution is only in convert View cache the layout of the ChildView, but the data in ChildView must be retrieved and loaded every time. In fact, ListView data loading and data caching are relatively complicated (a few related classes add up to finish the line =. =), So you have the opportunity to carefully study the source code in the future to better understand the principle.