Analysis of UI synchronization problems in an Android asynchronous callback _android

In the Android coding process, callbacks are everywhere. Start with the most common activity lifecycle callbacks, to Broadcastreceiver, service, and SQLite. Activity, Broadcastreceiver, and service the callback paths and processes of these basic components are commonly called "lifecycles." At the same time, when dealing with specific business logic, it is often designed to communicate between different threads, such as notifying the UI thread to update the UI after downloading the picture, where such scenarios, regardless of the type of communication between the threads (Handler/message, Handler/post, interface based callbacks, Based on many pairs of observer patterns such as Eventbus, and so on, it is essentially based on "callback." In the actual coding process, all involved in the communication between different threads, essentially is "asynchronous callback." When you need to modify the UI in asynchronous callbacks, you need to pay special attention to UI synchronization issues.

In order to facilitate the elaboration of the problem, the "Android asynchronous callback UI synchronization problem" is defined as follows: When an asynchronous callback executes (called an "asynchronous callback execution Point"), the element on the current UI interface starts when the caller that originally generated the asynchronous callback executes (called the "asynchronous callback Generation Point"). has already been inconsistent with the UI elements of the inconsistencies include not only the possible interface changes to UI elements, possible content changes, but also the representation of an attribute in the UI element (such as a field value that represents the current UI element) when the "Asynchronous callback execution point" and "asynchronous callback generation point" are related, Even UI element interfaces and content have not changed.

In the coding process, the "Android asynchronous callback UI synchronization problem" often exists, sometimes a little attention will produce some seemingly incomprehensible bugs, and because of the existence of asynchronous features, such bugs also have a certain randomness. Sometimes because of the complexity of some requirements, such bugs are very subtle and easy to ignore. At least so far, in actual development, I have encountered a number of such problems.

The description of the plain text may not be very well understood, and the following is an example of a very common android-universal-image-loader , with a simple example of a potential "Android asynchronous callback UI synchronization Problem".

ListView Item View has ImageView, through the Android-universal-image-loader to load the display, the picture after the completion of the load need to do some logical processing (such as hidden picture loading progress bar, etc.). ), the usual code is as follows:

Imageloader.getinstance (). LoadImage (ImageUrl, New Imageloadinglistener () {
        
 @Override public
 Void Onloadingcomplete (String Imageuri, view view, Bitmap loadedimage) {
  if (loadedimage!= null) {
   Imageview.setimagebitmap (loadedimage);
   Other business logic processing.}
 }

 @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) {
  
 }
});

At first glance, there seems to be no problem with code logic, as most people on the Internet write. When the slower sliding listview, or in peacetime normal use, there is no problem. But is the code logic here really tight?

ListView's GetView multiplexing features are well known to all. For previously encountered "picture dislocation/first show before the picture before being the correct picture covered", this kind of phenomenon also knows how to solve (at the GetView logic start processing Place ImageView to the first default picture, other UI element similar processing), basically also does not have "the picture dislocation" Show the previous picture and then be covered by the correct picture "this kind of phenomenon." In fact, when the speed of the general conditions, and LoadImage roughly with the above code, in the ListView Quick Slide list, a few screen, no accident, will find "picture dislocation/first show before the picture before being the correct picture covered" This problem still exists.

The problem at this point is not the GetView itself, because the GetView logic started by resetting ImageView to the default picture, and the Android asynchronous callback UI synchronization problem. As a result of the continuous reuse of viewholder, speed in general when the rapid slide several screens, Onloadingcomplete asynchronous callback execution and the current UI elements have been inconsistent, simple understanding, ImageView was reused ImageView position 0,imageview position, ImageView position 21, at this point the slide stops, Onloadingcomplete's asynchronous callback executes ImageView is the last ImageView position 21, and Onloadingcomplete's asynchronous callback may be executed several times (ImageView position 0,imageview position ImageView 21, and the order also depends on the specific processing and network environment in the asynchronous, so the problem occurs.

Solution:
Captures the representation of an attribute in the UI element, which is logically handled directly in the asynchronous callback by comparing the value of this feature variable, "Asynchronous callback Generation Point" and "asynchronous callback execution point".

 public class Hardrefsimpleimageloadinglistener implements Imageloadinglistener {Publi

 c int identifier; Public Hardrefsimpleimageloadinglistener () {} public hardrefsimpleimageloadinglistener (int identifier) {This.identi
 Fier = identifier; @Override public void onloadingcancelled (String arg0, View arg1) {} @Override public void Onloadingcomplete (STR ing 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 (imag Eurl, New Hardrefsimpleimageloadinglistener (did) {@Override public void Onloadingcomplete (String imageuri, view view, B
   Itmap loadedimage) {if (loadedimage!= null) {if (identifier!= did) {return;
   } imageview.setimagebitmap (Loadedimage);
  Other business logic processing.
}
 }
}); 

In short, where this type of "Android asynchronous callback UI synchronization Problem" is best done logically by comparing the value of the "asynchronous callback generation Point " and "asynchronous callback execution Point" feature variable, In order to avoid unnecessary bugs, is a very necessary and effective means.

Original address: http://www.cnblogs.com/lwbqqyumidi/p/4110377.html

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.