Android程序编码过程中，回调无处不在。从最常见的Activity生命周期回调开始，到BroadcastReceiver、Service以及Sqlite等。Activity、BroadcastReceiver和Service这些基本组件的回调路径和过程也就是通常意义上所谓的“生命周期”。同时，在处理具体的业务逻辑时，常常设计到不同线程之间的通信，如下载图片完成后通知 UI线程更新UI，凡此类场景，无论使用哪一种具体的线程间通信方式（Handler/Message、Handler/post、基于接口的回调、基于多对多的观察者模式如EventBus等），其本质上都是基于“回调”。在实际编码过程中，凡涉及到不同线程之间的通信，本质上更是属于“异步回调”。当需要在“异步回调”中修改UI时，此时需要特别注意UI同步性问题。
为了便于问题的阐述，在此先对“Android异步回调UI同步性问题”进行如下界定：当异步回调执行时（称之为“异步回调执行点”），当前UI界面上的元素与最初生成此异步回调的调用器开始执行时（称之为“异步回调生成点”）的UI元素已经存在不一致，不一致不仅包括UI元素可能的界面变化、可能的内容变化，也包括“异步回调执行点”和“异步回调生成点”时的UI元素中的某一特性的表征量（如某一具有表征当前UI元素的字段值）相关，即使UI元素界面和内容都尚未发生变化。
编码过程中，“Android异步回调UI同步性问题”经常存在，有时候稍不注意会产生一些看起来难以理解的bug,并由于异步特性的存在，此类bug还具有一定的随机性。有时候由于一些需求的复杂性，此类bug隐蔽性很强，也容易被忽略。至少到目前为止，在实际开发中，本人遇到此类问题已有数个。
纯文字的描述可能不太好理解，下面以一个很常用的Android-Universal-Image-Loader为例，简单举例一个潜在存在的“Android异步回调UI同步性问题”。
ListView Item View中有ImageView，通过Android-Universal-Image-Loader去加载显示，图片加载完成后需要做一些逻辑处理（如隐藏图片加载进度条等..）,通常代码如下：
ImageLoader.getInstance().loadImage(imageUrl, new ImageLoadingListener() {
@Override
public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
if (loadedImage != null) {
imageView.setImageBitmap(loadedImage);
// 其他业务逻辑处理..
}
}
@Override
public void onLoadingStarted(String imageUri, View view) {
}
@Override
public void onLoadingCancelled(String arg0, View arg1) {
}
@Override
public void onLoadingFailed(String arg0, View arg1, FailReason arg2) {
}
});
