WIN32 window message mechanism x Android message mechanism x asynchronous execution

If you've developed a WIN32 window program, then when you see Android code everywhere there are mhandler.sendemptymessage and

Private Final New Handler () {        @Override        publicvoid  handlemessage (Message msg) {             Switch (msg.what) {                case  msg_report_primary_clip_changed:                    reportprimaryclipchanged ();            }        }    };

Can't help but sigh, this is the window message mechanism? It's just a matter of not closing the window, and then separating out the message mechanism.
SendMessage This function, we look at the window properties, change the window properties, notify the window of the event everything seems to be calling this function.
WinProc This message handler, even if you change a name handlemessage in the Java code of Android, won't we recognize you?
Even the message is also a cosmetic, carrying two shaping parameters (Windows window message C code can put pointers, Android message Java code There are also bundles,
Object reference parameter, because int cannot be converted to object reference)

This is easy to understand:
In Windows, sending a window message to a window essentially sends a window message to the message queue of the thread on which the window is created, or blocks pending processing or blocking.
In Android, a message is sent to a handler, which also sends a message to the message queue of the thread associated with the handler, and does not block without waiting for processing.
In the Win32 window message mechanism, the message is dispatched in the message loop.
In Android, Looper encapsulates this message loop as well as the message queue and holds its reference (pointer) in the thread's TLS, which is unique for threads. If the instance
Handler does not indicate that Looper defaults to borrowing the looper of the current thread. Handler associates a looper, a looper uniquely associates a thread. Send a message to handler
is to send (enqueue) messages to the Looper message queue, and the thread must execute the LOOPER.LOOP message loop for the message to be dispatched.

Be aware that:
Windows systems are system-wide, and we can use window messages for interprocess communication. And Android's handler is not.
A window processes messages on the thread that the Windows system creates it, and any thread can create Windows. While the android window (view) can only be created and accessed in the main thread.
In the Android messaging mechanism, you can also send a runnable to a thread in the message loop, which is like the Dispatch_async code block in iOS gcd.

See Source code:

 Public void DispatchMessage (Message msg) {        ifnull) {            handlecallback (msg);         Else {            ifnull) {                if  (Mcallback.handlemessage ( msg) {                    return;                }            }            Handlemessage (msg);        }    }

Java Asynchronous thread execution code block:

Mhandler.post (new  Runnable () {     publicvoid  run () {     //  ....      }});

OC Asynchronous thread execution code block:

Dispatch_async (Global_queue, ^{     //  ...     });

WIN32 window message mechanism x Android message mechanism x asynchronous execution