初看上去，代码逻辑好像也没什么问题，网上大部分人也是这么写的。当较慢滑动ListView时，或在平时正常使用时，也没有什么问题。但是此处的代码逻辑真的严密吗？
ListView的getView复用特性，大家也都熟知。对于之前遇到的“图片错位/先显示之前的图片后再被正确的图片覆盖掉”，此类现象也都知道如何解决（在getView逻辑开始处理处将ImageView设置成最先的默认图片，其他UI元素类似处理），基本上也不会再有“图片错位/先显示之前的图片后再被正确的图片覆盖掉”这类现象了。实际上，当网速条件一般，且loadImage大致与上述代码所示，在ListView中快速滑动列表，几屏后，不出意外，会发现“图片错位/先显示之前的图片后再被正确的图片覆盖掉”此问题依然存在。
此时问题出现的原因不在于getView本身，因为getView逻辑开始时已经将ImageView重置为默认图片，而在于“Android异步回调UI同步性问题”。由于ViewHolder的不断复用，网速一般时快速滑动几屏后，onLoadingComplete的异步回调执行时与当前UI元素已经存在不一致，简单点理解，ImageView被复用了ImageView position 0，ImageView position 11， ImageView position 21，此时滑动停止，onLoadingComplete的异步回调执行时ImageView已经是最后一次的ImageView position 21，而onLoadingComplete的异步回调可能被执行数次（ImageView position 0，ImageView position 11， ImageView position 21，且顺序还取决于异步中的具体处理和网络环境等），于是问题发生了。
解决方案：
抓住”UI元素中的某一特性的表征量“，在异步回调中通过比较“异步回调生成点”和“异步回调执行点”此特征变量的值直接作出逻辑上的处理。
public class HardRefSimpleImageLoadingListener implements ImageLoadingListener {
public int identifier;
public HardRefSimpleImageLoadingListener() {
}
public HardRefSimpleImageLoadingListener(int identifier) {
this.identifier = identifier;
}
@Override
public void onLoadingCancelled(String arg0, View arg1) {
}
@Override
public void onLoadingComplete(String arg0, View arg1, Bitmap arg2) {
}
@Override
public void onLoadingFailed(String arg0, View arg1, FailReason arg2) {
}
@Override
public void onLoadingStarted(String arg0, View view) {
}
}
ImageLoader.getInstance().loadImage(imageUrl, new HardRefSimpleImageLoadingListener(did) {
@Override
public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
if (loadedImage != null) {
if (identifier != did) {
return;
}
imageView.setImageBitmap(loadedImage);
// 其他业务逻辑处理..
}
}
});
