Basically, as long as the control inherits from the view, has the message queue or the handler some processing method, below is some handler method as well as the method which the view encapsulates, its underlying use is handler's API.
Let me open the definition of postdelay.
Android.view.View
public boolean postdelayed (Runnable action, long Delaymillis) {final Attachinfo attachinfo = Mattachinfo; if (attachinfo! = null) {return attachInfo.mHandler.postDelayed (action, Delaymillis); }//Assume that post would succeed later Viewrootimpl.getrunqueue (). postdelayed (action, Delaymillis); return true; }
Not only that, there is also a method in activity that sends messages to the UI thread, Runonuithread (Runnable action);
Let's take a look at his eyes.
Java.app.Activity
Public final void Runonuithread (Runnable action) {if (Thread.CurrentThread ()! = Muithread) {MHANDLER.P OST (action); } else {action.run (); } }
Obviously, when the method runs on the UI thread, it executes immediately, otherwise the message is sent to the UI thread before it is executed.
Runonuithread also saves us the ability to create handler asynchronously, such as in multi-threading, no longer using handler to send messages in a child thread, it is entirely possible to call this method in a child thread to "update" the UI (note Oh, This actually sends the message and executes the code snippet to the UI, not to update on the child thread)
Update data using the view's Message Queuing API in Android