Win32視窗訊息機制 x Android訊息機制 x 非同步執行

標籤：發送   public   視圖   bsp   win32   override   查看   handle   roi   

如果你開發過Win32視窗程序，那麼當你看到android代碼到處都有的mHandler.sendEmptyMessage和

private final Handler mHandler = new Handler() {        @Override        public void handleMessage(Message msg) {            switch (msg.what) {                case MSG_REPORT_PRIMARY_CLIP_CHANGED:                    reportPrimaryClipChanged();            }        }    };

不禁歎出，這不就是視窗訊息機制嗎？只是不關視窗的事了，然後分離出來訊息機制。
sendMessage這個函數，我們查看視窗屬性，改變視窗屬性，通知視窗發生事件一切的一切彷彿都在調用這個函數。
WinProc這個訊息處理函數，即使你在android的java代碼裡換了個名handleMessage，我們就認不出你來了嗎？
就連Message也同樣是一個整形，同時攜帶兩整形參數（windows視窗訊息c代碼中可以放指標，android訊息java代碼另外還有Bundle,
Object引用參數，因為int不可以轉換對象引用）

這樣就很容易理解了：
在windows中，向一個視窗發送視窗訊息，實質就是向建立視窗所在的線程的訊息佇列發送視窗訊息，或阻塞等待處理或不阻塞。
在android中，向一個Handler發送訊息，同樣是在向這個Handler關聯的線程的訊息佇列發送訊息，並且不阻塞不等待處理。
在Win32視窗訊息機制，訊息在訊息迴圈中指派。
在android中，Looper封裝了這個訊息迴圈以及訊息佇列，並線上程的TLS中存放其引用（指標），對於線程唯一存在。如果在執行個體
Handler時不指明Looper預設借用當前線程的Looper。Handler關聯某一個Looper，一個Looper唯一關聯一條線程。向Handler發送訊息
就是向Looper的訊息佇列發送（入隊）訊息，線程必須執行Looper.loop訊息迴圈，訊息才能指派。

要注意就是:
視窗在Windows系統是系統範圍的，我們可以利用視窗訊息進行進程間通訊。而android的Handler卻不是。
視窗在Windows系統在建立它的線程上處理訊息，任何線程都可以建立視窗。而android的視窗（視圖）只能在主線程建立和訪問。
在android的訊息機制中，還可以發送一個Runnable到某一線程的訊息迴圈中執行，這點就仿如iOS的GCD中的dispatch_async代碼塊。

參看原始碼：

public void dispatchMessage(Message msg) {        if (msg.callback != null) {            handleCallback(msg);        } else {            if (mCallback != null) {                if (mCallback.handleMessage(msg)) {                    return;                }            }            handleMessage(msg);        }    }

Java非同步線程執行代碼塊：

mHandler.post(new Runnable() {     public void run() {     // ....     }});

OC非同步線程執行代碼塊：

dispatch_async(global_queue, ^{     // ....     });

 

Win32視窗訊息機制 x Android訊息機制 x 非同步執行